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

[phoronix]

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

The V3DV Vulkan driver that provides support for the Raspberry Pi 4 and newer can now run the Zink OpenGL-on-Vulkan translation layer...

http://www.phoronix.com/scan.php?page=news_item&px=Zink-With-Raspberry-Pi-V3DV

[zoomblab]

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.

[jojo7887]

Zink on V3DV allows for OpenGL 2.1 support to be exposed, which is the maximum desktop OpenGL version supported by the Raspberry Pi hardware

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.

[jntesteves]

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.

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

[andre30correia]

>>>the VideoCore VI GPU can do OpenGL ES 3.2, but it can’t do OpenGL 3.0,
> Can you give a bit more details on this issue?

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

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

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

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

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

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