ampere-av1 Phase 2 (master): fourth-fd probe + AV1 enumeration #5

2026-05-18T13:45:19Z

claude-noether commented

2026-05-18 13:45:19 +00:00

Closes the headline acceptance criterion of marfrit/libva-v4l2-request-fourier#2 — "vainfo on ampere lists VAProfileAV1".

What this PR is

A minimal master-side port of the operator's in-progress av1-iter1 Phase 2 work (commits bed75c0 + 61db76e on that branch). Hand-ported because cherry-pick has conflicts with iter39/iter40 changes that landed on master after av1-iter1 forked from iter38b. Naming uses vpu981 to match the operator's convention so the eventual av1-iter1 → master merge resolves cleanly.

What's in scope

4th-fd slot video_fd_vpu981 + media_fd_vpu981 in struct request_data
4th-decoder probe in VA_DRIVER_INIT walking hantro-vpu media nodes for an instance advertising V4L2_PIX_FMT_AV1_FRAME (OUTPUT-format probe — DTS-independent; the only reliable disambiguator since all 3 hantro instances on RK3588 report driver="hantro-vpu" + model="hantro-vpu")
'a' kind in request_device_kind_for_profile + dispatch in request_switch_device_for_profile
video_fd_vpu981 added to any_fd_supports_output_format helper (same off-by-one that bit av1-iter1's enumeration for a week)
VAProfileAV1Profile0 → V4L2_PIX_FMT_AV1_FRAME in pixelformat_for_profile
VAProfileAV1Profile0 push in RequestQueryConfigProfiles + RequestQueryConfigEntrypoints + RequestCreateConfig
Cleanup of vpu981 fds in RequestTerminate (also picks up the rpi_hevc_dec fds that were missing from cleanup — defensive fix)
V4L2_REQUEST_MAX_PROFILES bumped 13 → 14: defensively sized for post-Option-B-revert future. With Hi10P + Main10 + AV1 all enumerated, total = 13. Per-group guards use index < MAX - N; for a singleton push to succeed at index=13 we need MAX ≥ 14. Bumping now avoids a silent drop when Option B eventually reverts.

What's out of scope

Decode-side dispatch (Phase 2 step 4 + Phase 3-5 work on av1-iter1): ~700 LoC av1.{c,h} + picture.c dispatch wiring + 3/10 frames bit-exact. That stays in the operator's branch; this PR makes master's enumeration coherent so the eventual merge has a smaller delta.

Consequence today: vaCreateContext(VAProfileAV1Profile0) succeeds at the libva layer, but consumers calling vaRenderPicture with AV1 buffers will fail cleanly (no av1_set_controls dispatch yet). The bit-exact decode-side work continues in av1-iter1.

Verification

On ampere (RK3588, freshly-rebooted to 7.0.0-rc3-vp9-test+ kernel), 2026-05-18:

$ env LIBVA_DRIVER_NAME=v4l2_request vainfo | grep VAProfile
      VAProfileMPEG2Simple            :   VAEntrypointVLD
      VAProfileMPEG2Main              :   VAEntrypointVLD
      VAProfileH264Main               :   VAEntrypointVLD
      VAProfileH264High               :   VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:   VAEntrypointVLD
      VAProfileH264MultiviewHigh      :   VAEntrypointVLD
      VAProfileH264StereoHigh         :   VAEntrypointVLD
      VAProfileHEVCMain               :   VAEntrypointVLD
      VAProfileVP8Version0_3          :   VAEntrypointVLD
      VAProfileVP9Profile0            :   VAEntrypointVLD
      VAProfileAV1Profile0            :   VAEntrypointVLD   ← NEW

Probe log: "ampere-av1: vpu981 AV1 decoder at /dev/video4 + /dev/media3"

Build clean on ampere with GCC 16.1.1; no new warnings. ampere's running .so restored to the av1-iter1 build after verification — this PR's .so was NOT permanently installed.

🤖 Generated with Claude Code

Closes the headline acceptance criterion of marfrit/libva-v4l2-request-fourier#2 — "vainfo on ampere lists VAProfileAV1". ## What this PR is A minimal master-side port of the operator's in-progress `av1-iter1` Phase 2 work (commits `bed75c0` + `61db76e` on that branch). Hand-ported because cherry-pick has conflicts with iter39/iter40 changes that landed on master after av1-iter1 forked from iter38b. Naming uses `vpu981` to match the operator's convention so the eventual av1-iter1 → master merge resolves cleanly. ## What's in scope - 4th-fd slot `video_fd_vpu981` + `media_fd_vpu981` in `struct request_data` - 4th-decoder probe in `VA_DRIVER_INIT` walking hantro-vpu media nodes for an instance advertising `V4L2_PIX_FMT_AV1_FRAME` (OUTPUT-format probe — DTS-independent; the only reliable disambiguator since all 3 hantro instances on RK3588 report `driver="hantro-vpu"` + `model="hantro-vpu"`) - `'a'` kind in `request_device_kind_for_profile` + dispatch in `request_switch_device_for_profile` - `video_fd_vpu981` added to `any_fd_supports_output_format` helper (same off-by-one that bit av1-iter1's enumeration for a week) - `VAProfileAV1Profile0` → `V4L2_PIX_FMT_AV1_FRAME` in `pixelformat_for_profile` - `VAProfileAV1Profile0` push in `RequestQueryConfigProfiles` + `RequestQueryConfigEntrypoints` + `RequestCreateConfig` - Cleanup of vpu981 fds in `RequestTerminate` (also picks up the `rpi_hevc_dec` fds that were missing from cleanup — defensive fix) - `V4L2_REQUEST_MAX_PROFILES` bumped 13 → 14: defensively sized for post-Option-B-revert future. With Hi10P + Main10 + AV1 all enumerated, total = 13. Per-group guards use `index < MAX - N`; for a singleton push to succeed at index=13 we need MAX ≥ 14. Bumping now avoids a silent drop when Option B eventually reverts. ## What's out of scope - Decode-side dispatch (Phase 2 step 4 + Phase 3-5 work on `av1-iter1`): ~700 LoC av1.{c,h} + picture.c dispatch wiring + 3/10 frames bit-exact. That stays in the operator's branch; this PR makes master's enumeration coherent so the eventual merge has a smaller delta. Consequence today: `vaCreateContext(VAProfileAV1Profile0)` succeeds at the libva layer, but consumers calling `vaRenderPicture` with AV1 buffers will fail cleanly (no av1_set_controls dispatch yet). The bit-exact decode-side work continues in `av1-iter1`. ## Verification On ampere (RK3588, freshly-rebooted to `7.0.0-rc3-vp9-test+` kernel), 2026-05-18: ``` $ env LIBVA_DRIVER_NAME=v4l2_request vainfo | grep VAProfile VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileAV1Profile0 : VAEntrypointVLD ← NEW Probe log: "ampere-av1: vpu981 AV1 decoder at /dev/video4 + /dev/media3" ``` Build clean on ampere with GCC 16.1.1; no new warnings. ampere's running `.so` restored to the `av1-iter1` build after verification — this PR's `.so` was NOT permanently installed. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-noether added 1 commit 2026-05-18 13:45:19 +00:00

ampere-av1 Phase 2 (master): fourth-fd probe + AV1 enumeration c6f81c653f

Imports the minimal "vainfo lists VAProfileAV1Profile0" layer from the
operator's in-progress av1-iter1 branch (Phase 2 steps 1, 2 — commits
bed75c0 + 61db76e on av1-iter1). The Phase 3-5 bit-exact decode-side
work stays in av1-iter1; this commit gives master the enumeration +
fd-routing layer so consumers (ffmpeg-vaapi, firefox-fourier, chromium-
fourier) at least see VAProfileAV1Profile0 today on RK3588.

