Archived

This topic is now archived and is closed to further replies.

Jumpman

Problem with VBO on ATI

Recommended Posts

over the weekend I bought myself a ATI 9600XT Radeon.. (I had a gf4mx before that) and since then, my model loader has been crashing when setting up the VBO's (which was working fine on the gforce card). Here is the code which allocates the VBO and then feeds it the data (into a display list)..
	int	nVertexCount = m_numTriangles * 3;

	// generate the vertex, texture and normal arrays

	generateArrays();

	// Generate And Bind The Vertex Buffer

	m_pgp->glGenBuffersARB(1, &m_nVBOVertexArray);							// Get A Valid Name

	m_pgp->glBindBufferARB(GL_ARRAY_BUFFER_ARB, m_nVBOVertexArray);			// Bind The Buffer


	// Load The Data (vertices, texture cords, colours and normals)

	m_pgp->glBufferDataARB(GL_ARRAY_BUFFER_ARB, 
						   nVertexCount * sizeof(vaVertexArray),
						   m_pvaVertexArray, 
						   GL_STATIC_DRAW_ARB);

	m_fVBOGenerated = true;

	// generate a display list

	m_vaDisplayList = glGenLists(1);

	if(m_vaDisplayList == 0)
	{
		return;
	}

	glNewList(m_vaDisplayList, GL_COMPILE);

		// Enable all client states we are using.

		glEnableClientState(GL_VERTEX_ARRAY);
		glEnableClientState(GL_TEXTURE_COORD_ARRAY);
#ifndef NO_NORMALS
		glEnableClientState(GL_NORMAL_ARRAY);
#endif
	   
		// Load the data to each pointer type we need.

		m_pgp->glBindBufferARB(GL_ARRAY_BUFFER_ARB, m_nVBOVertexArray);
		glVertexPointer(3, GL_FLOAT, sizeof(vaVertexArray), BUFFER_OFFSET(0));
		glTexCoordPointer(2, GL_FLOAT, sizeof(vaVertexArray), BUFFER_OFFSET(3*sizeof(float)));

#ifndef NO_NORMALS
		glNormalPointer(GL_FLOAT, sizeof(vaVertexArray), BUFFER_OFFSET(5*sizeof(float)));
#endif

		// Draw the entire object.

		glDrawArrays(GL_TRIANGLES, 0, m_numTriangles*3);

		// Disable all the client states we enabled.

		glDisableClientState(GL_VERTEX_ARRAY);
#ifndef NO_NORMALS
		glDisableClientState(GL_NORMAL_ARRAY);
#endif
		glDisableClientState(GL_TEXTURE_COORD_ARRAY);

	// End the list creation.

	glEndList();

	// unbind any buffers

	m_pgp->glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
It's crashing on the glDrawArrays command.. any ideas ?? I am using the latest catalyst drivers (3.10) available for download on the ATI site.. Jumpman - Under Construction [edited by - Jumpman on January 6, 2004 2:20:18 AM]

Share this post


Link to post
Share on other sites
I can''t help you with your problem, but I''m just curious: why are you putting VBO inside a DL? This is pretty useless and will slow things down, since for DLs it makes no difference if the data is in the VBO, vertex arrays or even immediate mode.

-Lev

Share this post


Link to post
Share on other sites
well in my initial tests (on the gforce).. there was a significant jump in fps in putting in the enabling client state into a DL..

if I use the same vertex data as an normal vertex array then it works fine (including putting it in a display list).. would like to understand why it''s crashing as VBO''s should really be used if possible..

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
How much data are you trying to load into the VBO? There is a limit but I think it varies by card/driver configuration. Try putting just a few vertices in there and see if it still crashes.

Share this post


Link to post
Share on other sites
i think my largest object has about 1000 vertices , normals, texture cords etc..

will give it a go..

is there anyway to find out the maximum size of a VBO..

Share this post


Link to post
Share on other sites
tried it with just 10 tri''s and it''s still crashing out.. access violation in ATIOGLXX.DLL

bog standard va''s work fine.. hmm..

Share this post


Link to post
Share on other sites
do you have anything enabled usng EnableClientState where you haven''t specfied a pointer to? For instance i know my app crashes if i enable Normal_ARRAY but dont specify the data for it with NormalPointer. Maybe you accidentially enabled one of the other arrays but nevered turned it off ealier in your code; It''s probably not ur problem, but its a shot in the dark. Good luck with ur problem.

Share this post


Link to post
Share on other sites
try something weird and use the normal pointers etc. (everything but vertex pointer) without enabling them. i had some pretty pointless crashes using vbo and fragment programs and for some reason not enabling normal/color arrays but just using them would not just not crash but for some reason even work correctly when it probably shouldnt.

Share this post


Link to post
Share on other sites
I took out the display list bit and it works fine.. The normal VA code (which also puts it into a display list) works fine so it seems like the ATI drivers don''t like setting the VBO pointer (via glBindBufferARB(GL_ARRAY_BUFFER_ARB, x))
in a Display List where the nvidia drivers do..

Share this post


