Announcement

Collapse
No announcement yet.

Vulkan Video Decoding Coming In H1'2020, Ray-Tracing Progressing

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

  • Vulkan Video Decoding Coming In H1'2020, Ray-Tracing Progressing

    Phoronix: Vulkan Video Decoding Coming In H1'2020, Ray-Tracing Progressing

    The Khronos Group has posted their material from the SIGGRAPH 2019 graphics conference and includes some interesting updates on Vulkan and their ongoing efforts...

    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

  • #2
    Not that I'm against Vulkan video decode, but I personally would rather them prioritize encode.
    The progress on ray tracing is nice, though.

    Comment


    • #3
      Maybe now we can finally get all the drivers supporting the same API.

      Comment


      • #4
        Could you ask them about prioritizing gpus for render devices? Currently i have two vega64 in my system, and most games under vulkan run on the second gpu what have to send the frame to the primary to be sent out to screen, and its adding a lot of unnecessary latency. And just switching to that gpu not really help, because then the frame goes back to the first gpu what then sends it back to the second, so it adds even more latency...

        Comment


        • #5
          Originally posted by schmidtbag View Post
          Not that I'm against Vulkan video decode, but I personally would rather them prioritize encode.
          The progress on ray tracing is nice, though.
          I am just curious, could you elaborate why you'd prefer Vulkan video encode? Would it provide any benefits over NVENC / AMD VCN? I suppose they use compute shaders there? Isn't this a more power hungry approach in comparison to the dedicated IP blocks of the GFX vendors?

          I see more immediate benefits for the decode side, there the API landscape is so diverse across vendors and operating systems and would help especially Linux to have a vendor agnostic API for hw video decode that programs can use as a target. I could see Chromium finally adopting this new API and making the hw video decode experience on Linux better than today (some distros already use the VA-API patches, but that is a workaround and not the best solution).

          Comment


          • #6
            Sidestep: AMD has proposed their own RT-method (they posted a patent on this), which might get implemented in the next GPU revision. My hope/fear is, that the Vulkan API should be able to handle it in a more or less native way with close to zero overhead.

            If Khronos is building their general RT-approach based on the Nvidia implementation, then there might be (please tell me if I'm wrong) µArch dependencies fitting one vendor over the other - which we don't want - as Vulkan should be as agnostic as possible.

            While AMD could create their own Vulkan extension - we all know how this will play out: The majority of game studios will either take the gameworks implenetation on "classic" titles or the Nvidia/Vulkan one on Vulkan optimized titles. This might be a problem, if its based on the Nvidia RT-method, as compute pathways on future AMD hardware may be vastly different compared to the current RT-implementation.

            Either, we are too early for a generalized method - or I'm just wrong and it doesn't matter as AMD RT will be baked in hardware and the Vulkan-implementation is just a "wrapper" around the core RT-method, that every vendor will just have to natively mold into their hardware.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              Not that I'm against Vulkan video decode, but I personally would rather them prioritize encode.
              The progress on ray tracing is nice, though.
              The ratio of decode:encode usage of these APIs must be like 1000:1. A vast majority of encoding (mobile phones, cameras, major hosting sites like YT) is done with dedicated hardware not GPUs.

              Comment


              • #8
                Originally posted by miabrahams View Post

                The ratio of decode:encode usage of these APIs must be like 1000:1. A vast majority of encoding (mobile phones, cameras, major hosting sites like YT) is done with dedicated hardware not GPUs.
                I am pretty sure this is about exposing dedicated hardware decoders/encoders through Vulkan. I imagine it will allow you to encode/decode directly into Vulkan allocated memory.

                Comment


                • #9
                  Originally posted by ms178 View Post
                  I am just curious, could you elaborate why you'd prefer Vulkan video encode? Would it provide any benefits over NVENC / AMD VCN? I suppose they use compute shaders there? Isn't this a more power hungry approach in comparison to the dedicated IP blocks of the GFX vendors?
                  Because we already have bunch of video decoders, most of which seem incomplete or work fine even on low-end CPUs (and creating yet another decoder is not going to fix that). Not only are NVENC/VCN platform-specific, but not all of Nvidia's/AMD's devices support it either. I'd like to see a generic video-accelerated encode. To ask "isn't this a more power-hungry approach?" could be said of other decode methods (including Vulkan decode) too - it all depends on what you're comparing it to. The point of what I want is so if you don't have another option, you can still get good-performance encode.
                  I see more immediate benefits for the decode side, there the API landscape is so diverse across vendors and operating systems and would help especially Linux to have a vendor agnostic API for hw video decode that programs can use as a target. I could see Chromium finally adopting this new API and making the hw video decode experience on Linux better than today (some distros already use the VA-API patches, but that is a workaround and not the best solution).
                  Linux has 2 vendor agnostic APIs for video decode (VDPAU may have originally been centric to Nvidia but it isn't anymore). They're both insufficient, but that's because nobody is paying enough attention to them (and those who will are dividing their attention between them). So, what makes us think a new Vulkan decoder is going to be any different? Frankly, I don't blame devs for not giving them much attention. We also have several "good-enough" performing CPU decoders, which are becoming more and more relevant and many-core CPUs are becoming common. So, although I don't see a Vulkan decoder as a bad thing, I think it's just going to further divide developer attention.

                  Comment


                  • #10
                    Originally posted by ms178 View Post

                    I am just curious, could you elaborate why you'd prefer Vulkan video encode? Would it provide any benefits over NVENC / AMD VCN? I suppose they use compute shaders there? Isn't this a more power hungry approach in comparison to the dedicated IP blocks of the GFX vendors?
                    VCN is a hardware block. The encode and decode capabilities exposed by this hardware block are exposed today via multimedia APIs like OpenMAX, VA-API, and VDPAU. The vulkan extensions expose the video hardware engines like VCN through the Vulkan API similar to how we expose the compute and gfx hardware engines via the Vulkan API today.

                    Comment

                    Working...
                    X