What this commit adds:
- video_fd_vpu981 + media_fd_vpu981 slots to struct request_data
  (named to match av1-iter1's convention so the operator's Phase 3-5
   merge resolves cleanly)
- 4th-decoder probe loop in VA_DRIVER_INIT that walks hantro-vpu
  media nodes for an instance advertising V4L2_PIX_FMT_AV1_FRAME
  (AV1F) as OUTPUT pixfmt. RK3588 has 3 hantro-vpu instances all
  reporting driver="hantro-vpu" + model="hantro-vpu", so OUTPUT-
  format probe is the only DTS-independent discriminator.
- 'a' kind in request_device_kind_for_profile (VAProfileAV1Profile0)
  + 'a' branch in request_switch_device_for_profile.
- video_fd_vpu981 added to any_fd_supports_output_format helper
  (existing 3-slot loop missed the new fd; same off-by-one trap
  that bit ampere's av1-iter1 enumeration for a week).
- VAProfileAV1Profile0 → V4L2_PIX_FMT_AV1_FRAME in pixelformat_for
  _profile.
- VAProfileAV1Profile0 push in RequestQueryConfigProfiles +
  RequestQueryConfigEntrypoints + RequestCreateConfig switch.
- vpu981 fd cleanup in RequestTerminate.
- rpi_hevc_dec fd cleanup added at the same time (was already missing
  in master — fixed defensively).
- V4L2_REQUEST_MAX_PROFILES bumped 13 → 14. Defensively sized for
  the post-Option-B-revert future: with iter39 Option B reverted
  (Hi10P + Main10 back in enumeration) plus AV1, max possible
  enumeration is 13. The per-group guards use `index < MAX - N`
  pattern; for a singleton push to succeed at index=13 we need
  MAX >= 14. Bumping now avoids the same off-by-one bug from
  silently dropping AV1 when Option B eventually reverts.

What this commit does NOT add:
- av1.{c,h} decode-side scaffolding (Phase 2 step 4 on av1-iter1 —
  ~177 LoC including a stub av1_set_controls that returns -1). When
  the operator's av1-iter1 Phase 3-5 work lands on master, those
  500+ LoC + the stub will follow. Without them, consumers calling
  vaCreateContext(VAProfileAV1Profile0) succeed at the libva layer
  but ffmpeg-vaapi will fail at the first vaRenderPicture with an
  AV1-buffer-type rejection — clean error, no crash.

Verified 2026-05-18 on ampere:

  $ env LIBVA_DRIVER_NAME=v4l2_request vainfo | grep VAProfile
        ... (10 prior profiles, unchanged) ...
        VAProfileAV1Profile0            :   VAEntrypointVLD   ✓

  Probe log: "ampere-av1: vpu981 AV1 decoder at /dev/video4 + /dev/media3"

Build clean on ampere with GCC 16.1.1; no warnings introduced.
ampere's running module restored to the av1-iter1 build after the
verification — this commit's .so was NOT permanently installed.

Closes the headline acceptance criterion in
marfrit/libva-v4l2-request-fourier#2 ("vainfo on ampere lists
VAProfileAV1"). End-to-end AV1 decode bit-exactness is iter4 work
that the av1-iter1 branch continues to drive.

Co-Authored-By: claude-noether <claude-noether@reauktion.de>