Imagination GPUs With PVR Vulkan + Zink Working Well For OpenGL 4.6

[microcode]

That’s the way to go.
Why bother using something else than Zink for gl ?

I hope they contribute in exchange though.

The current "why" is corner cases where OpenGL stuff doesn't map all that well, or any of the no-doubt hundreds of interesting niche circumstances where Zink is currently performing a lot worse than you'd want... but those are being worked out, and since they are actually trying to make it good, they'll also presumably do the work on the Vulkan driver side to give Zink the best possible opportunity to perform.

[microcode]

Vendor GL drivers can provide more useful things, for example, NVIDIA's proprietary GL driver supports GL_NV_mesh_shader

Zink can totally support GL_NV_mesh_shader, if anyone actually wants it. It exposes what are essentially Vulkan mesh and task shaders, and it doesn't look to me like there's that much in the NV_mesh_shader GLSL extension that couldn't be translated straightforwardly to SPV_EXT_mesh_shader... though there's also NVIDIA's own SPIR-V extension for this exact purpose so... a little bit cringe, and adds a couple extra things.

[edxposed]

Zink can totally support GL_NV_mesh_shader, if anyone actually wants it. It exposes what are essentially Vulkan mesh and task shaders, and it doesn't look to me like there's that much in the NV_mesh_shader GLSL extension that couldn't be translated straightforwardly to SPV_EXT_mesh_shader... though there's also NVIDIA's own SPIR-V extension for this exact purpose so... a little bit cringe, and adds a couple extra things.

Zink: support for GL_NV_mesh_shader

[Quackdoc]

Zink: support for GL_NV_mesh_shader

interesting, Im wondering if there are any applications that require the extension. listed was a mod

[edxposed]

interesting, Im wondering if there are any applications that require the extension. listed was a mod

I know of no other applications that require GL mesh shaders, but nvidium does reveal the potential of GL mesh shaders

[smitty3268]

I heavily disagree with the statement, It would be more accurate to say "zink will never have the same maximum efficiency that native driver could possible achieve given maximum optimization" and even with this im not sure I totally agree with the statement

It's inherent to the entire design, and there's no way of getting around it.

By definition, a native driver can always do the most efficient possible thing to provide support for GL on the hardware it's driving.

By definition, Zink must follow a set of restrictions based around what Vulkan provides, and it must manipulate things to work the way Vulkan wants it to work.

If the way Zink does things is most efficient, then by definition a native driver would just copy that and be equally efficient. The only possible way any differences make sense is if the Zink differences are the slower version.

Now that said, it doesn't mean in practice that a Zink driver won't outperform any given alternative. I'd say that OpenGL drivers are rather famous for being poorly optimized in many cases, which leaves plenty of opportunities for Zink to do better. Simply by having lots of effort put into it, it's probably got a leg up on a lot of hardware like Imagination where there hasn't been a bunch of optimizations going into OpenGL support, and it can even beat more heavily optimized drivers in some cases simply because the native drivers are doing something less than optimal. So if that's what you mean, then maybe we agree.

But by definition, that's a bug in the native drivers that could potentially be fixed to match Zink. If the difference is the other way, it can be a legit real barrier that can't be improved upon - or at least, not without changing the Vulkan spec to allow better matching what you need to accomplish. Which is certainly something that's already been done several times for Zink and other layered graphics support on Vulkan.

[Quackdoc]

It's inherent to the entire design, and there's no way of getting around it.

By definition, a native driver can always do the most efficient possible thing to provide support for GL on the hardware it's driving.

By definition, Zink must follow a set of restrictions based around what Vulkan provides, and it must manipulate things to work the way Vulkan wants it to work.

If the way Zink does things is most efficient, then by definition a native driver would just copy that and be equally efficient. The only possible way any differences make sense is if the Zink differences are the slower version.

Now that said, it doesn't mean in practice that a Zink driver won't outperform any given alternative. I'd say that OpenGL drivers are rather famous for being poorly optimized in many cases, which leaves plenty of opportunities for Zink to do better. Simply by having lots of effort put into it, it's probably got a leg up on a lot of hardware like Imagination where there hasn't been a bunch of optimizations going into OpenGL support, and it can even beat more heavily optimized drivers in some cases simply because the native drivers are doing something less than optimal. So if that's what you mean, then maybe we agree.

But by definition, that's a bug in the native drivers that could potentially be fixed to match Zink. If the difference is the other way, it can be a legit real barrier that can't be improved upon - or at least, not without changing the Vulkan spec to allow better matching what you need to accomplish. Which is certainly something that's already been done several times for Zink and other layered graphics support on Vulkan.

again, I disagree with the statement "Zink will always be less efficient than a native driver" which as I said, it's not accurate at all, and to make it accurate would be, and im summarizing it "Zink will never exceed the maximum potential of a native driver". which is something you reiterated on. even a "well optimized driver" could still have it's performance beaten by zink assuming well optimized vulkan driver and zink optimizations.

[coder]

You're both too smart to waste time nit-picking each other on such a hypothetical argument over degrees rather than basic facts. It won't change how well or poorly Zink or any OpenGL driver ultimately performs. ...so, with no stakes and more agreement than disagreement, why bother?

[Quackdoc]

You're both too smart to waste time nit-picking each other on such a hypothetical argument over degrees rather than basic facts. It won't change how well or poorly Zink or any OpenGL driver ultimately performs. ...so, with no stakes and more agreement than disagreement, why bother?

the only other thing I have to waste my time on till tommorow is TV

[smitty3268]

You're both too smart to waste time nit-picking each other on such a hypothetical argument over degrees rather than basic facts. It won't change how well or poorly Zink or any OpenGL driver ultimately performs. ...so, with no stakes and more agreement than disagreement, why bother?

I've said my piece and stand by it 100%. There's not much more to say at this point.

I do agree that Zink has the potential to beat native drivers in practice, fwiw. So we agree at least partially.