Raspberry Pi's V3DV Vulkan Driver Can Now Run The Zink OpenGL Translation Layer

[mo0n_sniper]

This is a Linux/open source news site and is reporting news about open source technologies. Myself and probably others are interested in Zink, if you are not interested you can ignore the news article.

[Ladis]

Wait, what? I always thought the GPU supported OpenGL 4.x. It's kinda weird to me that it doesn't support it but supports Vulkan (not saying that supporting Vulkan is bad thing of course). I'm just genuinely surprised.

Vulkan is low-level, so it's many times faster to write the driver.

In future Zink will be the only way to run old OpenGL software on newer hardware. It isn't going to be worth writing both a Vulkan and an OpenGL driver.

Yes, especially when OpenGL is not only developed anymore (OpenGL Next = Vulkan), it will not even be on many future hardware:

1. On macOS it's deprecated and will be removed in a future version (like we had with 32bit recently). Zink + MoltenVK will be the free opensource way to run OpenGL (next to the commerical closed source MoltenGL).

2. On Windows 10 on ARM desktop OpenGL will be via Zink to Direct3D driver API translation (I think we even had an article here how Microsoft is cooperating with Zink on bringing OpenGL to Windows 10 on ARM).

I don't worry about the performance, because that's only a CPU overhead. And those are faster and faster each year (much faster than the legacy software was made for). Been there done that - we had it with 3D API wrappers for decades (e.g. emulating 3Dfx Glide, or OpenGL on the first generation of 3D cards, which could do only Direct3D).

[_ONH_]

Are they gonna help hooking OpenGL 3.1 ES to Zink. So they could run the whole android ecosystem over their Vulkan driver. Stressing the full hw capability out.

[You-]

In the far, far away future, and only maybe.

MasOS is ahead of the game here. Zink may be the only generic way to get OpenGL to work properly on it and people are working on making that work now.

[sykobee]

It is an issue with HW limits. Videocore VI hw only supports up to 4 multiple render targets.
For OpenGL ES that is enough, as the minimum value for GL_MAX_DRAW_BUFFERS is 4 (see table 6.27 on OpenGL ES 3.0 spec).
But for OpenGL 3.0 that is not enough, as the minimum value for GL_MAX_DRAW_BUFFERS is 8 (see table 6.51 on OpenGL 3.0 spec).

Let's hope that in the next RPi SoC they fix this up, amongst other things. But that's a year away at least I would hazard to guess.

[brent]

You can also compare if you want Zink with DXVK / D9VK. They reached close to native speeds quickly, because they do direct translation from DirectX to Vulkan.

DXVK isn't that efficient either. It just manages to hide the overhead well with multithreading, so the performance impact is often rather low, particularly with a many-core CPU. But it still burns many CPU cycles, increasing power consumption.

[camel_case]

Michael please stop chanting every other day about Zink. It is an extremely inefficient solution and I will risk, an uneducated, analysis this problem has a fundamental basis. It is based on the architecture of Gallium. For this reason I predict that a performance similar to the DXVK will never reach. It's a good experiment but let's not go over it.

I think it will be the future for many future drivers, specially for SoC-GPUs. Not because it is technically the best solution. But you do not develop 2 drivers.
With Zink OpenGL is just done if have vulkan. Thats the benefit for small developer teams. And OpenGL is nothing else as legacy, future implementations are waste of rare ressources ...

[zoomblab]

An uneducated guess is as good as taking a shit on the keyboard and let the feces do the talk.

Maybe, but I sproke about uneducated analysis - not guess. I am a programmer myself. Though I haven't taken the time to study the code, I have lets say an intuition about on the matter. Plus, so far what I say is correct. The architecture is doomed to be inefficient. You can also compare if you want Zink with DXVK / D9VK. They reached close to native speeds quickly, because they do direct translation from DirectX to Vulkan.

[brent]

In future Zink will be the only way to run old OpenGL software on newer hardware. It isn't going to be worth writing both a Vulkan and an OpenGL driver.

In the far, far away future, and only maybe. There is an inherent overhead associated with translation layers like Zink and that overhead will only become acceptable at large if OpenGL becomes much less relevant than it is today. Since Vulkan is not a direct replacement for OpenGL, that's unlikely to happen any time soon.

I agree that Zink gets more coverage than warranted. Nobody really needs this project right now or in the near future. It's basically a technology experiment.

[OneTimeShot]

Michael please stop chanting every other day about Zink. It is an extremely inefficient solution and I will risk, an uneducated, analysis this problem has a fundamental basis. It is based on the architecture of Gallium. For this reason I predict that a performance similar to the DXVK will never reach. It's a good experiment but let's not go over it.

In future Zink will be the only way to run old OpenGL software on newer hardware. It isn't going to be worth writing both a Vulkan and an OpenGL driver.