Hitokage
Hitokage

Reputation: 803

One big SSBO or multiple small ones in Compute Shaders OpenGL

Is there any difference when I allocate multiple small SSBOs for usage in compute shaders over a big one, internally mapped to many arrays?

By the difference I mean the read/write performance. Does the GPU memory even care about the SSBO partitioning or does it handle everything uniformly.

Here is an example in shader:

layout (std430, binding=1) buffer bufferA
{int elementsA[]};

layout (std430, binding=2) buffer bufferB
{int elementsB[]};
...

//VS

layout (std430, binding=1) buffer buffers
{
int elementsA[MAXCOUNT_A];
int elementsB[MAXCOUNT_B];
...
};

One big buffer would avoid the need of many allocations from CPU side and result in a cleaner code, leaving the memory partitioning to the shader code. Of course I'd need to specify maximum size for each array representing a buffer which might result in needless memory allocation. I am however more concerned about the runtime access speed.

Is this merging even a good practice? Now in my code I am getting too much small buffer allocations which kind of ugly :D.

Upvotes: 2

Views: 2678

Answers (1)

Michael IV
Michael IV

Reputation: 11436

GPU memory cares of what type of data storage you use. You must first ask yourself,why you need SSBOs in general? SSBO data maybe stored in global memory on GPU,whereas UBOs are in on chip shared memory,access to which is much faster. I would use SSBOs for really HUGE amount of data,where your application cannot live with UBO blocks size limits.

Now,regarding your question - you must try and profile. It is hard to tell if you're going to gain by using several buffers or just one. But,I would go for one long buffer,as it requires less bookkeeping,takes less binding slots, and will probably perform faster due to spatial locality of the data in video memory. But I leave the actual test to you.

Upvotes: 3

Related Questions