GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS too low on my machine

[questor]

Hi!
during setup of sokol-gfx the library tries to initialize the cache of the buffer bindings (in _sg_gl_cache_clear_buffer_bindings) and tries to assign a zero-ptr to all GL_SHADER_STORAGE_BUFFER indices, but the library tries to initialize 16 buffers (hard compiled into the library configuration with _SG_GL_MAX_SBUF_BINDINGS which is defined as:
#define _SG_GL_MAX_SBUF_BINDINGS (2 * SG_MAX_STORAGEBUFFER_BINDSLOTS)
which in turn is defined as:
SG_MAX_STORAGEBUFFER_BINDSLOTS = 8,
)

so the library tries to set 16 buffers, but my current machine (a linux-machine running under vmware) only supports 8 buffers in total:
GL_MAX_UNIFORM_BUFFER_BINDINGS: 84
GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS: 8 <------

so setting indices 8..15 result in glerrors which are catched after initialization of the cache.

I can workaround that initialization by clearing the error, but I'm not sure what that means for the library as a whole or if this needs broader handling or is this case only on a tiny subset of graphic drivers. If you need more infos just ping me.
-Kai

PS: LinuxMint reports the graphic drivers as "VMware SVGA II Adapter":
Graphics:
Device-1: VMware SVGA II Adapter driver:vmwgfx v: 2.20.0.0 ports:
API: EGL v:1.5 platforms: device: 0 drv: vmwgfx device: 1 drv: swrast
API: OpenGL v: 4.5 compat-v: 4.3 vendor: vmware v: N/A glx-v: 1.4

[floooh]

Thanks for the headsup. This is mostly a sokol-gfx bug, because the max number of storage buffer bindings across all shader stages is indeed expected to be 8 (as indicated by SG_MAX_STORAGEBUFFER_BINDSLOTS).

But that could mean 8 bindings on one stage, on none on the other, that's where the 2x in the GL backend comes from... the tricky thing is that GLSL has separate bind spaces for each shader stage, and mapping those separate bind spaces (with 8 slots each) to a common bind space with 16 slots was the convenient thing to do (e.g. vertex shaders use bind slot 0..7, and fragment shader 8..15).

I actually need to think about a good solution. Worst-case (and trivial) solution would be to restrict the number of per-stage bindings to GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS / 2, but maybe I can come up with something better...

[questor]

do you need the number of buffers for the other stages as well to get an overview of the capabilities? for the time beeing I can apply my workaround as I don't need a high number of buffers, currently I'm using very simple graphics so no hurry needed from my side.

[floooh]

do you need the number of buffers for the other stages as well

Thanks but probbaly not, I think the rest of the GL backend is already either 'minspec compatible' or uses dynamic limits because of the WebGL2 support.

Btw, another less intrusive fix might be to just tell sokol_app.h to initialize a GL 4.1 context via sapp_desc.gl_minor/major_version (in case you use sokol_app.h), this info then trickles into sokol_gfx.h via sg_environment and disables any storage buffer related code in the GL backend. In that case you may also need to change your shaders to #version 410 though.

Or alternatively, just hardwire this line to = false:

sokol/sokol_gfx.h

Line 7856 in 0925b88

_sg.features.storage_buffer = version >= 430;

[floooh]

Reminder to self: check if sokol-shdc just directly uses the input bindings [0..7] (that's how it should be) instead of remapping them to a [0..16] range.

[floooh]

FYI I'll start working on that now but it also needs a sokol-shdc update, so it's a bit bigger than expected.

[floooh]

Turns out that the sokol_gfx.h fix is actually very simple (https://github.com/floooh/sokol/pull/1196/files), and the bigger change is indeed in sokol-shdc (although still quite small: https://github.com/floooh/sokol-tools/pull/170/files).

I'll merge this tomorrow after combing the comments and documentation for outdated info.

Also, technically this is a breaking change, so I'll need to write a proper changelog entry :)

[floooh]

Should be fixed now. See changelog: https://github.com/floooh/sokol/blob/master/CHANGELOG.md#23-jan-2025