   Unknown delay with opengl
  I'm experiencing an unknown delay with my opengl implementation.First of all, I'm using windows 7 x64 and the 197.44 nvidia drivers (with GTX 260), although I believe this happened when I had win xp x64 and the up-to-date drivers a few months ago.On to the problem. I'm noticing a noticeable amount of delay when running opengl compared to direct3d 9. As is, it creeps up in the update function.My game loop looks like this more or less:while(running){    m_pTimeManager->Update();    m_pInput->Update();    m_pApplication->Update();    m_pApplication->Render();    if (m_pDisplayManager->MessageHandling() || m_pInput->GetKeyboard()->KeyDown(KEY_ESCAPE))    running = false;}Okay, so the delay pops up in the update function for some reason. However, if I use the windows function "SetWindowText()" every frame, it shifts the delay from the update function to the message handling function, which is just:MSG msg;if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)){    if (msg.message == WM_QUIT) return true;    TranslateMessage(&msg);    DispatchMessage(&msg);}return false;I know this is still a pretty vague question, but I'm wondering if anyone has come across this problem, and if there is a way to get rid of the delay.Or, am I not on the right track? In this case, does anyone have an idea of where I might look to better track this down?Thanks for any help!   
  Hi,I got similar effects and tried to optimize them(thread). Sofar my investigation shows, that ogl commands are queued, but not executed directly. But some commands blocks the execution of your program until the command queue has been executed ("command queue flushing"). I.e. glGetError is such a command or swapping the framebuffers with v-sync on. I don't know what SetWindowText() do, but I could imagine that SetWindowText waits for the swapping of the buffers.For debugging purpose you can play around with glFinish (which flushs the command pipeline) and see what effect it has on your delays, i.e. add glFinish to the end of your render update.   ;Quote:Original post by Ashaman73Hi,I got similar effects and tried to optimize them(thread). Sofar my investigation shows, that ogl commands are queued, but not executed directly. But some commands blocks the execution of your program until the command queue has been executed ("command queue flushing"). I.e. glGetError is such a command or swapping the framebuffers with v-sync on. I don't know what SetWindowText() do, but I could imagine that SetWindowText waits for the swapping of the buffers.For debugging purpose you can play around with glFinish (which flushs the command pipeline) and see what effect it has on your delays, i.e. add glFinish to the end of your render update.Thanks for the information and suggestion. I put glFinish at various places but did not see any difference in performance. However, it does seem like it is the command queue thing.I believe it is being transferred to my 'update' function as I updated a vertex buffer there, which would be the first gl call of the new frame. When I disabled that, the the delay moved to the 'render' function. More specifically, it seems to have found it's new home in the GBuffer creation (essentially first stage of the renderer minus clearing framebuffers).Tomorrow I'll try further debugging tests to try and figure some more stuff out.EDIT: Actually, I spoke too soon. It seems if I put glFinish at the end, right before SwapBuffers, the delay gets shifted to the "draw time", which is where D3D9 (where it does Present) has a little delay, though still smaller than opengl I believe   ;  You should try to move the complete delay, or atleast as much as possible, to the beginning of your rendering method. In this case you will avoid wasting CPU time with unnecessary time for waiting on GPU events. Your other CPU bound engine features (gamelogic, AI, physics) will benefit from it and you could archive a performance boost,  but most likely only if you use CPU expensive gamelogic,physics etc.With this approach you will not get rid of the delay as such. The delay means, that your GPU is busy while your CPU idles. In this case you can add more CPU bound features or try to optimize your shaders and/or rendering pipeline.;Quote:Original post by Ashaman73With this approach you will not get rid of the delay as such. The delay means, that your GPU is busy while your CPU idles. In this case you can add more CPU bound features or try to optimize your shaders and/or rendering pipeline.I'm going to look at my rendering pipeline some more. If I just bypass my renderer, and render a skybox, some text, and two gui textures, it takes OpenGL roughly .72ms to complete a frame, compared to if I use my rendering pipeline, it takes OpenGL roughly 7.3ms... not exactly apples to apples, but pretty close. The main difference between the two is pretty much framebuffer switches and some state changes (blending, depth stuff, etc), at least on the graphics side point.EDIT: Well, I managed to save a few ms. It was either because I was calling glGenerateMipmap on two textures that probably didn't need it, or if it was because I got rid of calling clear a few times at the start of the pipeline.A few ms on the basic scene (still 1.5ms more than D3D9, and doesn't really make a dent with 1024 lights/1 directional light)[Edited by - AgentSnoop on May 21, 2010 12:59:43 PM];  I saw you said something about updating vertex buffers. Generally you want to keep any buffers (Textures, vertices, etc) as static as you possibly can. Any access to these can cause locks and delays while data is updated/copied/etc over bus (In your case, the PCI Express bus).Without seeing anything in your "Update()" functions it's tough to say what a cause could be.   ;Quote:Original post by GodBeastXI saw you said something about updating vertex buffers. Generally you want to keep any buffers (Textures, vertices, etc) as static as you possibly can. Any access to these can cause locks and delays while data is updated/copied/etc over bus (In your case, the PCI Express bus).Without seeing anything in your "Update()" functions it's tough to say what a cause could be.They are rather basic currently. For my test scene, I just have 1024 point lights that circle on my static terrain, and a console that updates it's text. But the problem isn't really the updating of the vertex buffer as when I don't enable instancing (updating the vertex buffer), the delay just moves to a different part of the code, same amount of time. Everything else is static essentially, minus setting parameters to shaders.   ;  How are you going about rendering the text?   ;Quote:Original post by GodBeastXHow are you going about rendering the text?Without instancing, I draw a quad for each character (so for how ever many characters there are, there are an equal amount of draw calls), updating the position offset, and texture coordinate offsets on each draw call.With instancing, I update the "instancing" vertex buffer with the position offset and texture coordinate offsets when it needs to be updated. Then draw once.So, if I have the console enabled, with instancing, and nothing gets typed, it doesn't update the vertex buffer, and I'll still have a delay.   ;  Have you figured out at which point in the C++ code the delay is actually occuring? On what API call?   