🔒 Locked

Fastest Rendering Solutions

Started by cippyboy Jun 6, 2004 at 12:15 PM 16 replies 1.8k views

Original Post

Jun 6, 2004 at 12:15 PM

I normally render all my objects trough the glDrawElements() function wich works perfectly & all

Now I come up with the following issue-> I have An AMD XP 2000+(~1.7GHz), with a GeForce FX 5200. I made some tests today-> I rendered 204 800(that`s 103 041 vertices and 614 400 Indices

) with lighting and no textures at all, and I get around 12-15 frames. Is this normal/maximum I can get ? Second point, I tryed using ->GL_EXT_compiled_vertex_array As Ive seen its not much differnt, the use of glLockArraysEXT/glUnlockArraysEXT is equal to nothing because nothing happens ->GL_EXT_draw_range_elements_ I understood why its better but I havent seen it`s effects, and the limitations they talk about, those GL_MAX_ELEMENTS_VERTICES_EXT GL_MAX_ELEMENTS_INDICES_EXT are uh... not to be used, I mean 4096 vertices ?? I use 25 times that and more... ->Display Lists At this sizes, you cant actually see the difference, or at least I havent, the framerate is still the same... maybe when I insert texturing I`ll see the performance. I`m trying to better more solutions, these are just the first I stumbled upon... have you found other solutions ?

Corrail

Jun 6, 2004 at 12:21 PM

Try GL_ARB_vertex_buffer_objects!

--------------------------------------------------------

There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened...

cippyboy

Jun 7, 2004 at 6:02 AM

Ok thanks, I knew that stuff existed, its just that I didnt had the time to look over it, its the first thing Ill try next

By the way whats the performance increase if youve tested it already ?

python_regious

Jun 7, 2004 at 3:28 PM

quote:
Original post by cippyboy
Ok thanks, I knew that stuff existed, its just that I didnt had the time to look over it, its the first thing Ill try next

By the way whats the performance increase if youve tested it already ?

Substantial.

You have to remember that you''re unique, just like everybody else.

cippyboy

Jun 8, 2004 at 9:07 AM

[python_regious] I

m sorry to dissapoint you but that extension is... crap, at least for my needs it is...

I just made tests with that thing and guess what ? while using at every frame the BindBuffer/Null Vertex Array/Draw elements I get around 1-2 frames at that huge model. What I tryed next was to insert all this into display lists... So I get back at those 15 frames that I normally get with the normal ussage of the glDrawElements.
At a second though, maybe it

s my code thats buggy right ? ok heres a piece of the diplay list calls(remove comments to get in list mode)


void RenderBufferObjects(MODEL3D *M)
{	
	static UINT bID=0;
	static bool b=0;
	if(!b)
	{
		glGenBuffersARB( 1, &bID );							// Get A Valid Name

		glBindBufferARB( GL_ARRAY_BUFFER_ARB, bID);			// Bind The Buffer

	// Load The Data

		glBufferDataARB( GL_ARRAY_BUFFER_ARB,M->Object[0].nr*3*sizeof(float),M->Object[0].V, GL_STATIC_DRAW_ARB );// where M->Object[0].nr is the number of vertices

		delete [] M->Object[0].V; M->Object[0].V = NULL;	
		b=1;
	}
int y=0;
static UINT LID=0;
static bool comp=0;
//if (!comp)

{
	//LID=glGenLists(1);

   //glNewList(LID,GL_COMPILE);

   glEnableClientState(GL_VERTEX_ARRAY);
   //

   glBindBufferARB( GL_ARRAY_BUFFER_ARB,bID);
   glVertexPointer( 3, GL_FLOAT, 0, (char *) NULL );
   //	    

		glColor3f(1,1,1);
   glDrawElements(GL_TRIANGLES,M->Object[y].nrI,GL_UNSIGNED_INT,M->Object[y].I);//nri->indices and I->the index array, it renders corectly no doubt...

   //glEndList();

   comp=1;
}
//glCallList(LID);

}

Alura

Jun 8, 2004 at 10:09 AM

I may be wrong, but i think that you should only generate the buffer once, otherwise, you''ll be generating them whenever you render an object.

Krohm

Jun 8, 2004 at 10:29 AM

quote:
Original post by python_regious
quote:
Original post by cippyboy
Ok thanks, I knew that stuff existed, its just that I didnt had the time to look over it, its the first thing Ill try next

By the way whats the performance increase if youve tested it already ?

Substantial.

You have to remember that you''re unique, just like everybody else.

It was higher than 100% for me but it was a xform limited scenario with no fancy per-pixel math or the stuff.
Take this numbers with some salt (application specific, almost 1 year ago):
MultiDrawElements: <5fps
MultiDrawElements with VBO (same data): >20fps (maybe it was around 23, not sure).
Static geometry, with a simple vertex program loaded. No blending, no antialiasing (even with AA on it doesn''t change too much, looks like it was xform limited), some simple texturing.

python_regious

Jun 8, 2004 at 10:32 AM

quote:

[python_regious] I`m sorry to dissapoint you but that extension is... crap, at least for my needs it is...

No, you''re just not using it correctly.

Creating and filling a VBO *every* time you render something is of course going to totally destroy your framerate. Start using it properly and you''ll start seeing results.

Just to give you an incentive... I rendered a similar number of poly''s on my Ti4200, and I got a 50-60% speed increase (100->160fps) by using VBO ( well, it was VAR at the time, but it''s the same sort of thing ).

You have to remember that you''re unique, just like everybody else.

Ysaneya

Jun 8, 2004 at 11:12 AM

quote:

No, you''re just not using it correctly

I don''t know, his code looks messy but correct. He''s using a static bool to determine if the VBO has been already created or not.

Y.

python_regious

Jun 8, 2004 at 11:23 AM

Oh aye...

Hmmm, that''s strange. Well, a couple of things then.

Try using DrawRangeElements; Some cards have a problem with data not being 4-byte aligned. Make sure thats the case.

You have to remember that you''re unique, just like everybody else.

cippyboy

Jun 8, 2004 at 11:46 AM

Well first of all Im impressed that not too many figured out that what I do with the static vars... but thats not the point, the point is that I used that with glDrawRangeElements() I just dont see the differences, and I dont get the vertex/index limit size of this function... it

s 4096 on my card... should that mean that I have to pass 4096 vertices/indices limited objects to the card and that way it

s gonna be faster ? I thought that the smaller the number of objects, the faster it renders... please corect me if I`m wrong.

...and to think that initially I thought this was going to be my pot of wonders...

[edited by - cippyboy on June 8, 2004 12:51:02 PM]

python_regious

Jun 8, 2004 at 1:15 PM

Read the spec on the DrawRangeElements extension to understand what it does and why ( the limits imposed will become apparent then ).

Also, are you sure you aren''t fillrate limited? If you are, then VBO won''t make too much of a difference.

>>I thought that the smaller the number of objects, the faster it renders

Not entirely accurate. It''s all to do with state changes, vertex throughputs, and fillrate - and can get quite complicated.

You have to remember that you''re unique, just like everybody else.

python_regious

Jun 8, 2004 at 1:18 PM

One more thing, I''m starting to think you''re doing something terribly wrong elsewhere, as your vertex throughput is really low. 1.2MVs^-1 is pretty crap, especially since you aren''t even using any textures.

You have to remember that you''re unique, just like everybody else.

Ysaneya

Jun 8, 2004 at 3:31 PM

It''s unlikely to be a fillrate problem if switching from display lists to VBO makes his framerate drop from 15 fps to 2 fps. His data is aligned to 4 bytes, since he''s only using 3 floats for vertex positions.

Ok, the first thing to do is to split your mesh in sections of max 65536 vertices each (the amount of indices doesn''t matter, but each index should not have values higher than 65535). If you''re trying to access more, the driver might fall back into software transform & lighting, which would explain what you see.

Also make sure your drivers are not too old.

Finally if you still experience bad performance i''d recommend switching to the VAR extension. I''ve seen some NVidia cards perform badly with VBO but extremely well with VAR, especially on laptops or PCI FX 5200s.

Y.

python_regious

Jun 8, 2004 at 4:07 PM

Yeah, I agree about the fillrate issue. Twas a bottom of the barrel thing.

Since he gets such a crap throughput even with DL''s, I still think he''s doing something wrong else where in the program.

You have to remember that you''re unique, just like everybody else.

cippyboy

Jun 9, 2004 at 7:12 AM

I have to write some more code to do that, Im curently wirintg an importo from VRMLs and didnt finished it, since 3DS are limited to 64K poly export(I think it has something to do with the chunks and jump bytes, I guess It

s a WORD).

And... what do you mean by fill rate limited ?

PS:what exactly should the fill rate mean ? I

ve heard many things about it but... I dont know what it is exactly, and I havent tryed to find documentation... yet

by VAR you mean the GL_NV_vertex_array_range(2) right ? I`ll try to find some usage of that and come back with the results.

python_regious

Jun 9, 2004 at 7:42 PM

The fill rate is essentially how many pixels are drawn. If your fps changes alot by changing the resolution of the screen for instance, will imply that you are fillrate limited.

Indeed, VAR = vertex_array_range(2).

You have to remember that you''re unique, just like everybody else.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.