Vulkan 1.3.274 Released With Video Encode Extensions Promoted

[phoronix]

Phoronix: Vulkan 1.3.274 Released With Video Encode Extensions Promoted

As what's likely to be the last Vulkan API spec update before Christmas, Vulkan 1.3.274 was released today with the Vulkan Video encode extensions promoted as well as adding some other new extensions as a nice end-of-year gift...

https://www.phoronix.com/news/Vulkan-1.3.274-Released

[timofonic]

Now Vulkan Audio and let OpenAL rest in peace, please.

Vulkan Audio is a **proposed** extension of the Vulkan API for audio processing, similar to its graphics and compute capabilities. However, Vulkan Audio **does not exist** yet, and audio APIs are **diverse and platform-specific**. Most game developers use **middleware** like Wwise and FMOD to simplify audio programming. Some developers may want a more **direct and cross-platform** approach, like OpenGL or Vulkan for graphics.

OpenAL is **not popular** and **slowly developed**. It **lacks** features like lowpass filters, stereo spatialization, and omni-directional blending.

XAudio2 has a **different volume curve** than OpenAL, which may **change the sound loudness**. It also has **latency issues**.

Vulkan Audio could be a **potential solution** for the audio API problem. It could provide a **consistent, cross-platform, and high-performance** way of handling audio, like Vulkan does for graphics and compute.

However, Vulkan Audio would also have **many challenges**, such as defining a common audio format, supporting various audio devices and backends, and integrating with existing middleware and engines. Until then, developers have to **choose** between the existing audio APIs, or use middleware to **simplify** their audio development.

Vulkan Audio could be based on **open technologies** like IAMF.

Vulkan Audio could **extend** SPIR-V for audio.

[binarybanana]

Why the need for separate extensions for different codecs? Why not an API that let's you query available codecs?

[Gusar]

Why the need for separate extensions for different codecs? Why not an API that let's you query available codecs?

Vulkan is very low-level. So you can't handle a codec without knowing its distinct features. Which are described in those separate extensions.

[ermo]

Does Vulkan encoding run on the GPU shader engines, thus making it a more generic solution, at the cost of (quite possibly) using more power...?

I would kind of enjoy my older GPUs being able to decode the stuff that isn't supported in their fixed-function decoders by just using the GPU shaders instead?

[Quackdoc]

Does Vulkan encoding run on the GPU shader engines, thus making it a more generic solution, at the cost of (quite possibly) using more power...?

I would kind of enjoy my older GPUs being able to decode the stuff that isn't supported in their fixed-function decoders by just using the GPU shaders instead?

no. it uses asic still, like vaapi

[mbriar]

Does Vulkan encoding run on the GPU shader engines, thus making it a more generic solution, at the cost of (quite possibly) using more power...?

I would kind of enjoy my older GPUs being able to decode the stuff that isn't supported in their fixed-function decoders by just using the GPU shaders instead?

You wouldn't need new vulkan extensions to implement the decoding in shaders, vulkan already allows you to fully program the shader pipeline. What you're asking would be for drivers to ship boat loads of shader code, which should be the applications/libraries responsibility (if it's really desirable at all compared to just decoding it on the cpu)

[Quackdoc]

You wouldn't need new vulkan extensions to implement the decoding in shaders, vulkan already allows you to fully program the shader pipeline. What you're asking would be for drivers to ship boat loads of shader code, which should be the applications/libraries responsibility (if it's really desirable at all compared to just decoding it on the cpu)

and preform black magic, it's not impossible to parallize a video stream decode, but to that extent...

[piotrj3]

Now Vulkan Audio and let OpenAL rest in peace, please.

Vulkan Audio is a **proposed** extension of the Vulkan API for audio processing, similar to its graphics and compute capabilities. However, Vulkan Audio **does not exist** yet, and audio APIs are **diverse and platform-specific**. Most game developers use **middleware** like Wwise and FMOD to simplify audio programming. Some developers may want a more **direct and cross-platform** approach, like OpenGL or Vulkan for graphics.

OpenAL is **not popular** and **slowly developed**. It **lacks** features like lowpass filters, stereo spatialization, and omni-directional blending.

XAudio2 has a **different volume curve** than OpenAL, which may **change the sound loudness**. It also has **latency issues**.

Vulkan Audio could be a **potential solution** for the audio API problem. It could provide a **consistent, cross-platform, and high-performance** way of handling audio, like Vulkan does for graphics and compute.

However, Vulkan Audio would also have **many challenges**, such as defining a common audio format, supporting various audio devices and backends, and integrating with existing middleware and engines. Until then, developers have to **choose** between the existing audio APIs, or use middleware to **simplify** their audio development.

Vulkan Audio could be based on **open technologies** like IAMF.

Vulkan Audio could **extend** SPIR-V for audio.

Vulkan Audio, when it could work, it would require all audio related companies join group and discuss how it should work. When all GPU makers are kinda eager to join Khnosos group under Nvidia leadership, audio related companies are totally diffrent. Vulkan and Vulkan video have easier times since most companies were already on board with OpenGL in the past.

[shmerl]

What's going on with AV1 Vulkan video?