ZINK: OpenGL Over Vulkan Comes As New Mesa Gallium3D Driver

[L_A_G]

Also, you could get a recent version of OpenGL on Mac through MoltenVK. You can more easily port a GL game onto, say the Switch. (I don't remember if it supports OpenGL API at the OS level, but it does support Vulkan, I think. I might have that backwards.)

The Switch does support OpenGL, up version 4.5 at launch and it could be up to 4.6 as the drivers are derived from the same common codebase all of their other drivers are derived from, so the whole Switch API premise falls apart then and there.

Also, if you're familiar with graphics hardware and how it's been evolving for the last decade you'll know that hardware bring-up isn't that heavy in new code, only new drivers for new APIs. The main foundations of the drivers stay the same as new hardware is rarely anything beyond an evolution of previous hardware and even when whole new architectures come out, there's going to be at least one common hardware abstraction layer between the hardware and API, meaning that most of the work is going to be done for every API you support once that hardware abstraction layer is done.

[L_A_G]

...

If you've paid any attention to when AMD adds support for new hardware into AMDGPU, not just new driver features, you've seen that the amount of the new code for a new set of hardware isn't even that big. Not only that, most of the code is creating paths for the hardware abstraction and features, which are replicated across APIs meaning that once you've gotten new hardware to run glxgears, you're almost done getting the Vulkan equivalent to run as well.

Considering the low level nature of the Vulkan API I really doubt it does anything to vendor-specific differences in drivers except exacerbate the issue. MoltenVK currently only has to run on top of Apple's own Metal drivers meaning that there's not that much that's variation in how things are implemented even when running on different hardware.

[kenjitamura]

What's worse, on the desktop only AMD GPUs have a sane Gallium drivers. ILO (Gallium3D driver for Intel GPUs) is already dead, and everyone knows the quality of Novueau...

Wasn't there an article recently about Intel starting to work on Gallium drivers and there was a lot of speculation they'd start using Gallium for their drivers once they release their GPU's in 2020?

Google brought up the article I was thinking of:

[pal666]

Should this be(come) performant and complete, graphics driver makers will only need to write a vulkan driver to support everything including OpenGL instead of having their own or even another mesa openGL driver implementation.

no, they still have to write opengl driver if they want fast opengl. what subj can achieve is to run opengl apps on non-opengl platforms. and even on non-vulkan platforms via vulkan-over-something

[pal666]

Currently AMD (who currently support 5 versions of GCN) have to write 5 OpenGL drivers, 5 Vulkan drivers, 5 DirectX 9 drivers, 5 DirectX 10 drivers and 5 DirectX 11 Drivers*. And then the hundreds of game specific patches need to be implemented 5 times each (assuming each game only supports one API).

If these conversions layers work out being as good as native

if pigs will fly. btw, amd does not write driver for each gcn version and amd does have conversion layer named pal
isn't if funny that average phoronix commenter does not like adding abstraction layers when hears dc, but likes adding much larger abstraction layers when hears vulkan?

Another advantage is that currently the drivers have a lot of hacks in order to incorporate every game specific patch, AMD tried to fix a bug in one game a few months ago and broke the game specific patches for a 15 year old game engine in the process. With these conversions layers you can store multiple versions, so that if a game has a really broken DirectX 9 implementation you can create a specific version for that game and always use that version for that game without the need to add the patches to the mainline.

what makes you think those hacks were not in conversion layer?

[pal666]

Yes, but do you think they want to keep writing new OpenGL driver code every time a new device comes out?

nobody writes new opengl driver. opengl is already written in mesa, what you have to write is hardware-specific part, with which subj does not help

[profoundWHALE]

I'd hate to sound like I'm being overly negative here, but I fail to see the point in this.

Because then AMD, Nvidia, and Intel only have to focus on their Vulkan implementation and the OpenGL, Directx, and Metal applications will work great.

[Spazturtle]

nobody writes new opengl driver. opengl is already written in mesa,

No mesa on windows, so they still need to write an OpenGL driver for Windows.
In comparison the Vulkan driver (AMDVLK) is shared by both Windows and Linux.

what you have to write is hardware-specific part,

So you do have to write a new driver then (even if you are basing it off existing code).

with which subj does not help

It will because you won't need to write any hardware specific code for OpenGL to work, as OpenGL would be converted to Vulkan and use the Vulkan driver. Effectively this means GPU vendors can pretend OpenGL doesn't exist, whilst keeping OpenGL supports as good or better then it currently is. Once all these conversion layers get to a good point GPU vendors will only need Vulkan support in their drivers and all other APIs will be converted.

[DrYak]

I'd hate to sound like I'm being overly negative here, but I fail to see the point in this.

And that's why Gallium was born...

With the current situation, for each new piece of hardware you need to write 2 low level things.
- You need to write a Vulkan driver (vulkan is a sort of standardized low-level API to begin with)
- You need to write a Gallium back-end (mesa's own low-level API to build drivers on top).

With the direction Zink is heading to, you would only need support for Vulkan as a low-level API, and build high-level API upon this base.

So it saves dev time. (Only one low-level component to write instead of two)

Also helps for future hardware that might not have released docs yet. Most of the upcoming GPUs are bound to have Vulkan support. Mesa could as well target that as a back-end.

No mesa on windows, so they still need to write an OpenGL driver for Windows.

Just for the record, after the 3Dfx company bankrupted most of the OpenGL drivers developed by the community for Voodoo cards were based on Mesa. (but using Glide as a back-end. This predates the Gallium back-end infrastructure, so there wasn't much code sharing between mesa3d driver and most other variants).

In comparison the Vulkan driver (AMDVLK) is shared by both Windows and Linux.

And Android, too.
(Thus vulkan could be used as a back-end for OpenGL / DirectX /etc. for UBPorts, etc.)

[the_scx]

With the direction Zink is heading to, you would only need support for Vulkan as a low-level API, and build high-level API upon this base.

That's not true. Vulkan is not suitable for GPGPU (e.g. OpenCL) and video decoding/encoding (VDPAU, VA-API, etc.). Gallium can handle both. Of course, the best solution would be Germanium, which I mentioned earlier. Unfortunately, this would require rewriting everything again.

And Android, too.

Yeah, right...

https://upload.wikimedia.org/wikipedia/commons/f/fe/Gallium3D_example_matrix.svg