SSBO as bigger UBO?

Question

i am currently doing so rendering in OpenGL 4.3 using UBOs to store all my constant data on the GPU. (Stuff like material descriptions, matrices, ...). It works however the small size of UBO (64kB on my implementation) forces me to switch buffers numerous times slowing rendering, i am looking for similar a way to store a few MB.

After a little research i saw that SSBO allow exactly that but also have unwanted 'features' : they can be written from the shader and might be slower to read.

Is there a better solution than SSBO for supplying big chunks of data to shaders ? I feel like i am missing something, why should UBO be limited to a few kB while there exists a more flexible solution capable of handling much more data ? If shader storage buffers is what i am looking for, is there a way to ensure that they are not modified by the shaders ?

Answer 1

UBOs and SSBOs fundamentally represent two different pieces of hardware (usually)¹.

Shaders are executed in groups, such that every shader executes in lock-step. Each group of individual shader invocations has access to a block of memory. This memory is what UBOs represent. It is relatively small (on the order of kilobytes), but accessing it is quite fast. When performing a rendering operation, data from UBOs are copied into this shader local memory.

SSBOs represent global memory. They're basically pointers. That's why they generally have no storage limitations (the minimum GL requirement is 16 Megabytes, with most implementations returning a number on the order of the GPU's memory size).

They are slower to access, but this performance is because of where they exist and how they're accessed, not because they might not be constant. Global memory is global GPU memory rather than local constant memory.

If a shader needs to access more data than can comfortably fit in its shader local memory, then it needs to use global memory. There's no getting around this, even if you had a way to declare an SSBO to be "constant".

¹: There is hardware that exists (GCN-based AMD hardware) which doesn't have dedicated UBO storage. This hardware implements UBOs as just a read-only SSBO, so all UBO accesses are global memory accesses. This hardware essentially relies on having large caches to make up for the performance difference, and the patterns of use for UBOs tend to make this viable. But there's still lots of hardware that has dedicated room for UBO storage, so if your use can fit within those limits, you should use them.