Link to post
Share on other sites
quote:
Original post by Jumpman
seems like ATI have their own VAO type extenstion... but they support the "GL_ARB_vertex_buffer_object"

http://www.ati.com/developer/sdk/RADEONSDK/Html/Info/ATI_vertex_array_object.txt

what are people using for ATI cards ??.. surly the code I posted above must be simular to what other people are doing ???

No one bothers with ATI_vertex_array_object anymore. Performance is pretty much equal with both, so there''s no reason not to use VBO.

Share this post


Link to post
Share on other sites
for those who are interested.. I did some benchmarks (on a Athlon 2700XP, 512 333 DDR and on a Radeon 9600xt (3.10 drivers)

I rendered my scene (a pinball table).. at 1024res, 32bit, windowed) which has 5811 tri''s on it..

235fps for Raw Poly Pushing..

260fps for Vertex Arrays without a Display List wrapper

275fps for Vertex Arrayw with a Display List wrapper

265fps for VBO''s (without a Display List wrapper as it don''t work :D)

so you can see that embedding the client/server state into a DL makes a nice speed increase..

Share this post


Link to post
Share on other sites
As a minor point of intrest, when your scene gets to a high enuff complexity it wont be the 15fps loss from the VBO that kills your frame rate it will be fill rate

Vertex submission and transformation rate is much of a muchness really, its fillrate which kills things now

Share this post


Link to post
Share on other sites
quote:
Original post by Jumpman
seems like ATI have their own VAO type extenstion... but they support the "GL_ARB_vertex_buffer_object"

http://www.ati.com/developer/sdk/RADEONSDK/Html/Info/ATI_vertex_array_object.txt

what are people using for ATI cards ??.. surly the code I posted above must be simular to what other people are doing ???




Nvidia and Apple both had their own versions similar to ATI as well, that''s what makes the VBO nice (that its vendor independent)

Share this post


Link to post
Share on other sites
You''re probably not bandwidth limited, so your framerate values are just irrelevant. It''s more likely a CPU or fillrate bottleneck. Try increasing your amount of geometry drawn by a factor of 10, and test again.

Putting a VBO inside a display list is not something common, so i''m only half surprized of the problem you see. Display lists are built on the CPU, which means the CPU has to have access to the geometry data. If you''ve put this geometry data in a VBO, this implies a readback from video to system memory by the CPU, which we all know if extremely slow. Although it shouldn''t crash.

But are you 100% sure this operation (embedding VBOs inside DLs) is allowed by the specification? I''d double-check if i were you. It''s possible that NVidia allows it when it shouldn''t.

Y.

Share this post


Link to post
Share on other sites
ok.. rendered the same scene 10 times (over the top) per frame..

total tris.. 57633 (same spec machine)

61fps for Raw Poly Pushing..

139fps for Vertex Arrays without a Display List wrapper

229fps for Vertex Arrays with a Display List wrapper

175fps for VBO''s without a Display List wrapper

..

I checked the sgi docs..

Which commands are compiled into display lists?

RESOLVED: None of the commands in this extension are compiled
into display lists. The reasoning is that the server may not
have up-to-date buffer bindings, since BindBuffer is a client
command.

Just as without this extension, vertex data is dereferenced
when ArrayElement, etc. are compiled into a display list.


I guess Nvidia do it where ATI are more close to the specification.. Might be interesting to test if nvidia do it if the data has been specified as Dynamic or Stream..

Share this post


Link to post
Share on other sites
Interesting. I read the spec (including the later section):

Additions to Chapter 5 of the 1.4 Specification (Special Functions)

Added to section 5.4, as part of the discussion of what commands
are compiled into display lists:

"Commands that are used to create, manage, and query buffer objects
are not included in display lists, but are executed immediately.
These commands are BindBufferARB, DeleteBuffersARB, GenBuffersARB,
IsBufferARB, BufferDataARB, BufferSubDataARB, MapBufferARB,
UnmapBufferARB, GetBufferParameterivARB, GetBufferSubDataARB,
and GetBufferPointervARB.

GL commands that source data from buffer objects dereference the
buffer object data in question at display list compile time, rather
than encoding the buffer ID and buffer offset into the display list.
Only GL commands that are executed immediately, rather than being
compiled into a display list, are permitted to use a buffer object as
a data sink."


to mean than VBO in a display list was valid, but that the result would be the polygons contained in the buffer at display list compile time, not the contents of the buffer at display list execution time.

Enigma

Share this post


Link to post
Share on other sites
This is the reason I said it makes no sense to include VBO in a DL. And if it brings more performance then it''s either a misuse of VBO or a driver bug (or your app is fill or CPU limited). It shouldn''t crash though

Try contacting devrel@ati.com

-Lev

Share this post


Link to post
Share on other sites
Try disabling OVERDRIVE in the advanced display options - that can sometimes make your system unstable (what with overclocking the card and all).

The card runs the exact same without it on, it''s not much of a performance boost so turn it off.

Make sure you''re not running it at 8x AGP when you can only run it at 4x AGP - that happened to me too.

Peace.


Share this post


Link to post
Share on other sites