Hacker News Reader

Comment by marcodiego | Hacker News Reader

Now combine this with Zink and boom! We get OpenGL 4.6 for free: https://www.phoronix.com/scan.php?page=news_item&px=Zink-Clo... .

Vulkan is too low level, but AFAICS it is not something one use directly, instead a library which uses it as a back-end should be used.

View on HN

> Now combine this with Zink and boom! We get OpenGL 4.6 for free

For the RPi4 specifically:

That GPU has hardware limitations that make it unable of OpenGL 3.0. However, it supports GLES 3.2.

If you want GL desktop minus the unsupported features by the hardware, you can set MESA_GL_VERSION_OVERRIDE=3.3 for example. That will however never be compliant.

Vulkan has many extensions to allow it to work on hardware which doesn’t support the full feature set. (by not implementing them, instead of having only version numbers)

I wonder what specifically the GPU missing that OpenGL needs.

The OpenGL 3.0 spec mandates support for 8 render targets, the RPi4 GPU only has support for 4.

When you say render targets, do you mean drm buffers? Or on GPU output buffers?

I'm not quite completely clueless, but I have the feeling that clarification on this point will nudge me in the right direction to understanding these things better.

GL_MAX_DRAW_BUFFERS

The Pi hardware may not support multiple render targets or other features in hardware directly but Zink is not required to (and does not always) emit 1 Vulkan API call for each OpenGL API call. It is free to issue as many as are needed to properly emulate the OpenGL API in a conformant way. That being said I don't think this particularly compatibility is in Zink today but there is nothing preventing it from being possible just because the hardware couldn't create the render targets all in one shot.

> but Zink is not required to (and does not always) emit 1 Vulkan API call for each OpenGL API call

The OpenGL driver also doesn't have to emit 1 logical hardware operation for each OpenGL API call.

There is no hard technical requirement for hardware drivers but it's riskier to expose performance impacting emulation at that level vs the layered driver level (where Zink is). For instance imagine a case where the hardware supported 4 MRTs but the hardware driver emulation layer exposed 8 MRTs for OpenGL compatibility yet Zink needed to use 16 MRTs. Now you've got all sorts of translation happening where Zink is likely calling the lower emulation layer multiple times rather than just calling the hardware directly. Such emulation layers are expected in a layered driver, that's part of their actual intent, whereas base hardware drivers are meant to expose what the hardware is able to do natively and let you work around it otherwise.

You can already enjoy stuff like OpenGL 2.1 support on purely GLES 2.0 hardware this way - for instance on older Raspberry Pis. There's not much Zink will bring on the table that Gallium doesn't already when it comes to emulation of missing hardware features (at least not if you want them to actually perform in any reasonable way).

Ideally, shouldn't zink query the vulkan driver for what capabilities the hw has, and then expose an appropriate OpenGL version?

Unconditionally exposing the latest GL version by emulating missing GPU functionality sounds like a recipe for applications to fall off performance cliffs.

I've always wondered how this would work. Surely if it was possible to reasonably implement OpenGL 4.6 on the PI GPU it would already be done through Mesa.

Reply on news.ycombinator.com