Zink OpenGL-On-Vulkan Seeing Some 50~100% FPS Gains

[wertigon]

Hardware has changed but OpenGL hasn't. Whatever the specification is, any implementation has to obey to even all the "stupid things" in it, too, limiting possible performance on a more capable hardware. It does not matter which so-called platform the OpenGL implementation is built on top of.

Nono, see, that is the thing - OpenGL was built for a static pipeline that then got shoehorned into a shader pipeline (GL 2.0), and then Vulkan said "Screw pipelines, we're doing piecemeal production instead!" Old hardware didn't allow you to go straight to the end if all you cared about was wireframe meshs, for instance. Vulkan does - and such optimisation tricks can then be taken advantage of by a Vulkan OpenGL backend but not a native one, since the native one *has* to go from A to B to C to D to E.

Not saying this leads to speedups across the board, just that it should be possible to make an overall faster implementation.

I don't see how any of these Vulkan-enabled optimizations wouldn't be possible also using the underlying native instructions, unless of course vendors don't care about OpenGL performance anymore and haven't bothered with it.

Because OpenGL mandates the hardware works a certain way, while Vulkan adds a superset of that, if my understanding is correct anyhow. Feel free to correct me, certainly not an expert here in any way, shape or form.

[smitty3268]

How Zinc is different from DXVK for example? There are lots of examples when gaming on Linux is faster than super native API support in Windows. Redesigning super old API over modern graphics stack can lead to unobvious optimizations. For example, using multithreading properly without ugly external hacks.

It's different because Zink shares the exact same OpenGL code (gallium state tracker) that the native Mesa drivers use.

If a driver just absolutely sucks at something, then for sure an alternative implementation could be faster. But the native Mesa drivers and Zink will most likely share the exact same weaknesses and strengths since they share the same code. The backend side of things is going to be the same too. Only a little tiny piece in the middle of the driver is changing, and that's not in a good position to create any performance improvements.

Technically, I guess now that ACO is the default for radv that could result in performance gains vs radeonsi since it's not been hooked up for OpenGL use yet. But it doesn't appear that those gains are typically as large as I suspect the slowdown from Zink will be, and of course they are working towards adding ACO for radeonsi too.

[Zan Lynx]

Hardware has changed but OpenGL hasn't. Whatever the specification is, any implementation has to obey to even all the "stupid things" in it, too, limiting possible performance on a more capable hardware. It does not matter which so-called platform the OpenGL implementation is built on top of.

A Vulkan implementation of OpenGL can get away with dropping the error handling. Since it is Vulkan it has API layers, some of which are supposed to validate all of the API calls. Once your OpenGL application passes the verification layers cleanly those can be removed and the result should run faster.

[log0]

Old hardware didn't allow you to go straight to the end if all you cared about was wireframe meshs, for instance. Vulkan does - and such optimisation tricks can then be taken advantage of by a Vulkan OpenGL backend but not a native one, since the native one *has* to go from A to B to C to D to E.

I am confused. Are you comparing OpenGL on old hardware with OpenGL over Vulkan on new hardware?


On the same hardware a native OpenGL implementation will always as fast or faster than OpenGL over Vulkan, because it doesn't have to comply with Vulkan spec.

[wertigon]

I am confused. Are you comparing OpenGL on old hardware with OpenGL over Vulkan on new hardware?


On the same hardware a native OpenGL implementation will always as fast or faster than OpenGL over Vulkan, because it doesn't have to comply with Vulkan spec.

No, not necessarily. New hardware isn't designed with OpenGL in mind; it is designed with Vulkan in mind. Vulkan can remove quite a bit of the OpenGL overhead that the silicon has to move through. This is my perception of how it works, but I could be wrong about this.

1. GL was designed with the concept of Pipelines - First you do A, then B, then C, then D, then E.
2. Later on, GL was designed with shaders, which pretty much said, first you do whatever shader runs at A, then the one at B, then the one at C...
3. Then GL stopped being relevant as Mantle and later on, Vulkan came along - where you could say "Run A, then D. Screw the rest."

GL hardware must route data through a whole lot of hardware logic Vulkan doesn't have to route through. And since you can ignore all that logic, it might end up faster in the end for quite a few use cases. Of course, if what you want to do is "First do A, then B, then C, then D, then E", then GL wins out. This is my understanding of course - I might very well be dead wrong on this, like I said earlier.

[smitty3268]

A Vulkan implementation of OpenGL can get away with dropping the error handling. Since it is Vulkan it has API layers, some of which are supposed to validate all of the API calls. Once your OpenGL application passes the verification layers cleanly those can be removed and the result should run faster.

