Zink Lands Threaded Context Support For A Big Speed Boost With OpenGL Over Vulkan

[oiaohm]

You forget to mention than Zink was introduced less than 2 years ago and already achieved 60-70% of performance. OpenGL implementations were polished for more than 20 years. I think in 2 years it will be 90-100% already, if not more. Right in time when no new software will use this API and it will be needed only for backwards compatibility.

There will be a upper limit on what Zink can do.

https://www.supergoodcode.com/last-day/

The highest recorded benchmark with Zink is 95% and that most likely ideal route. 80-90% would be more of a realistic guess based on what the developer of Zink has already done. In a few years that could be good enough.

For example, I remember about such proprietary thing like MoltenGL - OpenGL ES implementation on top of Metal for Apple devices. They state it is capable of doing 3x performance of native drivers. Yes I know that native OpenGL is horrible on Apple devices and Mesa is very good, but it is possible to achieve the same and do even more in Zink.=

The reality here with MoltenGL is 3x performance of the broken to hell Apple provided Opengl. Windows and Linux running on the same Apple hardware doing Opengl stuff is faster by over 3x. MoltenGL if you are comparing to what the GPU in the Apple device can do under ideal conditions is about 80-90% so quite a bit down due to wrapping through Metal but does that mater when the vendor as in apple is no longer providing decent Opengl Drivers..

Molten stuff example why Zink does not need to make it to 100 percent performance as they are example for 80-90% being good enough. 80-90% is more of a realistically possible value with enough slack that it should be achievable.

[oiaohm]

60-70% is cool. Is it possible for Zink to reach 100% performance?
Is it possible for Zink to exceed 100% of native OpenGL drivers?

It depends on the driver you are benchmarking against. Zink even with Vulkan to metal overhead should exceed the Apple native Opengl drivers of old at current 60-70% by over 2x faster and if Zink gets to 80-90% you will be looking at MoltenGL performance. Lets just say Apple native opengl drivers were pure garbage this results in a wrapper being way faster than native.

Zink vs other Mesa Gallium drivers it very unlikely that it will get to 100% performance 95% would Zink doing well. The problem here is any improvement that Zink does to the Galluim driver core get shared with the other Mesa Gallium drivers so its really hard for Zink to get ahead and all the overhead going though Vulkan shows.

There is a still the problem will reaching 100% matter. If lets say Valve decides that all games its providing are only tested with Mesa Gallium driver and mandates that having a Nvidia closed source driver that can go faster will not matter right on Linux. Remember the steam runtime could by Valve contain zink and when it detects Nvidia use Zink. At that point 90-80% where the programs work vs 100% where the programs don't work you can bet the users will choose the 90-80% like they did with Glide.

[cl333r]

70% is definitely not enough and it will never be. I believe Zink can (and will) achieve much, much better results.

Agreed, there's probably no low hanging fruit anymore so speed increase from now on will come at a greater effort.

[oiaohm]

Agreed, there's probably no low hanging fruit anymore so speed increase from now on will come at a greater effort.

Not quite there are still known performance boosting patches that are not mainline mesa yet but are Zink development. 90-80% would be realistic possibility with the out standing patches against other gallium drivers. 98% would be a hell lot of work and past that is may never happen.

[schmidtbag]

Zink was known to have pretty bad performance recently, right? If so, I'm a little concerned about this. Multi-threading is great to have, but we don't want it compensating for otherwise unoptimized code. Think of it like this:
If Zink reaches a point where a decently powerful CPU (such as a 5900X) can get Zink to around 100% native performance, that's a bit misleading because the CPU could be doing all the heavy lifting, and get people to think "oh I guess Zink is well optimized" until you use a lesser CPU.

But, as long as the devs are aware of this don't aren't treating multi-threading as an alternative to optimizing, then all is good.

[oiaohm]

Zink was known to have pretty bad performance recently, right? If so, I'm a little concerned about this. Multi-threading is great to have, but we don't want it compensating for otherwise unoptimized code. Think of it like this:
If Zink reaches a point where a decently powerful CPU (such as a 5900X) can get Zink to around 100% native performance, that's a bit misleading because the CPU could be doing all the heavy lifting, and get people to think "oh I guess Zink is well optimized" until you use a lesser CPU.

But, as long as the devs are aware of this don't aren't treating multi-threading as an alternative to optimizing, then all is good.

The reality here is opengl drivers on Linux does use threading in background. One of the things about moving to vulkan is having to do the threading support in your application instead of dumping it on opengl. Zink it depends on what branch how good or bad its performance has been. Mesa mainline branch has been way behind and this was partly this lack of threading. So Zink has basically had one hand tied behind it back. The threaded contexts also applies to multi threads inside the GPU so hand serous-ally tied behind back for Zink in Mesa mainline without this feature why such a huge boost.

[_ONH_]

But, as long as the devs are aware of this don't aren't treating multi-threading as an alternative to optimizing, then all is good.

It's stupide to assume they're not.
Even more if one has read several times the original blog posts.

Short: the zink devs work on all components involved to reduce the cpu overhead. This while mainlaining all the zink patches.

[GruenSein]

To me, Zink is more about Hardware enablement than driver replacement. Replacing RadeonSI with Zink does not make any sense, since in theory there is nothing Zink could do that a native driver couldn’t. However, looking at the various ARM SoCs with little to no open source support, this might be a game changer. They‘d only have to implement a somewhat simpler Vulkan driver and get OpenGL for free, which is absolutely sufficient for anything apart from gaming (Desktop composition, some simple visualization, generell GUI acceleration). Think about Linux phones where driver support is massively lacking.

[tildearrow]

60-70% is cool. Is it possible for Zink to reach 100% performance?
Is it possible for Zink to exceed 100% of native OpenGL drivers?

Wait 2 years, and you'll see...

[You-]

AFAIK DXVK can get over 100% performance at the expense of extra CPU useage,

Zink may also be able to do the same, especially if threading is easier this way compared to the native drivers.

Even if it doesnt, it is still turning out to becoming a solid fallback solution that people will be able to rely upon. AFAIK in many cases it is already better than proprietary alternatives.

(I read some stuff recently about the proprietary MoltenGL actually not being as good as advertised. Zink may overtake it there. Recent benchmarks of Swiftshaders also shows deficiencies that would have been exposed in the OSS world on every phoronix article "its not ready yet. Why dont we stick to try and tested Open GL native drivers?" etc)