3 ms·

> 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

by my123 5y ago

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

jdc 5y ago
I wonder what specifically the GPU missing that OpenGL needs.
- my123 5y ago
  The OpenGL 3.0 spec mandates support for 8 render targets, the RPi4 GPU only has support for 4.
  - salawat 5y ago
    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.
    - my123 5y ago
      GL_MAX_DRAW_BUFFERS
zamadatix 5y ago
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.
- seba_dos1 5y ago
  > 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.
  - zamadatix 5y ago
    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.
    - seba_dos1 5y ago
      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).
jabl 5y ago
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.

by my123 5y ago

jdc 5y ago

I wonder what specifically the GPU missing that OpenGL needs.

my123 5y ago
The OpenGL 3.0 spec mandates support for 8 render targets, the RPi4 GPU only has support for 4.
- salawat 5y ago
  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.
  - my123 5y ago
    GL_MAX_DRAW_BUFFERS

zamadatix 5y ago

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.

seba_dos1 5y ago
> 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.
- zamadatix 5y ago
  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.
  - seba_dos1 5y ago
    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).

jabl 5y ago

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.