False.

Not if it's a valid OpenGL implementation it can't.

The OpenGL spec flat out says that the OpenGL driver must handle and return errors in a certain way. Therefore, Zink must implement that behavior as well. There is no shortcut - because the Vulkan side doesn't implement it, that just means Zink itself has to provide the error checking on top rather than relying on the underlying hardware driver to do it.

[smitty3268]

No, not necessarily. New hardware isn't designed with OpenGL in mind; it is designed with Vulkan in mind. Vulkan can remove quite a bit of the OpenGL overhead that the silicon has to move through. This is my perception of how it works, but I could be wrong about this.

You're mostly right about all that when it comes to pure Vulkan vs pure GL, but what you're missing is that Zink still has to implement all the OpenGL overhead, because it's still implementing the OpenGL API. It has to behave the same way, in order to be compatible with all the OpenGL apps out there (and the spec).

So while it's backend can do things in a more optimal vulkan way, the native OpenGL hardware drivers can also ignore OpenGL and do things in a more optimal (hardware-specific assembly code) way - they just build all the GL abstraction layer overhead on top. Which is the same thing Zink is doing - it's just that it's abstracting that backend over Vulkan, while native drivers run directly against the hardware. That means the native drivers are always going to be able to more directly deal with the hardware, making it more optimal - but Zink will run across all hardware that has Vulkan support, making it potentially a single implementation that could be shared across many gpus.

In that respect, you can think of it like Java vs C. A Java app might run faster than a C app if it was just coded better, but chances are the C app is likely going to be faster, or if it's not then the Java app will be pointing out exactly how the C app should be updated in order to make it faster. The hope behind Zink is that if it's close enough any performance difference won't matter, but expecting it to be faster is going to be a recipe for disappointment.

[wertigon]

You're mostly right about all that when it comes to pure Vulkan vs pure GL, but what you're missing is that Zink still has to implement all the OpenGL overhead, because it's still implementing the OpenGL API. It has to behave the same way, in order to be compatible with all the OpenGL apps out there (and the spec).

So while it's backend can do things in a more optimal vulkan way, the native OpenGL hardware drivers can also ignore OpenGL and do things in a more optimal (hardware-specific assembly code) way - they just build all the GL abstraction layer overhead on top. Which is the same thing Zink is doing - it's just that it's abstracting that backend over Vulkan, while native drivers run directly against the hardware.

With you so far, however:

That means the native drivers are always going to be able to more directly deal with the hardware

Yes. Indeed, if they do the exact same thing in the backend, Zink will be slower. But I still think it is possible to conform to the spec and leverage Vulkan since you will have access to more information in Vulkan than you will have in OpenGL.

You also make the assumption that AMD and Nvidia has taken their sweet time to optimize OpenGL to take advantage of their newer architectures. I am very skeptical that they have done this to a large extent. Instead, I am pretty confident they have done bare-minimum work to keep the OpenGL 4.6 compatibility, while focusing on a strong Vulkan/DX12 performance. At the end of the day it isn't really worth their time to optimize a good-enough OpenGL implementation when the world is slowly moving on to the next generation. They are companies, and companies must follow deadlines and plan their work. They do not have the luxury to send 5 top-talent engineers to tighten up the GL pipelines in the drivers, unless someone specifically pays for this.

Sorry for being stubborn here, I have dabbled quite a bit in emulation recently where you actually do a lot of shortcutting with modern architectures, and Zink is a form of emulation. I can agree to disagree here though, we both agree Zink is awesome and a Vulkan-only driver is desirable, performance hit or not. In the end only time will tell how good it can get.

[smitty3268]

Yes. Indeed, if they do the exact same thing in the backend, Zink will be slower. But I still think it is possible to conform to the spec and leverage Vulkan since you will have access to more information in Vulkan than you will have in OpenGL.

The only information it will have is what the application gives it, which is through the OpenGL interface. From there, it can internally track whatever it wants, but that's exactly the same thing the native drivers do too. Only again, the native drivers can track stuff native to the hardware, rather than through an (admittedly very low-level) abstraction layer.

Anyway, at the end of the day the only thing that will prove things conclusively is tests, and I do think those will be interesting. But I think it's noteworthy that the driver developers working on both radeonsi and zink both seem very clear that performance in zink will be slower, and I don't see any logical way it would be otherwise, at least in full games. There will likely be certain micro-benchmark type things where zink may just happen to score a win here and there.