Originally posted by polarathene
View Post
New Intel Mesa Driver Patches Implement AV1 Decode For Vulkan Video
Collapse
X
-
-
-
i imagine gstreamer will probably query for available vulkan video extensions (which in turn should only be available if there's a compliant driver and hardware in the machine) and fallback to its other code paths when that's not available
this would likely allow gstreamer devs to focus on the codepath selection logic, the codec APIs translation/generalization and specifics, software fallback decoding logic... while optimal code for specific hardware becomes driver-level work behind a common cross-vendor API with proper definition, compliance testing, etc
afaik gpus that don't have an asic for video encoding/decoding might still implement it in their driver over the available shaders and whatnot and expose this under the vulkan video API, thus making this a natural "best available option" API
and i bet lavapipe will also end up implementing some vulkan vidro over CPU codepaths that may leverage AVX and such as available and applicable
which means at some point targeting this API might be all you really need in gstreamer and the likes of it, game engines, or even directly in apps
imho probably the biggest benefit of this being done as a vulkan API extension (beyond having proper API governance, documentation, visibility, etc) is that encoding/decoding codepaths become driver development, so this gets done by devs who understand the hardware and are better positioned to optimize for it, while app logic stays in userland with app devsLast edited by marlock; 29 December 2024, 11:28 PM.
Comment
-
-
Originally posted by marlock View Posti imagine gstreamer will probably query for available vulkan video extensions (which in turn should only be available if there's a compliant driver and hardware in the machine) and fallback to its other code paths when that's not available
this would likely allow gstreamer devs to focus on the codepath selection logic, the codec APIs translation/generalization and specifics, software fallback decoding logic... while optimal code for specific hardware becomes driver-level work behind a common cross-vendor API with proper definition, compliance testing, etc
afaik gpus that don't have an asic for video encoding/decoding might still implement it in their driver over the available shaders and whatnot and expose this under the vulkan video API, thus making this a natural "best available option" API
and i bet lavapipe will also end up implementing some vulkan vidro over CPU codepaths that may leverage AVX and such as available and applicable
which means at some point targeting this API might be all you really need in gstreamer and the likes of it, game engines, or even directly in apps
imho probably the biggest benefit of this being done as a vulkan API extension (beyond having proper API governance, documentation, visibility, etc) is that encoding/decoding codepaths become driver development, so this gets done by devs who understand the hardware and are better positioned to optimize for it, while app logic stays in userland with app devs
Comment
-
Comment