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

  • agd5f
    replied
    Originally posted by marlock View Post
    about (3)... isn't vulkan already offering plenty zero-copy functions? can't any of them be used?
    Not sure what you had in mind, but if you use shaders, you'll need to read in the unscaled YUV image from the video decoder and write out a scaled RGB image for display; that is your extra copy.

    Leave a comment:


  • marlock
    replied
    about (3)... isn't vulkan already offering plenty zero-copy functions? can't any of them be used?

    as for "no apple", aren't they offering some (Metal) Video API that can be used by MoltenVK as a Vulkan Video API translation target
    Last edited by marlock; 21 April 2024, 05:34 PM.

    Leave a comment:


  • agd5f
    replied
    Originally posted by dec05eba View Post

    Vulkan video doesn't touch the graphics rendering pipeline. It uses the dedicated video encoding/decoding unit on the gpu that is separate from the graphics. But when it comes to playing videos you want to use your graphics cards 3d processing anyways. That allows your gpu to decode the video and display the video directly without copying it to system ram. The video encoding/decoding unit uses the graphics cards ram so the 3d graphics unit can access it directly. It's the most power efficient and performant way to play a video.
    Mobile devices (such as laptops) also support low power video encoding/decoding mode (and graphics) to use even less battery.
    Sort of. Most video decode hardware outputs an unscaled YUV image. You need to scale it and convert it to RGB to see it on the screen. There are several ways to do that:
    1. Use planes on the display engine. This is the most power and bandwidth efficient; you can just point a plane at the raw YUV image and the display hardware will scale and handle the CSC. This is not well supported in most compositors at this point, but that will hopefully change in the near future.
    2. Use a fixed function scaling/CSC engine. Vulkan doesn't currently support these. This is more power efficient than shaders, but still requires an additional copy. APIs like VA-API support these today.
    3. Use shaders to do the scaling/CSC. This is unfortunately the least power and bandwidth efficient as you have to power up the shader hardware and there is an extra copy to do the scaling and CSC. Vulkan supports 3D and compute queues. This is the most likely way vulkan applications would handle this today.

    Leave a comment:


  • patrick1946
    replied
    Originally posted by dec05eba View Post

    Vulkan video doesn't touch the graphics rendering pipeline. It uses the dedicated video encoding/decoding unit on the gpu that is separate from the graphics. But when it comes to playing videos you want to use your graphics cards 3d processing anyways. That allows your gpu to decode the video and display the video directly without copying it to system ram. The video encoding/decoding unit uses the graphics cards ram so the 3d graphics unit can access it directly. It's the most power efficient and performant way to play a video.
    Mobile devices (such as laptops) also support low power video encoding/decoding mode (and graphics) to use even less battery.
    Allmost all laptops have and integrated GPU and the new Intel CPU put the 3D engine on a different isle. So if I watch a video in full screen which I do very often it would be handy if it is skipping the composition.

    Leave a comment:


  • dec05eba
    replied
    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 doesn't touch the graphics rendering pipeline. It uses the dedicated video encoding/decoding unit on the gpu that is separate from the graphics. But when it comes to playing videos you want to use your graphics cards 3d processing anyways. That allows your gpu to decode the video and display the video directly without copying it to system ram. The video encoding/decoding unit uses the graphics cards ram so the 3d graphics unit can access it directly. It's the most power efficient and performant way to play a video.
    Mobile devices (such as laptops) also support low power video encoding/decoding mode (and graphics) to use even less battery.
    Last edited by dec05eba; 14 April 2024, 01:55 PM.

    Leave a comment:


  • dec05eba
    replied
    Originally posted by edxposed View Post
    This makes no sense, any serious program would continue to use AMF/VAAPI/QSV/NVENC and not switch to this toy.
    There is a huge benefit to using this on nvidia at least. If you use nvenc then the driver will use cuda internally which reduces your gpus performance because the driver will lock the power level state to max - 1 and there is no way to disable that. That decreases performance in games while recording (on my gtx 1080 that reduces fps by 10%) and it also prevents your gpu from going to a lower power level state when the gpu can easily handle decoding the video.

    Leave a comment:


  • lu_tze
    replied
    Originally posted by agd5f View Post

    AMF uses the same underlying hardware as VAAPI or Vulkan Video and uses the same kernel code. AMF is just an AMD specific API.
    Nobody claimed otherwise; the claim was, that in order to use AMF, you need to have proprietary binaries installed, which basically nobody has. For distributions like Debian or Fedora, they are not even supported.

    So as an API for linux apps, AMF is pretty useless. Compared to that, user's won't have any problems with VAAPI or Vulkan Video, no need to tinker with their systems.

    Leave a comment:


  • piotrj3
    replied
    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.
    that is pretty much always activated.

    Also in case of Nvidia there is actually one more benefit - NVDEC actually does use CUDA to certain level and driver puts clocks high when CUDA load is detected. Vulkan Video doesn't have that issue.

    Leave a comment:


  • M.Bahr
    replied
    Originally posted by edxposed View Post

    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.
    Actually i would like to see a focus on flexible gpgpu and compute shaders for video processing apis. Hardwired video codecs are a pain when it comes to backwards compatibility. Developers hate fixed function gpu "features" by the way due to the aforementioned reason. And yes i know that ASIC fixed function blocks are more efficient. But FPGAs come close as a viable alternative.
    Last edited by M.Bahr; 12 April 2024, 06:24 AM. Reason: typos

    Leave a comment:


  • agd5f
    replied
    Originally posted by lu_tze View Post

    Exactly; you linked to AMF#457 which spells it out: you need the AMF runtime, which is shipping with the proprietary AMD drivers. You could try to install the proprietary packages and run them on the top of RADV, experimentally.

    So VAAPI/Vulkan is still better API to use. Your users are more likely to have the requisite packages installed and your app would work out of the box.

    I don't understand what AMD intends to achieve with this. Intel doesn't hide their media engine, it is open source (edit: not fully; some interesting bits are hidden in the GuC firmware).
    AMF uses the same underlying hardware as VAAPI or Vulkan Video and uses the same kernel code. AMF is just an AMD specific API.

    Leave a comment:

Working...
X