Zink OpenGL-On-Vulkan Lands Tessellation Shader Support In Mesa 21.0

[baryluk]

FYI. Tessellation just got fixed, and is working as intended. It was just a minor difference between Vulkan and OpenGL defaults, that were super easy to address (just hard to find it out that it is the problem). https://gitlab.freedesktop.org/mesa/..._requests/8274

[oiaohm]

Zink being where it is makes the idea of GTK/Qt VK backends much more practical / sensible. Even if the performance stalls where it is, it's already long since past the point of being able to drive a 2D desktop.

EDIT: I realised that comment is very badly phrased and could be read backwards. What I was trying to say is that the original disclaimer on Zink no longer really applies, and going forwards it appears to be at the stage where new HW only really needs a VK driver and Zink for (at least) a DE to run without problems. That's valuable, as a VK driver is a tiny fraction of the work of a full GL driver, and MAY be light enough to persuade a few more IHVs to actually deliver one.
Obviously it doesn't help the worst offenders - the types who don't even bother to release register / interface specs etc. But it may still speed up the bring-up of whatever the next ?Mali? or whatever is. Hopefully.

There is a problem. Not all GPU can support Vulkan well. There are some GPU that will be just better served by direct opengl there are presumes with Vulkan about the gpu providing decent memory management and not really needing a global state that a opengl based driver does not have to support.

This is one of these horrible ones on decent GPU designs with modern features designed into the silicon doing a vulkan driver is less work than doing a opengl driver this is true. But when you get into the modern GPU designs that don't really have modern features that have been design to save every square mm of silicon they can it can be less work to do a open source opengl driver. Kind of in the same way that Zink is able to develop quickly.

I do agree that Zink will be helpful with a lot of GPUs to reduced how much badly made vendor code you have to use. But its not going to be 100 percent magic bullet.

Yes your common vendors if the design is newer than 2014 you fairly much have decent vulkan support. Independent hardware vendor not exactly. Fabless manufacturing is the worry lets say you have paid for a GPU design that is kind of crap with a unlimited production license you are tempted to keep on using it. Good example is the Matrox G200eW Graphic design only designed in 1998 but still found on many motherboards new as the remote control screen. Yes the good old Matrox G200eW does not support modern features vulkan and its a uphill battle to make it work with Opengl.

You would be expecting that its going be more than 20 years before all newly made silicon with a GPU is vulkan compatible. The road in this department is a lot longer than we would wish.

[Kano]

The development speed is very impressive! Together with MoltenVK it seems even the only way to go for MacOS. Well done!

[Creak]

Thank you baryluk for all these explanations!

[arQon]

Zink being where it is makes the idea of GTK/Qt VK backends much more practical / sensible. Even if the performance stalls where it is, it's already long since past the point of being able to drive a 2D desktop.

EDIT: I realised that comment is very badly phrased and could be read backwards. What I was trying to say is that the original disclaimer on Zink no longer really applies, and going forwards it appears to be at the stage where new HW only really needs a VK driver and Zink for (at least) a DE to run without problems. That's valuable, as a VK driver is a tiny fraction of the work of a full GL driver, and MAY be light enough to persuade a few more IHVs to actually deliver one.
Obviously it doesn't help the worst offenders - the types who don't even bother to release register / interface specs etc. But it may still speed up the bring-up of whatever the next ?Mali? or whatever is. Hopefully.

[oiaohm]

66% will still be faster than being stuck with software rendering under Xwayland due to Nvidia not providing drivers.

90-95 on open source drivers I would say would be realistic top side zink vs open source Intel and amd drivers. Thing to remember as zink finds areas to improve things the other open source drivers in Mesa will learn from it so if Zink finds a 105% somewhere its likely in a generation of mesa drivers it will be back to 90-95%. Of course 90-95% is nothing to sneeze at.

There are a lot of cases where 66% is good enough like for a custom version of opengl for a old game depending on some horrible quirk of opengl that should never be implemented that way. Even at 90% there will be a lot of good enough cases. I really do wounder at 90% of performance does this cover 99.9% of the opengl use case well enough?

[baryluk]

baryluk do you think it is theoretically possible to go over 100%??

Maybe in 2022.

Right now the shaders go though the glsl -> tgsi/nir -> spirv -> nir -> aco ir -> isa. A lot of of context is loss, in the optimiser phases, or lack of them. Maybe some MESA vulkan extension could be made to feed directly nir back to radv, to improve a latency and performance a bit. This is really very low on priority list for foreseeable future.

Plus, any draw calls, and bindings stuff, goes though a lot of translation layers, adding a bit to CPU overhead. zink tries to cache a lot of stuff, but still, there will be some minor stutter here and there. This are at the moment something that can't be avoided, but In the future it could be improved.

I think 105% is possible. But that would require a lot of work, in the nir, optimiser, better memory allocator (it is now extremely primitive and naive). I think If we reach 90-95% consistently (on radv and anv), that would be a huge success. Once zink has fully working threading (it is there, just buggy), it could get further gains, in some games and apps, but again radeonsi is already doing really good job. The main maintainer of radeonsi is also primary author of NIR, and radeonsi is most optimized driver in Mesa, more so even than intel (who have more people maintaining it!).

I do expect the zink to show some over 100% (maybe 150%?) gains in some other drivers, like broadcom (Raspberry Pi 3, 4). But not necessarily.

I also hope the zink -> MoltenVK -> metal, and zink -> nvidia, or zink on Windows/WSL, could show some interesting performance benefits, and be faster than vendor provided OpenGL drivers in many cases. In fact it is very likely. This work is ongoing.

[Creak]

baryluk do you think it is theoretically possible to go over 100%??

[baryluk]

Don't be too excited yet. There is still few hundredth patches to go.

Also the tessellation kind of works, but is also broken with zink. https://gitlab.freedesktop.org/zmike/mesa/-/issues/22

But it will get fixed, no worries.

If you want to be excited, I can tell you that I measured about 75%-85% performance of radeonsi, when running zink+radv_aco, across variety of complex workloads. At least in highly GPU intensive stuff, indicating the generated shader code is still not as good as it could be. It can go as low as 66% on average, in less GPU bound scenarios. And multi threading support is broken at the moment. But, it is progressing. And we are squashing bugs, like (most) memory leaks, and (all) VRAM leaks, just get patched yesterday.

Considering that correctness were the primary goal initially, and there are some Vulkan optimisations, but almost nothing put into SPIR-V optimisations, it is a very good result. I am pretty sure we can get 95% performance of radeonsi, and maybe more in the future.

The formal review during merge request is going to probably find few extra bugs here and there.

For anybody curious, testing zmike/zink-wip branch, is really recommended.

Also if you want to compare performance with mangohud, be sure to take a look at this patch https://github.com/flightlessmango/MangoHud/pull/443

[camel_case]

I am loving how quickly this is all coming together

True! Just ~500 new lines but big impact!