Zink OpenGL-On-Vulkan Now Nearly At ~69% Of Intel's Native OpenGL Driver

[mdedetrich]

I think, the main purpose of this are less mainstream projects. AMD, Nvidia, and Intel all provide decent OpenGL drivers for their hardware and usually those native drivers should outperform a translation layer running on a Vulkan driver. However, OpenGL in itself is much more complex than Vulkan and many implementations have non-standard behavior to deal with. This leads me to believe that smaller efforts for some SoCs without comprehensive driver support on Linux will benefit the most since they can now work on a simpler, smaller, and more straight-forward Vulkan driver and get OpenGL for free by sacrificing some performance.

Although theoretically a native OpenGL driver should beat a wrapper over Vulkan, I think in practice this may not be the case. There were already some cases I read where Zink was beating native OpenGl because Vulkan was developed with multi-threading in mind so its easier to leverage when writing a layer ontop.

Also Vulkan is really low level, its almost like an immutable low level assembler for graphical GPU's so I would be suspicious if there was a big difference.

[nokipaike]

I suspect that if it exceeds 100%, only vulkan with zink will soon be supported, with the abandonment of the development of the official opengl drivers

[GruenSein]

Although theoretically a native OpenGL driver should beat a wrapper over Vulkan, I think in practice this may not be the case. There were already some cases I read where Zink was beating native OpenGl because Vulkan was developed with multi-threading in mind so its easier to leverage when writing a layer ontop.

Also Vulkan is really low level, its almost like an immutable low level assembler for graphical GPU's so I would be suspicious if there was a big difference.

It is a question of optimization. There is no reason why an OpenGL driver should not be multi-threaded while talking directly to the hardware. In theory, there is nothing a native OpenGL-driver cannot do that is possible in Vulkan since the OpenGL driver could theoretically reimplement the Vulkan driver as a private internal API. If anything, Vulkan is a slight restriction versus native access to the hardware. However, there might be many very simple and ill-optimized drivers that could end up slower than a modern implementation on top of Vulkan.

Also, we need to be careful with the "multi-threading focus" of Vulkan. It is my understanding that a Vulkan APPLICATION can more dynamically do things in parallel because Vulkan is more flexible and low level. This is something that an OpenGL application can only do to a certain degree. Whatever happens within the OpenGL driver can be as parallel as the hardware will allow. This is not something that Vulkan enables in particular.

[jntesteves]

Considering that most OpenGL workloads are getting old, and that hardware kept getting faster since, this performance level is already appropriate for a final product, given the necessary stability and features are provided. Really astounding progress!

[Azpegath]

Wait, SuperTuxCart uses compute shaders? That's quite unexpected, considering its "graphic fidelity", even though I am aware that they have modernized their OpenGL usage.

[mdedetrich]

It is a question of optimization. There is no reason why an OpenGL driver should not be multi-threaded while talking directly to the hardware. In theory, there is nothing a native OpenGL-driver cannot do that is possible in Vulkan since the OpenGL driver could theoretically reimplement the Vulkan driver as a private internal API. If anything, Vulkan is a slight restriction versus native access to the hardware. However, there might be many very simple and ill-optimized drivers that could end up slower than a modern implementation on top of Vulkan.

Sure, this the same reason why I used the word "theoretically". Its theoritically possible that if graphics card companies made a new OpenGL implementation from scratch with the learnings that have happened over the decades that it could be really fast, but this is not gonna happen.

Also, we need to be careful with the "multi-threading focus" of Vulkan. It is my understanding that a Vulkan APPLICATION can more dynamically do things in parallel because Vulkan is more flexible and low level. This is something that an OpenGL application can only do to a certain degree. Whatever happens within the OpenGL driver can be as parallel as the hardware will allow. This is not something that Vulkan enables in particular.

This is half of the story, there are other reasons why Vulkan is much better for multi-threading is that the main OpenGL context uses global state and many OpenGL drivers were built this way (this gets to my earlier point). If you ask a lot of game devs about doing multi-threading in OpenGL, a lot of them would have not nice things to say. OpenGL was made in the 70s (iirc) and back then everything was your typical "C based global state" style program and the API reflected this.

Vulkan on the other hand uses immutable data structures and takes a much more "functional" approach (i.e. no global state). This makes it much easier for both the driver/library and the library users.

Being low level helps but its not the full story, the API is also much better in this regard.

[camel_case]

That's why I love open source 😊
But can someone tell me please , what is this driver aiming to replace? It's a improvement of open source Intel GPU driver, yes? It will render OpenGL through newer Vulkan? Why would this be required or needed?
Thanks.

OpenGL will be a legacy api in future. There will be no need to develop an Vulkan *and* OpenGL implementation for coming gpu architectures.

[You-]

Another big thing is that after a long freeze (probably due to last release?) patches now are being merged against upstream. Merged patches now declare support for OpenGL3.3.

[R41N3R]

Another big thing is that after a long freeze (probably due to last release?) patches now are being merged against upstream. Merged patches now declare support for OpenGL3.3.

Zink commits are dominating Mesamatrix now ;-) Nice, OpenGL 3.3 in main mesa and I hope that the other patches to bring it even up to OpenGL 4.6 will be reviewed as well in time for the next Mesa feature freeze.

[CommunityMember]

OpenGL will be a legacy api in future. There will be no need to develop an Vulkan *and* OpenGL implementation for coming gpu architectures.

While that may be the direction in the long run, until the major commercial vendors (the adobes, the autodesks, etc.) support vulkan throughout their product line to the same extent that they currently support OpenGL the GPU vendors will create drivers for their commercial base where the best OpenGL performance makes the sale. While different, think how long it has taken Wayland to displace X.