OpenGL fragment shader doesn't write to SSBO - opengl

Question

I have a small OpenGL engine written and I want to use SSBOs to allow shaders to write debugging logs that I can write out. My log class looks like this:
#define SHADER_LOG_LINE_LENGTH 128
#define SHADER_LOG_MAX_LINES 512
#define SHADER_LOG_DATA_OFFSET sizeof(int32_t) * 3
#define SHADER_LOG_DATA_SIZE SHADER_LOG_LINE_LENGTH * SHADER_LOG_MAX_LINES * sizeof(int32_t)
#define SHADER_LOG_TOTAL_SIZE SHADER_LOG_DATA_OFFSET + SHADER_LOG_DATA_SIZE
class ShaderLog
{
protected:
GLuint ssbo;
GLuint binding_point;
int32_t number_of_lines;
int32_t max_lines;
int32_t line_length;
int32_t data[SHADER_LOG_DATA_SIZE];
public:
ShaderLog()
{
glGenBuffers(1,&(this->ssbo));
this->number_of_lines = 0;
this->max_lines = SHADER_LOG_MAX_LINES;
this->line_length = SHADER_LOG_LINE_LENGTH;
this->binding_point = 0;
glBindBuffer(GL_SHADER_STORAGE_BUFFER,this->ssbo);
glBufferData(GL_SHADER_STORAGE_BUFFER,SHADER_LOG_TOTAL_SIZE,&(this->number_of_lines),GL_DYNAMIC_COPY);
glBindBufferBase(GL_SHADER_STORAGE_BUFFER,this->binding_point,this->ssbo);
glBindBuffer(GL_SHADER_STORAGE_BUFFER,0);
};
void connect_to_shader(Shader *shader, string shader_variable_name)
{
GLuint block_index = 0;
block_index = glGetProgramResourceIndex(shader->get_shader_program_number(),GL_SHADER_STORAGE_BLOCK,shader_variable_name.c_str());
if (block_index == GL_INVALID_INDEX)
ErrorWriter::write_error("Shader log could not be connected to the shader.");
glBindBufferBase(GL_SHADER_STORAGE_BUFFER,block_index,this->binding_point);
glShaderStorageBlockBinding(shader->get_shader_program_number(),block_index,this->binding_point);
}
virtual void load_from_gpu()
{
glBindBuffer(GL_SHADER_STORAGE_BUFFER,this->ssbo);
GLvoid* mapped_ssbo = glMapBuffer(GL_SHADER_STORAGE_BUFFER,GL_READ_ONLY);
if (mapped_ssbo == NULL)
ErrorWriter::write_error("Could not map shader log into client's memory space for reading.");
else
memcpy(&(this->number_of_lines),mapped_ssbo,SHADER_LOG_DATA_SIZE);
glUnmapBuffer(GL_SHADER_STORAGE_BUFFER);
}
int get_number_of_lines()
{
return this->number_of_lines;
}
...
};
In my fragment shader I do:
#version 430
layout (std430, binding=0) buffer shader_log_data
{
int number_of_lines;
int max_lines;
int line_length;
int data[];
} shader_log;
...
void main()
{
shader_log.number_of_lines = 20; // just to test
shader_log.data[0] = 10000;
...
}
And the main program looks like this:
void render()
{
... // rendering
shader_log->load_from_gpu();
cout << "lines: " << shader_log->get_number_of_lines() << endl;
glutSwapBuffers();
}
...
int main(int argc, char** argv)
{
...
shader_log = new ShaderLog();
...
shader_log->connect_to_shader(shader,"shader_log_data");
shader_log->update_gpu();
...
// rendering loop
...
}
Now the number of lines written out remains 0, even though it should be set to 20 by the shader. I tried loading the data from GPU after glBufferData(...) and they are there, the problem seems to be in the connection between the buffer and the shader. I also tried reading the data in the shader and outputting them to screen and they're always 0, which supports my hypothesis. Basically I seem to be able to write/read to/from the SSBO from the CPU but not from the shader. Could anyone help me with finding the issue?

Answer 1

Why do you pass binding_point (which is 0) to your memcpy function? This way you get 0 bytes of data copied.
memcpy(&(this->number_of_lines),mapped_ssbo,this->binding_point);

Answer 2

I am assuming that at least one of those ... lines is a memory barrier that you neglected to show?
You need some form of synchronization across parallel invocations to ensure coherency, this is not automagic when using SSBOs, Image Load/Store, etc. You are likely to read an undefined value without a barrier in place as each execution unit has a different (isolated) view of the same memory.
Making sure that changes you made to the SSBO are visible to other shader invocations will require a barrier in your GLSL code prior to performing the read. Other types of incoherent operations may require a barrier in the GL command stream, but the premise is the same; order commands and read/write memory such that following operations use the result of previous ones.