Vulkan 1.3.284 Released With Another Extension To Help Zink

[QwertyChouskie]

But they have to implement those extensions, which may be like implementing a legacy feature, no?

It's still wayyyy less work than implementing the entirety of OpenGL's state tracking, sync mechanisms, etc.

[mcloud]

But they have to implement those extensions, which may be like implementing a legacy feature, no?

Only if you want a performance opengl driver on top of vulkan. If you dont need open gl or don't care that much of opengl's performance, you don't have to

[dragorth]

But they have to implement those extensions, which may be like implementing a legacy feature, no?

No they don't. Its an extension, not a required part of the spec. The ease to get to a working Vulkan compliant driver is much easier than to a compliant OpenGL driver, and then they can optionally implement the features they desire to use.

So, if they want to use Zink as an OpenGL layer, thereby having most of the work of a compliant OpenGL stack already written, they can focus on just the extensions that make it performant.

Now, for the big 3, Intel, AMD, and Nvidia, they can forgo this in their closed source drivers, for instance, as they already have compliant and performant OpenGL drivers made.

The Open Source Drivers tend to get everything feature, but that is still at the discretion of the developer.

Where might this be useful? In any of the mobile chips with included GPUs like the Pi and other devices, they can implement just the base layer to be compliant and run most software.

If they want that OpenGL layer, they can then just implement what Zink requires.

There are lots of other extensions that don't make sense on them, like that ones that make Wine faster with DXVK and friends, they may never implement.

[ranixon]

But they have to implement those extensions, which may be like implementing a legacy feature, no?

In addition to what dragorth said, the OpenGL driver is way more complex than Vulkan, it does a lot of background job to make software development easier. From Nvidia

OpenGL does a lot in the background, from very simple things such as error checking, compiling high-level shaders, to avoiding deletion of resources that are still used by the GPU (which operates asynchronously) or managing internal resource allocation and hardware cache flushing. Another example is the handling of out of memory situation, where the OpenGL driver implicitly splits up workloads or moves allocations between dedicated/system memory. This code now moves from the driver into the application domain.

Source

So for a hardware developer POV, it's easier to support only Vulkan with some extension for OpenGL emulation, than a full featured OpenGL driver. Also, since OpenGL is more complex, compatibility layer like Zink is better, since it's a single software for various GPU vendors and simpler Vulkan drivers for each vendor, than a complex OpenGL driver for every GPU vendor. So in the future they can simply stop developing OpenGL and go full Vulkan.

[LockedPotato]

But they have to implement those extensions, which may be like implementing a legacy feature, no?

Implementing a few more extensions is a hell of a lot faster than making an entire separate driver.

[ssokolow]

But they have to implement those extensions, which may be like implementing a legacy feature, no?

Think of it like that Wine NT synchronization primitive patch for the Linux kernel. It's faster than emulating it in userland and much less complex than implementing the whole Win32 API in the Linux kernel.

(Yeah, I know much of the Win32 API is userland DLLs. The point remains. Wine and Zink can both be shared between multiple consumers, be they drivers or OSes.)