0

I have multiple SSBO(4 SSBO) of size 400400100 ints and my fragment shader updates the value of this ssbo. I do this by calling the drawelements call and I read the data after the draw call by first binding the specific SSBO and then calling the glMapBuffer and type casting the ptr to an int.

The GPU does heavy processing (loops with 10000 iteration) and updates the SSBO. I have a print statemnt after the drawelement call which is shown on the screen and a print statement after the bind call, which is also displayed but the glMapBuffer call takes forever and hangs the system.

In Windows task manager, the GPU is not used for majority of the time and only CPU is used. I think its because the GPU is only used during the draw call.

Plus, Is my understanding correct that when I call glMapBuffer, only the binded ssbo is transfered?

Do you guys have any suggestion as to what might be causing this issue?

I tried using glmapbuffer range, which caused similar problem.

glDrawElements(GL_TRIANGLES, NUM_OF_TRIANGLES , GL_UNSIGNED_INT, 0); 

std::cout << 'done rendering' <<std::endl; //prints this out 

glBindBufferBase(GL_SHADER_STORAGE_BUFFER, 0, 0); 

glBindBuffer(GL_SHADER_STORAGE_BUFFER, SSBO); 

std::cout << 'done binding ssbo' <<std::endl; //prints this out 

GLint *ptr; 

ptr = (GLint *) glMapBuffer(GL_SHADER_STORAGE_BUFFER, GL_READ_ONLY); //hangs here
qwerty
  • 49
  • 9
  • "*size 400400100 ints*" That's 1.5 GB. Does your implementation even allow such a thing? "*In Windows task manager*" Please use an actual profiling tool when asking questions about performance. – Nicol Bolas Apr 14 '21 at 15:25
  • 2
    In addition, `glMapBuffer` is the first command after the draw call, so it might cause a GPU-CPU sync. The draw call itself is not blocking and returns immediately. `glMapBuffer` might then be waiting until all operations are finished. – BDL Apr 14 '21 at 16:10

0 Answers0