Announcement

Collapse
No announcement yet.

Open-Source Radeon Driver Enables Support For Vulkan Video H.264/H.265 Encode

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by oleid View Post

    Okay, but the issue is not the API, is it?
    Not right in my opinion. I think ecology is also part of platform independence. Application developers don't have GPUs that supports Vulkan video drivers, so how do they add support for this?

    Or do you expect application developers to assist Mesa and NVIDIA in developing and fixing open source/closed source drivers?

    Note that only Intel 11th Gen+, AMD RDNA+ and NVIDIA Kepler+ support Vulkan video on Windows. Developers still have to maintain other paths as fallbacks.​
    Last edited by nyanmisaka; 11 April 2024, 08:20 AM.

    Comment


    • #12
      I really don't see vulkan living up to the inflated hopes a lot of people seem to have. I know a lot of people are excited for a "universal video encode/decode API" but I really don't think vulkan is it. Don't get me wrong, I'm personally very excited for it for a plethora of reasons. But I know say android isn't likely to support it any time soon. A lot of SBCs are unlikely to support it. I think it could be great to be used in a higher level API, but I don't think vulkan in isolation is it.

      Comment


      • #13
        Originally posted by oleid View Post

        Please elaborate: why would one not use a platform independent API
        AMF/VAAPI/QSVNVENC are indeed cross-platform API, support Linux and Windows.

        Originally posted by oleid View Post
        why is this API a toy?


        Because Vulkan doesn't have any advantages worthwhile for ISVs writing new hardware-accelerated backends. Performance? The bottleneck is in the hardware, not in the API. Cross-vendor APIs clearly do not outperform vendor-specific APIs in terms of quality. Features? The vulkan video doesn't even have a hardware video processing capability. Compatibility? Every program with hardware accelerated encoding use cases already has mature VAAPI/NVENC support, so why waste time adding a new backend with lower quality and fewer features? And Vulkan Video simply doesn't work on Windows, it's broken on every vendor.

        Comment


        • #14
          Originally posted by patrick1946 View Post

          They only disadvantage I see is that Vulkan is activating the 3D hardware. If you watch a video you don't that to be activated on a laptop. But maybe there is an other way.
          Vulkan Video does not expose any hardware video processing offload support, so video processing operations must be performed by GPU.

          Comment


          • #15
            Always good to see features that iGPUs can take advantage of in systems that also have dGPUs - helps make use of an otherwise idle chip while freeing resources from the more demanding task.
            I assume this works on GCN models too?

            Comment


            • #16
              Originally posted by edxposed View Post
              Because Vulkan doesn't have any advantages worthwhile for ISVs writing new hardware-accelerated backends. Performance? The bottleneck is in the hardware, not in the API. Cross-vendor APIs clearly do not outperform vendor-specific APIs in terms of quality. Features? The vulkan video doesn't even have a hardware video processing capability. Compatibility? Every program with hardware accelerated encoding use cases already has mature VAAPI/NVENC support, so why waste time adding a new backend with lower quality and fewer features? And Vulkan Video simply doesn't work on Windows, it's broken on every vendor.
              It does have advantages for a lot of stuff. Video processing is actually one of them. While indeed it doesn't expose, Vulkan does already have other processing extensions, for example https://registry.khronos.org/vulkan/...ocessing2.html

              And vulkan itself is already really useful for video processing thanks to frameworks like NCNN, it makes vulkan a great target for machine learning/computer vision stuff. So it could make a lot of sense there for cross compatible ML stuff. And ofc it also helps with just general usage, High quality video players such as MPV can use vulkan hwdec+vulkan rendering to get better performance then you would get out of vaapi + vulkan rendering.

              Comment


              • #17
                Originally posted by schmidtbag View Post
                Always good to see features that iGPUs can take advantage of in systems that also have dGPUs - helps make use of an otherwise idle chip while freeing resources from the more demanding task.
                I assume this works on GCN models too?
                Vulkan encode is currently VCN only. The VCE used on Polaris/Vega56/64 and older is not supported.

                Comment


                • #18
                  Originally posted by Quackdoc View Post

                  It does have advantages for a lot of stuff. Video processing is actually one of them. While indeed it doesn't expose, Vulkan does already have other processing extensions, for example https://registry.khronos.org/vulkan/...ocessing2.html

                  And vulkan itself is already really useful for video processing thanks to frameworks like NCNN, it makes vulkan a great target for machine learning/computer vision stuff. So it could make a lot of sense there for cross compatible ML stuff. And ofc it also helps with just general usage, High quality video players such as MPV can use vulkan hwdec+vulkan rendering to get better performance then you would get out of vaapi + vulkan rendering.
                  These things are still based on the GPU general-purpose compute and shader units, whereas hardware video processing is purely ASIC. If Vulkan doesn't have standardized support for ASIC video processing offload, it's just going to cause Firefox and Chrome to shy away from it because they're more focused on power efficiency. But TSG clearly has no plans to do so in the near future.

                  Comment


                  • #19
                    Originally posted by ahrs View Post

                    (macOS doesn't count. Get a real computer)
                    LMAO true

                    Comment


                    • #20
                      Originally posted by lu_tze View Post

                      AMF is not available in any open-source driver; why would any program use it at all?
                      Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


                      - AMF on Linux can now be used with AMD Pro Vulkan, and experimentally with RADV drivers

                      This release adds support for: Added native DX12 support for encoding and PreAnalysis Vulkan encoder became independent from Vulkan driver Switched to public Vulkan Khronos extensions for decoder ...



                      Comment

                      Working...
                      X