Vulkan 1.2.200 Released With Two New Extensions

[smitty3268]

So those extensions don't implement any extra logic, only provide direct way to some underlying hardware circuit in graphics card that otherwise would be inaccessible?

That certainly could be the case sometimes.

I'm not completely sure exactly what this does, but from what I gather the driver programs the hardware to use certain coordinate ranges, and these ranges differ between GL and Vulkan (which matches what D3D expects). So Zink has to basically convert everything from one coordinate system that GL uses to another one the vulkan driver expects, which means everything is getting an extra calculation along the way. This extension will prevent that by making the vulkan driver (and hardware) expect the same ranges that the GL userspace in zink is providing.

Take all that with a grain of salt, I'm not very familiar with that part of graphics systems.

[Daktyl198]

Vulkan is reaching the point of OpenGL levels of fragmented extensions, except with a way more confusing versioning system. Can't wait for the Linux Vulkan drivers to fall behind the same way OpenGL did.

[dark_sylinc]

Vulkan is reaching the point of OpenGL levels of fragmented extensions, except with a way more confusing versioning system. Can't wait for the Linux Vulkan drivers to fall behind the same way OpenGL did.

Most of these extensions ARE implemented because the Linux drivers needed them (like this one for layers like Zink, or VK_VALVE_mutable_descriptor_type for emulating D3D12 on top of Vulkan). So I don't think so.

Also it would be crazy to depend on VK_VALVE_mutable_descriptor_type because that extension basically is "whatever Proton needs", so any use outside that case could run into bugs.

Also, these extensions are fairly specific for emulation layers. They're not meant to be used by most games or apps.
Many of these extensions don't even make sense implementing them on Windows for example.

The situtation with 2000-era OpenGL is different because developers would need a vendor extension to access basic state of the art GPU features while D3D9 was officially offering it out of the box.
These Vulkan extensions instead are miscellaneous and niche.

If Vulkan is so low level why those things cannot be implemented efficiently without extensions?

High/low level depends on where you're standing. For a microcode dev, even assembly language feels high level, let alone something like C. For a Python developer, C++ is already low level.

Vulkan is very low level compared to D3D11 and GL, but it doesn't give direct access to the HW.
Some parts were specifically left out because they're good defaults (e.g NDC range being [0; 1]) but turns out emulation layers need them (OpenGL uses the worse NDC range [-1; 1]).

The same thing happened with Transform Feedback. It is terrible and nobody should be using it, so it was left out.
But turns out you need it if you want to emulate OpenGL games that used it; and it is also useful for debugging (e.g. RenderDoc).
Hence VK_EXT_transform_feedback was added.

What we're seeing is just the result of tighter integration and coordination between drivers (Mesa with Intel & AMD) and user space SW (like Zinc or WINE/Proton) which is quite the opposite of the chaos that was in the 2000's and first half of 2010's.

[dark_sylinc]

I forgot to mention something: VK_ARM_rasterization_order_attachment_access is not niche (but specific to TBDR GPUs, aka Mobile). And something I've been asking since day 0.

It's nice to finally have it. Better late than never.

Anyway, it's not an extension that dramatically changes how we make graphics through Vulkan (unlike OpenGL's era where vendor extensions that introduced shaders in the era of Fixed Function Pipeline was a total game changer), but it's more like a couple of lines of code to get access to GPU state I've always wanted to have to improve performance.