Repository navigation
Export decoder surfaces before the first decode - #123
Open
c4software wants to merge 1 commit into
Open
c4software wants to merge 1 commit into
c4software wants to merge 1 commit into
Conversation
[Medium impact] The changes appear safe to merge; no actionable code issues were found. SummaryThe decoder now exports every VA-API surface when it opens a stream, before submitting any decode.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The client exported its VA-API decode surfaces to Vulkan only after the first decode of a stream. On
libva-v4l2-request(Apple AVD on Asahi,libva-v4l2_request-avd), the first decode fixes how the CAPTURE queue is backed: MMAP when the surface has not been exported yet. Every surface exported afterwards gets its own standalone dma-buf, and the driver then refuses to decode into it:This happened from the second frame of every stream, so it repeated on each
--headlessresize, on both the main and aux streams.H264Decodernow exports every surface when it opens a stream, before any decode, and keeps the descriptors.DecodeStreamimports those instead of exporting after the fact. The driver supports this order: it switches the queue to DMABUF mode and decodes into the exported memory (the same order Chromium uses). On AMD and Intel the same dma-buf is exported, just earlier.Testing
scripts/check.shpasses.libva-v4l2_request-avd1.3.r11, kernel 7.2.11) as the client,--headlessagainst an AMD server: the errors are gone. The driver logssurface ... was exported before its first decode; decoding into client-exported dma-bufs, and resizing the window reopens the stream at each new size (1920x1088, 768x832, 960x1120, ...).scripts/e2e.shhas not been run.