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

[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.

[Creak]

Thank you baryluk for all these explanations!

[Kano]

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

[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.

[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