forked from FFmpeg/FFmpeg
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
hw_context_vulkan: Add support for transfers to cuda
Although transfers from cuda to vulkan are currently implemented as a map rather than a transfer, this approach doesn't work in the other direction; it relies on being able to manually initialise the destination buffer pool which cannot cleanly be done from hwcontext_vulkan for a cuda destination. Rather than trying to work-around that, this change implements the transfer from vulkan to cuda as an actual transfer, using vf_hwupload[_cuda]. The change has three main parts. 1) hwcontext_vulkan: We implement a special case for transfer_to for a cuda destination. This is another GPU memcpy, and we refactor all the interop logic for reuse with map_from_cuda. We don't use the semaphores here, because cuda will naturally serialise subsequent operations after the memcpy. A semaphore would be needed if the vulkan frame might not have been completely written before the memcpy is issued, but I think this is never the case in the current design. 2) hwupload_cuda: Here we need to do two things: Declare that we can accept AV_PIX_FMT_VULKAN as an input format, and extract the sw_format if the input is a hardware frame. 3) hwupload: Here we make the same change to handle hardware input formats, but the declaration of support for vulkan happens in hwcontext_cuda due to get_constraints being used. This change is not final for one main reason. Because the filter format matching logic isn't properly hw format aware, we have to declare vulkan as a supported sw format, which means that we can't separately check if the sw format is supported unless we do a second check within the filter. This really should be pushed up into the common logic. Basically, filters should be able to separately declare their supported input hw and sw formats. We might also need some additional logic to handle when the vulkan and cuda devices aren't the same hardware. I haven't looked at the failure paths yet. This basic approach could be used instead of hwmap for cuda to vulkan transfers, but there are complications: hwcontext will attempt a src->transfer_to() if available in preference to a dst->transfer_from() with no fallback if the transfer_to() fails. Without changes, that implies the cuda hwcontext must implement a transfer_to. The second complication as that you'd have two hwuploads but pointed to different hw devices, and I don't think you can specify a different device for each hwupload - I guess you'd need to add logic to hwupload to be able to init itself. (A workaround here would be to use hwupload for the cuda->vulkan and then hwupload_cuda for the vulkan->cuda but we really want to get rid of hwupload_cuda in the long term). Example command lines: $ ffmpeg -hwaccel nvdec -hwaccel_output_format cuda \ -init_hw_device cuda=cuda:0 -i sample.mp4 -filter_hw_device cuda \ -vf hwmap=derive_device=vulkan,scale_vulkan=w=640:h=480,hwupload \ -c:v h264_nvenc -f null /dev/null $ ffmpeg -hwaccel nvdec -hwaccel_output_format cuda \ -i sample.mp4 \ -vf hwmap=derive_device=vulkan,scale_vulkan=w=640:h=480,hwupload_cuda \ -c:v h264_nvenc -f null /dev/null As you can see, hwupload_cuda is significantly more concise as it can directly init a hw device by itself.
- Loading branch information
Showing
4 changed files
with
153 additions
and
31 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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