After some trial-and-error I think I´ve found a new bug inside the VBO implementation from ATI. It seems under some circumstances the current vertexprogram gets “lost” or the newly bound VBO is not properly synchronized with the rendering of previous glDrawElementRange() calls. I first encountered the problem when adding skinned models into the currently static world. So I think, I can narrow it down to the mixing of GL_DYNAMIC_DRAW and GL_STATIC_DRAW buffers in combination with VertexPrograms.
My rendering looks this way:
1.0 enable vertexprogram, fragmentprogram, bind “favourite” vertexprogram and fragmentprogram. enable all arrays that are used by the VP
2.0 for each object
bind VBO´s (static/dynamic) to the appropriate arrays.
3.0 for each surface of the current object
set renderstate, modelview, bind textures, probably update some VP environment variables
3.1 if the needed VP or FP differs from the favourite, bind it
3.2 call glDrawRangeElements() for this surface
3.3 rebind the favourite VP/FP, if 3.1 bound others
3.4 reset renderstate of the surface-material
1.1 disable VP/FP, disable texture units in use and texture coordinate arrays
You can see, it is well possible that the favourite VP is bound over a long time, it might even stay bound while VBO´s for other objects get bound. The problem/bug results in either unlit (the rendered geometry doesn´t match the ambient pass, so GL_EQUAL as depthfunc won´t light it up) or completely screwed surfaces. It can be turned off by
a) not using VBO (slow)
b) forcing a rebind of the current VP (also slow) in step 3.1:
glBindProgramARB(GL_VERTEX_PROGRAM_ARB, 0);
glBindProgramARB(GL_VERTEX_PROGRAM_ARB, m_lightingHLVP);
step 3.1 can lead to do the same as “solution” b) so parts of the geometry gets drawn correctly, while big parts of the other does not. The corruption doesn´t occur if no skinned models are visible (no dynamic VBO´s get bound).
GL does not throw errors, all dynamic buffers get unmapped after updating them (which is done even before step 1.0)
I´m using Catalyst3.4 drivers on a R9700. If anyone could confirm this problem, I´d be happy. thanks.
I’m having some problems with VBO in ATI hw (R9700) with and without vertex programs (using Catalyst 3.4).
My program is complex and uses static and dynamic vbo for different kinds of geometry, vertex formats, index buffers. And I’m also using ‘mapped’ buffers for dynamic geometry and I haven’t check where the problem comes.
The courious thing is that everything was working with ATI_VAO (except that I was not using mapping in this case). At the moment I don’t have time to see what is happening but I will next month.
(Currently I have to ‘disable’ the use of VBO in ATI hw).
Anyway, If you find a problem, send an example to devrel.ati.com. It is true they have many problems in their drivers but it is also true that they are very responsive and for every problem I’ve sent they have fixed it in next driver revisions. Their current drivers are ‘state of the art’ compared with their two years ago drivers.
Hope this helps.
I had that problem too but its fixed(I think). I don’t have more problems with my test/demo after installing the latest drivers for registered developers.
I’ve just spent the evening trying to get my app working on a Radeon 9700 Pro / Catalyst 3.4 and i’ve also run into a problem with VBO/Vertex Programs.
I have both my element and vertex data in vertex buffer objects. I use glVertexAttribPointerARB( … ) for pointing to my vertex data.
Having the following in my vertex program causes a crash when calling glDrawElements
ATTRIB position = vertex.attrib[0];
ATTRIB normal = vertex.attrib[2];
ATTRIB texcoord0 = vertex.attrib[8];
Switch it the following and the crash goes away.
ATTRIB position = vertex.position;
ATTRIB normal = vertex.normal;
ATTRIB texcoord0 = vertex.texcoord[0];
Unfortunately, since i’m using glVertexAttribPointerARB the second, non-crashing version, renders incorrectly as the inputs don’t match up properly.
I had similar experiences with glVertexAttribPointer… When I tried to use it for arrays 9,10,11 I got nullpointer exceptions inside the driver. Using arrays 6 and 7 resulted in a huge performance hit. So I ended up using glTexCoordPointer again
I’ve got also a Access Violation on a Radeon 9800 with Catalyst 3.4 when using VBO and Vertex Attrib Arrays. I think that it could be a driver bug, because the same program runs without errors on a GF4.
Yes, attribute arrays work now. But unfortunately my initial problem didn´t get solved. But I suspect my application more and more to be the cause. What If I do divisions by zero inside the vetex program? Would it cause the current vertex program to “crash” and remain useless until it is bound again?
