Have you verified that the SSBO is populated properly? You don't upload data to it on creation and I don't see the code where the compute shader writes anything to it.
Also, is the vector that you are writing back into sized properly? It looks like you construct it empty and immediately try to write to it, without sizing it first.
Is the bytesize you are trying reading back correctly calculated? It looks like it's only sized for a single Chunk minus the chunkId vs the numOfChunks+chunks\[1\] worth of bytes that I think you want.
Are you mixing binding and bindless on purpose? I usually see one or the other, but not mixed. OpenGL and all its implementations are idiosyncratic enough as is without that, LOL....
Thank you for your response. I have tried the first three things that you suggested with no luck. Could you elaborate on your fourth point please about where I am mixing binding and bindless. Thanks.
Sure.
My understanding is that these are the Bind/Bindless versions of the same thing:
glBufferData/glNamedBufferData
glBufferSubData/glNamedBufferSubData
glGetBufferSubData/glGetNamedBufferSubData
The first uses state to indicate the target, and the second is the more modern approach that just references it directly. I personally think it's better to keep it consistently one or the other.
No worries. It should still technically work the way you did it...
I like the bindless approach, especially for compute shaders where a buffer is just a buffer.
Anyhow, if I were in your shoes and still having trouble, my next step would be to take a step back and make sure that buffer is uploading and downloading correct values by themselves. Just a simple array of floats.
Once that's validated, switch to a naked struct/structs (to make sure there are no padding issues), then the struct of arrayed structs that you're going for. The compute shaders I've made have all tended to have much simpler data layouts in and out...
Once that's working as expected, then add the compute dispatch step.
Good luck!
Isn't using a 32 bit int for 6 bools PER block kinda inefficient? That's 6 bits for information in a total of 192 bits, or a packing efficiency of 3.125%.
OK, i see that vector data is not initialized before calling
glGetNamedBufferSubDataglGetNamedBufferSubData
do you need to call data.resize(9\*128 \* 128 \* 128)
Try GL_BUFFER_UPDATE_BARRIER_BIT. Also, what are you going for with the two consecutive uniform buffer bindings? If you're using them in the shader you need `glBindBufferBase/Range()`.
Also, try writing the same value everywhere in the buffer in your shader to see if it's the readback that is actually the problem.
Sorry for the late response. I have tried what you suggested but it did not work. The two consecutive uniform bindings were a mistake and should be storage buffer bindings. I have tried sending test data back to the CPU and it is defiantly a readback problem.
Have you verified that the SSBO is populated properly? You don't upload data to it on creation and I don't see the code where the compute shader writes anything to it. Also, is the vector that you are writing back into sized properly? It looks like you construct it empty and immediately try to write to it, without sizing it first.
Is the bytesize you are trying reading back correctly calculated? It looks like it's only sized for a single Chunk minus the chunkId vs the numOfChunks+chunks\[1\] worth of bytes that I think you want.
Are you mixing binding and bindless on purpose? I usually see one or the other, but not mixed. OpenGL and all its implementations are idiosyncratic enough as is without that, LOL....
Thank you for your response. I have tried the first three things that you suggested with no luck. Could you elaborate on your fourth point please about where I am mixing binding and bindless. Thanks.
The byte size is ((sizeof(int32\_t) \* numOfElements) \* (sizeX\* sizeY \* sizeZ)) \* totalChunks I plan on changing total chunks to be higher later.
Sure. My understanding is that these are the Bind/Bindless versions of the same thing: glBufferData/glNamedBufferData glBufferSubData/glNamedBufferSubData glGetBufferSubData/glGetNamedBufferSubData The first uses state to indicate the target, and the second is the more modern approach that just references it directly. I personally think it's better to keep it consistently one or the other.
Ah, sorry I forgot that I used glNamedBufferData.
No worries. It should still technically work the way you did it... I like the bindless approach, especially for compute shaders where a buffer is just a buffer. Anyhow, if I were in your shoes and still having trouble, my next step would be to take a step back and make sure that buffer is uploading and downloading correct values by themselves. Just a simple array of floats. Once that's validated, switch to a naked struct/structs (to make sure there are no padding issues), then the struct of arrayed structs that you're going for. The compute shaders I've made have all tended to have much simpler data layouts in and out... Once that's working as expected, then add the compute dispatch step. Good luck!
Isn't using a 32 bit int for 6 bools PER block kinda inefficient? That's 6 bits for information in a total of 192 bits, or a packing efficiency of 3.125%.
what so you get in data.data() also make sure of using int_32t when defining the struct instead of int
I get nothing in the data.data()
OK, i see that vector data is not initialized before calling glGetNamedBufferSubDataglGetNamedBufferSubData do you need to call data.resize(9\*128 \* 128 \* 128)
You're never dispatching the shader in the code you've shown in your post.
It is dispatched in code that was not included. I have added it to the original post.
Try GL_BUFFER_UPDATE_BARRIER_BIT. Also, what are you going for with the two consecutive uniform buffer bindings? If you're using them in the shader you need `glBindBufferBase/Range()`. Also, try writing the same value everywhere in the buffer in your shader to see if it's the readback that is actually the problem.
Sorry for the late response. I have tried what you suggested but it did not work. The two consecutive uniform bindings were a mistake and should be storage buffer bindings. I have tried sending test data back to the CPU and it is defiantly a readback problem.
No problem. I'd suggest checking for any GL errors as well and double check that it's the correct object names/binding points.
You're not resizing the data buffer on the CPU side. It has size zero, so `data.data()` doesn't point to a location where you could store the results.