Vulkan 1.2.196 Introduces H.265 Encode Extension

[phoronix]

Phoronix: Vulkan 1.2.196 Introduces H.265 Encode Extension

Arriving back in April were the initial Vulkan Video extensions that included support for video decode of H.264 and H.265 while the initial video encode support was limited to H.264. Out today with Vulkan 1.2.196 is the new extension allowing for H.265 encoding with this new industry-standard video API...

https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.2.196-H265-Encode

[cytomax55]

Is there any idea when AMD will get this feature

Is this something that could help AMD encode videos to h265 and compete with Intel's quicksync in terms of performance?
Right now if you want to set up a Plex or emby server and Intel CPU with quick sync makes more sense than an AMD chip I wonder if this would make a difference

[Danny3]

I wonder if Steam could use this in the future on powerful enough systems to capture and stream games in high quality.
I hope for decode extensions, at least VLC will take advantage of them one day since for browsers like Firefox will probably take about 10 years to use them since they are too busy destroying to layout and adding spyware and adware.

[agd5f]

Is there any idea when AMD will get this feature

Is this something that could help AMD encode videos to h265 and compete with Intel's quicksync in terms of performance?
Right now if you want to set up a Plex or emby server and Intel CPU with quick sync makes more sense than an AMD chip I wonder if this would make a difference

AMD already supports VA-API (same as Intel) and OpenMAX. You could expose the video encode/decode hardware via Vulkan, but it would just be exposing it via a different API.

[rmnscnce]

Is there any idea when AMD will get this feature

Is this something that could help AMD encode videos to h265 and compete with Intel's quicksync in terms of performance?
Right now if you want to set up a Plex or emby server and Intel CPU with quick sync makes more sense than an AMD chip I wonder if this would make a difference

Is there any idea when AMD will get this feature

I suppose so. FWIW the (currently proprietary) AMD AMF is an implementation of Vulkan video using private Vulkan extensions[?]. That's why one should load the AMDVLK-PRO Vulkan ICD to enable AMD AMF support for OBS Studio (an amf_h264-supporting FFmpeg build is required ) on systems having both RADV and AMDVLK-PRO. [citation needed for all of my words there, I don't have the links for references at hand right now]

[aufkrawall]

AMD already supports VA-API (same as Intel) and OpenMAX. You could expose the video encode/decode hardware via Vulkan, but it would just be exposing it via a different API.

In obs-studio xcomposite window grab, VAAPI real time capturing on the same GPU that renders the game unfortunately has very bad performance with AMD VAAPI driver. It's basically unusable when the GPU is maxed out and you don't want to have just 10fps stutter video. xcomposite might not be optimal, yet it works much better with Nvidia (and probably also Intel VAAPI driver).

[Guest]

I wonder if this could be useful for ALVR (SteamVR for Oculus Quest headsets on Linux)

[timofonic]

I hope Vulkan one day gets totally equivalent t9 all VA-API and other similar APIs. One API to dominate all video.

Then I hope someday "Vulkan 3" appears and does the same with audio, OpenAL situation is a joke right now.

Then "Vulkan 4" to get all SDL-like features...

[sophisticles]

Hardware acceleration on AMD GPU's has been available on Linux for a while:

https://gpuopen.com/advanced-media-framework/

However, as is the case with Windows, if you want the best available consumer grade GPU powered video encoding and processing, you go with either Nvidia or Intel.

The one thing to keep in mind is that AMD treats GPU powered accelerated encoding and video filtering as an afterthought because it is an afterthought to them, if it was up to AMD they wouldn't even bother designing and offering such a product because it hurts their cpu sales,

I know people like to rag on Nvidia in Linux circles but the truth is that we owe a huge debt to Nvidia. Back on the 2000's Nvidia expressed the desire to build and sell x86 based cpu's, but Intel blocked them. Nvidia claimed that the x86 chipset license they had from Intel allowed them to build x86 cpu's, Intel said no and Nvidia sued.

Intel gave Nvidia something like 300 million to settle the suit and Nvidia took that money and basically created the gpgpu market.

With their CIDA framework they release the first reference CUDA encoder and then they released nvenc, a fixed function chip built into their GPU's. This is what caused Intel to release quick sync with Sandy Bridge.

The reality is that cpu's for a long time have been fast enough to handle most people daily tasks, such as editing a Word document, surfing the web, playing their web based games, playing 1080p 3d games, most Excel sheets, or audio editing.

The reality is that on the desktop the only really heavy tasks that need lots of cpu power, in terms of cores, is 3d rendering and video encoding and editing, which is why AMD trots out Blender, Cinebench and Handbrake benchmarks when they introduce a new Threadripper.

AMD has made the decision to compete with Intel on "more cores" at any given price point, so they are not about to release anything that in anyway invalidates that argument. AMD wants you to believe that you need a 12C/24T $500 cpu + $100+ motherboard to encode video via Handbrake, imagine what it would to to the sales of their high end desktop cpu's if they release a $100 4C/8T APU with excellent hardware video encoding and filtering.

Intel is in a similar position, but they have more motivation to release high quality hardware encoders because intel can't compete, or won't compete, in the "more cores" battle, so they have released great quality hardware encoders to go against Nvidia's nvenc.

I think AMD will regret their strategy in the long run. Yes they have made a lot of money and gained significant market share with the "more cores" strategy, but just like adding cylinders to a car engine, there is only so far that you can go.

AV1, which is poised to take over, is extremely computationally intensive, software encoding and decoding is not an option at most resolutions. Intel's dGPU is said to have hardware AV1 encode, so AMD will definitely find themselves in a disadvantage.

[dec05eba]

In obs-studio xcomposite window grab, VAAPI real time capturing on the same GPU that renders the game unfortunately has very bad performance with AMD VAAPI driver. It's basically unusable when the GPU is maxed out and you don't want to have just 10fps stutter video. xcomposite might not be optimal, yet it works much better with Nvidia (and probably also Intel VAAPI driver).

thats also an issue with obs-studio itself. Obs-studio uses xcomposite, then it copies the opengl window texture to the cpu and then sends it back to the gpu, which can be very heavy when your system is maxed out playing games. Its only on windows that obs-studio skips these copies, even though its also technically possible to do so on linux.