   ATI VAO performance issues
  Maybe somebody experienced a similar problem and might have an answer. I'm seeing a very strange (and show-stopping) problem on an ATI card using VAOs. The effect shows like this:1) have a camera looking somewhere2) change the camera (beaming) to another place3) new objects get into view so new VAOs are used for renderingNow comes the annoying part. In the very first frame rendered using the new camera view and therefore new VAOs not yet used a huge stalling happens so this frame takes over 2 seconds to render. All other frames afterwards (same camera, same objects, no changes) render fast and smooth. It's only this very first image where VAOs never used before are used for the first time where this 2 second stalling happens.Any ideas what could cause a VAO on ATI to stall horribly the very first time it is used for rendering? Is there some sort of ATI-specific driver hack that one has to know to not trigger this stalling?As a side note on an nVidia card the very same situation works without any stalling at all so it is an ATI specific problem.   
  Have you tried to break this down a little more to see what's really causing the problem? You keep talking about VAO's, are you sure its the VAO that's causing the problem? What exactly do you mean that "new VAO's are used for rendering"? Are you actually creating new vertex buffers/uploading the data when you move the camera? Or all these all created at runtime and its the first time you're binding it? Or are you calling the render function on all the VAO's every time, and this is the first time it's passing the frustum check? Be a little more specific about what steps you're taking.Not saying that you're wrong, but I don't think you know enough to say that it's an ATI specific problem just because you tried it on two pieces of hardware. Do your two cards have the exact same specs? Does one have more memory than another?Finally, can you try to use some profiler or some kind of timers or something to figure out exactly what calls are taking the extra few seconds? For such a jarring delay it should be relatively easy to find. Is every draw call taking five times as long, or do you just get a hang for a couple seconds when you call some specific command? It would be good to know exactly where the delay is coming from.   ;You keep talking about VAO's, are you sure its the VAO that's causing the problem?I'm sure about that as I ruled out all other factors using various tests (disabling stuff and so forth). The only way to not trigger the problem is if I don't render from the VBOs at all. In all other cases the problem happens.What exactly do you mean that "new VAO's are used for rendering"? Are you actually creating new vertex buffers/uploading the data when you move the camera? Or all these all created at runtime and its the first time you're binding it? Or are you calling the render function on all the VAO's every time, and this is the first time it's passing the frustum check? Be a little more specific about what steps you're taking.[/quote]The first time I render with them. Hence at the beginning I create the VBOs and VAOs. Then for each render call I render using the VAOs of what is visible (frustum check using various tests). Hence the first time a VAO using a new VBO (one that has never been rendered using a VAO so far... thus never been bound for rendering so far but fully prepared for rendering) the stalling happens. From this time on the VBO does not cause a stalling anymore.So to put it short: VBOs are created and data filled in at the start of the game. In the first frame the VBO is used (first bound to render) stalling happens. In all following frames no stalling (with the same VBO) happens.Not saying that you're wrong, but I don't think you know enough to say that it's an ATI specific problem just because you tried it on two pieces of hardware. Do your two cards have the exact same specs? Does one have more memory than another?[/quote]Memory is not the problem. I tested using 50% resolution (hence 25% of FBO data clogging the memory) as well as disabling Compositing but the problem stays the same. Would memory be a problem it would have gone away or be reduced in these test cases. The nVidia machine even less memory than the ATI one so I'm rather sure memory is not the problem here.Finally, can you try to use some profiler or some kind of timers or something to figure out exactly what calls are taking the extra few seconds? For such a jarring delay it should be relatively easy to find. Is every draw call taking five times as long, or do you just get a hang for a couple seconds when you call some specific command? It would be good to know exactly where the delay is coming from.[/quote]Yes, I did timing tests. The stalling happens during the rendering (aka glDrawArrays). In the same frame update calls using a bound VBO used in rendering before accounts for ~25ys (aka fast) while with those not rendered to before very high (like 27.2ms, 523.7ms, 374.9ms and so forth). In the all frames afterwards all calls around around ~25ys again (aka fast). It happens therefore exactly in the situation where a VBO is used for rendering that has not been used yet for rendering (initialized, data set, but not yet used for rendering). Unless something rather strange is going on I'm pretty sure I'm looking at the culprit right now and this are VBOs being rendered for the very first time.;  And what parameters do you use to create the VBO?What vertex format do you use?   ;  As a workaround, after creating your buffers, you can use each one to render an off-screen triangle If you can make a small app that reproduces this behaviour reliably, I'd send a bug report in to ATI with your driver version number and the repro app.   ;  @V-man:They are created like this:OGL_CHECK( *pOgl, oglGenBuffers( 1, &pVBO ) );   glBindBuffer( GL_ARRAY_BUFFER_ARB, pVBO );   glBufferData( GL_ARRAY_BUFFER_ARB, pVBOLayout->GetSize(), NULL, GL_STATIC_DRAW_ARB ) );   vboData = ( unsigned char * )oglMapBuffer( GL_ARRAY_BUFFER_ARB, GL_WRITE_ONLY_ARB );   pWriteVBOData( vboData );   glUnmapBuffer( GL_ARRAY_BUFFER_ARB );Dynamic ones use glBufferData using the NULL-copy version (hence glBufferData with NULL then with actual data).Vertex format is (stride=44, interleaved):// name   | offset | type  | components// -----------+--------+-------+------------// position   |  0 | float | x, y, z// normal | 12 | float | x, y, z// tangent| 24 | float | x, y, z// tex-coord  | 36 | float | u, v@Hodgeman:Some random 2-3 seconds lag before starting the game is not that funny neither but maybe the problem can be found. Concerning the bug I did already send a bug (with test-bed app sources) for the Depth-Detach bug but nobody cared. The same with the FBO+CubeMap Depth Render Bug (I've not been the only one reporting this problem) but nobody cared. Why should they care now? Nope, I'm not going to waste my time a 3rd time. I better spend it finding a way around the problem as most likely they don't give a damn about it anyways.;  Try to padd your data so that it is 64 bytes   ;Try to padd your data so that it is 64 bytesI read this now at a couple of places but often from old places. Some say it's not important as this only affects old cards (and with old I mean a couple of years ago). Is this really something ATI cards sneeze at? Right now my points are 44 bytes long. This would mean 20 bytes of wasted VBO space so roughly 2x more VBOs (assuming 4M is the max size one should use... something I found at one place but could not get confirmed so far). Or does this only mean the total amount of data has to be 64-bytes aligned not the individual points (aka stride)? I read also at one place that 64-bytes is not important only 4-bytes. What's about that claim?   ;  What is pVBOLayout->GetSize() ?What happens if you change the usage hint? Or if you send the data in glBufferData (at least for the static vbos), instead of mapping them?   ;What is pVBOLayout->GetSize() ?You can look at the commented text above. It describes the used format (in this case 44 bytes stride to answer the question).What happens if you change the usage hint?[/quote]Tried static and dynamic, both show the same problem.Or if you send the data in glBufferData (at least for the static vbos), instead of mapping them?[/quote]Tried this also and the problem is the same no matter if mapped or using BufferData.