After ~70% FPS Boost For Zink, The OpenGL-on-Vulkan Code Is ~50% The GL Native Speed

[rawr]

I am not the honorary editor but: Blumenkratz? (scratching flowers)

I'm not entirely sure if you were pointing that out but the name is actually Blumenkrantz which means floral wreath.

[George99]

Blumenkrantz which means floral wreath.

You're right. Normally I don't care about spelling mistakes but the missing n changes the meaning to something funny. (If you speak German)

[ShFil]

Emulation layer cannot be as fast as the native implementation that properly utilizes the underlying hardware. Previously some people said the Vulkan implementation allows for skipping some redundant error checks, but that is only one slight theoretical improvement, whilst there must be a ten-fold amount of drawbacks.

You make a wrong assumption here. It's not about emulating aka having the exact same behavior like other software, but to match the same specification. So under the hood it can do less and achieve the same results.

[blackshard]

I don't see the point on this.

I remember the 3dfx days, when voodoo hardware hasn't a native OpenGL implementation, but an OpenGL to Glide wrapper.

Something like this Zink.

That wrapper costed performance to the voodoos.

I remember a press note of one 3dfx manager saying that the next drivers they'll do will be native OpenGL because of this.

Too late I "Zink"

It depends a lot on the underlying library.

Vulkan is a very low-level API, which is ideal if you want to build something at higher level, such as OpenGL. OpenGL instead is a giant state machine that abstracts a lot of the underlying features and capabilities of the hardware.

Of course making an OpenGL driver directly on the hardware will make it much faster because you can access all the features of the hardware, but it is also a lot more of work to create the driver and also to maintain it when the underlying hardware changes.

[rawr]

You're right. Normally I don't care about spelling mistakes but the missing n changes the meaning to something funny. (If you speak German)

Spelling of names do not always coincide with the spelling of regular words. Did you actually want to hint at the error (his name is actually Blumenkrantz) or just at the fun of the changed meaning?

The correct spelling of the word itself would be Blumenkranz (without the t). I speak German.

[Venemo]

I don't see the point on this.

I remember the 3dfx days, when voodoo hardware hasn't a native OpenGL implementation, but an OpenGL to Glide wrapper.

Something like this Zink.

That wrapper costed performance to the voodoos.

I remember a press note of one 3dfx manager saying that the next drivers they'll do will be native OpenGL because of this.

Too late I "Zink"

The point is that, in theory, if Zink gets good enough, then future GPU vendors don't need to implement an OpenGL driver anymore, just Vulkan, and Zink would give them OpenGL “for free”.

We already see examples of this on Windows, where a few vendors don't want to invest in OpenGL anymore. That is why Microsoft is now contributing an “OpenGL on DX12” layer in mesa.

[microcode]

I think Zink can do very well and I'm excited to see the performance loss to trend toward zero, then toward negative infinity. :+ )

[rawr]

You make a wrong assumption here. It's not about emulating aka having the exact same behavior like other software, but to match the same specification. So under the hood it can do less and achieve the same results.

Strictly speaking he would be right. An ideal specialised native driver will always be faster than a driver that has one more abstraction layer, since that abstraction layer might prevent certain optimizations or just is slower because of one more indirection.
In reality drivers will have their own abstractions in there and depending on the architecture, some workloads will always be preferred to others.

In the long run I would expect Zink to have comparable performance with a better GL implementation overall (given that the Vulkan specification and implementation are good enough)

Sounds like that would be ideal for WebGL (I'm not a fan of it)

[R41N3R]

I don't see the point on this.

I remember the 3dfx days, when voodoo hardware hasn't a native OpenGL implementation, but an OpenGL to Glide wrapper.

Something like this Zink.

That wrapper costed performance to the voodoos.

I remember a press note of one 3dfx manager saying that the next drivers they'll do will be native OpenGL because of this.

Too late I "Zink"

Intel and radeonsi required years of development to reach their current state, so it is obvious that Zink will be slower than a native driver. But what if the OpenGL driver doesn't exist yet or is in a bad state? Then Zink would speed up the time to develop drivers massively as you could just focus on a Vulkan only driver and get OpenGL (+OpenGL ES) for free. This is the main advantage of Zink from my point of view.
If Zink works reasonably well, I would probably use it as well instead of Intel/radeonsi as long as the frame rate will be OK.

[aufkrawall]

Mostly in select few games, when running under Windows, on AMD cards, due to bad Directx drivers. Generally, no. When running games in Wine under Linux, the performance hit is still very noticeable, in all games, often exceeding 50%. Many of the core components of Wine were written 20+ years ago, for old Pentiums, and they lack support for both multicore architectures and modern CPU instructions. This is also the reason why native Vulkan games tend to get a severe performance hit, like DOOM (2016) does.

50% performance hit is only with Nvidia in select titles, it's usually hardly more than 15% with Radeons (and often far less).
Doom (2016) runs faster in Wine than on Windows with Radeon when GPU bound, while CPU bound performance probably doesn't differ much...