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...

    http://www.phoronix.com/scan.php?pag...Decode-H1-2020

  • tuxayo
    replied
    Okay this news is about exposing the dedicated decoding unit (ASIC).

    I got my hopes too high for something that might be unrealistic:
    Does anyone have a idea how feasible it would be to have AV1 or VP9 implemented using compute shaders or OpenCL or some parts of Vulkan, i.e. whichever non-video API available on modern GPUs that don't support yet these codecs?

    Because video engines are too specific, that's why hardware change is needed to have any acceleration for AV1 for example. And it takes a lot of time.
    So the aim is to achieve some level of acceleration that would make usable for example AV1 on some of the modern GPUs.
    The best thing that could happen it that would be enough to allow use on mobile device if such implementations are efficient enough.
    That would result in providing support of new codecs few GPU/SoC generation in advance compared to complete full ASIC-accelerated support. (Even if the support is not with the highest resolutions and framerates)

    Leave a comment:


  • agd5f
    replied
    Originally posted by ms178 View Post

    Thanks for this explanation. I see that this would leverage the cross-plattform and cross-vendor advantages of Vulkan to video encode/decode and should supersede the usage of OpenMAX, VA-API and VDPAU on Linux?!
    Well, it would provide another API for video acceleration. So you could use OpenMAX or VAAPI or VDPAU or Vulkan.

    Leave a comment:


  • ms178
    replied
    Originally posted by agd5f View Post

    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.
    Thanks for this explanation. I see that this would leverage the cross-plattform and cross-vendor advantages of Vulkan to video encode/decode and should supersede the usage of OpenMAX, VA-API and VDPAU on Linux?!

    Leave a comment:


  • agd5f
    replied
    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.

    Leave a comment:


  • schmidtbag
    replied
    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.

    Leave a comment:


  • log0
    replied
    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.

    Leave a comment:


  • miabrahams
    replied
    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.

    Leave a comment:


  • Shevchen
    replied
    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.

    Leave a comment:


  • ms178
    replied
    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).

    Leave a comment:

Working...
X