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

[curfew]

It can be, let's assume there's vulkan driver and corresponding part of opengl driver (doing the same), so If vulkan's driver is better quality then it's possible to achieve better results.

This is not magic and in no way thanks to the Vulkan emulation layer. I presume the most likely benefit is working around shitty OpenGL drivers that are too buggy, not that they would be too slow, though. And I do not know which particular hardware is in this state, as Vulkan support is very new and not available on those older graphics cards that right now are known to be shitty.

[curfew]

Correct me if I'm wrong, but the main benefit of Zink is that if successful it would allow all driver and hardware development to eventually forget about complex OpenGL conformance, and just focus on simple Vulkan primitives. All standards like OpenGL become hardware-agnostic software issues.

...in the hypothetical universe where any technical curiosity restricted to Linux would affect what the mainstream market will do. But this is probably what will eventually happen once the performance hit (or OpenGL itself) becomes irrelevant. It is comparable to how Intel is already emulating some ancient x86 instructions in their processors in exchange for simplifying / optimizing the hardware architecture.

[curfew]

(For example drivers of vk/dx12/mantle allow to use opportunity of having more than one core to achieve more draw calls.)

OpenGL does not allow for that because it is impossible to be both multithreaded and in compliance with OpenGL. Therefore Vulkan's multithreading is out of reach when emulating OpenGL.

[oiaohm]

OpenGL does not allow for that because it is impossible to be both multithreaded and in compliance with OpenGL. Therefore Vulkan's multithreading is out of reach when emulating OpenGL.

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.1-Better-GLTHREAD

To be horrible correct Opengl standard does not really have any clear statements on multithreading.

https://www.khronos.org/opengl/wiki/OpenGL_and_multithreading

Its fairly much left down to the platform to write platform particular rules. So technically zink could add platform unique features to allow more Vulkan multi-threading in opengl for aware applications and still be in compliance with OpenGL

Opengl compliance is just passing the OpenGL test suite that is only going to test out single threaded stuff.

It not impossible to be in compliance with Opengl and multithreaded but the fact this equals having own implementation features means existing applications can need to be hand picked or only for new applications to use multi-thread features.

[wertigon]

It not impossible to be in compliance with Opengl and multithreaded but the fact this equals having own implementation features means existing applications can need to be hand picked or only for new applications to use multi-thread features.

This. Just because it doesn't map to multithreading 1-to-1, does not mean it is impossible or even infeasible to use multiple cores to speed up the pixel pushing.

Exactly how that should be done I have no clue, but it's not unheard of to have old ideas finally come back again because now we have the technology to implement such ideas. Fifteen years ago the idea of dedicating a single computer core to doing OS stuff was seen as laughable, today it is increasingly common on 8+ core systems.

[mangeek]

Emulation layer cannot be as fast as the native implementation that properly utilizes the underlying hardware.

I think that with Gallium, everything is -already- being translated to an intermediary format. It's not like the software is sending OpenGL right to the hardware. I think you're right that Zink won't end up being as fast as OpenGL, but it might end up being -fast enough- to justify having a single 'OpenGL-on-Vulkan' path that always works well inside a bunch of 'Vulkan-on-hardware' implementations rather than a bunch of 'OpenGL-on-hardware' and 'Vulkan-on-hardware' implementations.

[mangeek]

comparable to how Intel is already emulating some ancient x86 instructions in their processors in exchange for simplifying / optimizing the hardware architecture.

I believe this started back in the 1990s with the Pentium Pro/i686. My recollection was that the i586 and below were straight-up CISC processors, but the i686 sort of decoupled things and -emulated- a CISC CPU in microcode while everything really ran on a RISC-ish core with microcode.

[Amaranth]

I believe this started back in the 1990s with the Pentium Pro/i686. My recollection was that the i586 and below were straight-up CISC processors, but the i686 sort of decoupled things and -emulated- a CISC CPU in microcode while everything really ran on a RISC-ish core with microcode.

I think you're mixing up micro-ops and microcode. There is dedicated hardware in the chip for converting most x86 instructions in to micro-ops, microcode is a much slower programmable emulation of instructions.

[rmfx]

50 percent of native driver speed with such a new project and all the mesa abstraction stuff, that leaves a good hope for a non-mesa base wrapper and further optimizations.

[rawr]

I think you're mixing up micro-ops and microcode. There is dedicated hardware in the chip for converting most x86 instructions in to micro-ops, microcode is a much slower programmable emulation of instructions.

Isn't microcode defining which micro-ops to use for an instruction?