Catalyst 3.5 and VBO/VAO

OpenGL OpenGL: Advanced Coding
1

Looks like the issue where creating more than 32 MB of vertex buffers resulted in OUT_OF_MEMORY is solved. Individual buffers are still capped at 32 MB, but several smaller buffers whose total is beyond 32 MB will work.

2

Using generic attributes with VBO finally also works.

But I still get about 30% better performance with VAO than with VBO in a real world app (and have no clue what I could do about it).

3

Yeah! Attribute Arrays + VertexProgram = working. And in my case Catalyst3.5 brought a significant speed up. If you say, they are still slower than VAO (never implemented them), maybe there´s still room for improvement in the drivers :slight_smile: The Halflife fullscreen-to-desktop-and-back-60-Hz-problem is still there. Someone mentioned that this is a Halflife bug and nVidia could only solve it by doing application-specific behaviour inside their drivers. As a programmer, I understand they (ATI) are suspicious of such solutions, but as a consumer and gamer I really don´t mind it, as long as it happens behind the scenes.
Besides that the new drivers introduced a new bug in my own app, being, that when the application ran in fullscreen, it wouldn´t quit normally, but stay in taskbar, taking 99% of cpu time. But I won´t blame ATI for that yet, I still need to figure out if its my fault maybe.

4

I have to complain about ATI-VBO (neverending story??). When using fullscreen, my app won´t quit nicely but hangs isnide this infinite loop deep inside the ATI ogl dll:

0921D9E0 mov edx,dword ptr [ecx]
0921D9E2 and edx,7FFFFFFFh
0921D9E8 mov eax,edx
0921D9EA inc edx
0921D9EB lock cmpxchg dword ptr [ecx],edx
0921D9EF jne 0921D9E0

my code:

if (m_vbo)
{
	assert(!m_lockcount);	
	glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
	glDeleteBuffersARB(1,&m_vbo);
	GLERROR("VBOVertexBuffer::~VBOVertexBuffer() glDeleteBuffersARB");
}

glDeleteBuffersARB() is not returning.

It is well possible that at the time when this buffer is deleted, it is still bound to some arrays (vertexarray, texcoord and colorarray). But the VBO specs mention, it is ok to delete the buffer object in this case. After deletion I don´t use the buffer for anymore (as expected). The problem occurs only when the app ran in fullscreen mode before. Running in windowed is ok.
A coarse order-of-operations:

  1. switch to fullscreen
  2. initialize gl
  3. allocate, render, destroy buffers arbitrary times
  4. user quits
  5. switch to windowed
  6. delete all remaining buffer objects, textures and so on
  7. destroy gl context

The hang-up occurs in Step 6. Maybe the driver expects that the program should only delete bufferobjects in the screenmode it created them???
Well again, very mysterious things going on here, I wonder if VBO will ever work bugfree on my R9700…

5

That loop looks like a spinlock. Thus, it’s waiting for some resource to be released, and the resource never is.

I’ve had problems with a VIA KT400 based motherboard, and it got mostly solved by turning off fast writes. If you’re using a VIA motherboard, you may with to try the same thing yourself.

It’s not certain that it’s a driver bug, just because the driver is the place where it ends up hanging…

6

Well it wasn´t there before, so the new Catalyst must have provoked this somehow. Anyway, I´m using an Abit NF7rev.2, equipped with nForce2 chipset and I had no problems with it yet.