Is Vertex Buffer extension "much more" faster than Display Lists?

Started by
28 comments, last by owl 20 years, 5 months ago
quote:Original post by benjamin bunny
Anim-   Smooth Skinning	Render  FPS     Tris/sec        Time /ation	motion          Method			        Frame (MS)Yes	Yes	Yes	IM	27.77	1,329,405	36.01Yes	Yes	Yes	VA	46.8	2,240,410	21.37Yes	Yes	Yes	VBO	47.11	2,255,250	21.23Yes	No	Yes	IM	28.91	1,383,980	34.59Yes	No	Yes	VA	48.4	2,317,005	20.66Yes	No	Yes	VBO	49.49	2,369,185	20.21Yes	Yes	No	IM	53.39	2,555,886	18.73Yes	Yes	No	VA	119.23	5,707,779	8.39Yes	Yes	No	VBO	170.99	8,185,633	5.85No	No	No	IM	63.08	3,019,766	15.85No	No	No	VA	171.12	8,191,857	5.84No	No	No	VBO	300.01	14,362,079	3.33    

Abbreviations: IM: Immediate mode; VA: Vertex Arrays; VBO: ARB_vertex_buffer_object


That looks good. Which configuration has the computer in which you ran that test?
[size="2"]I like the Walrus best.
Advertisement
The computer is an Athlon 2100+ (1.733GHz), 512MB 333MHz DDR-RAM, Radeon 9700 Pro.

A few more details I should probably have mentioned: lighting was enabled, with a single light; the vertex data included colours, normals and texture coords. In the test I rendered 64 meshes at a time, with 748 triangles in each, and measured the frame rate over 100 frames. In the tests with skinning enabled, the vertex normals and positions for each mesh were updated every frame, which is why VBO wasn't that much quicker than VAs. Animation refers to bone animation. Smooth motion is an option to smoothly interpolate between frames. The executable was a release build with VC.net 2003 with the O7 command line option set (optimise for P4 and above).

I think that about covers it

____________________________________________________________
www.elf-stone.com | Automated GL Extension Loading: GLee 2.00 for Win32 and Linux

[edited by - benjamin bunny on November 13, 2003 12:15:26 AM]

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

quote:Original post by _the_phantom_
be intresting to see the kinda fps you get when using VBOs and the matrix palette stuff (the proper name escapes me atm) as you could render each bone segment with a different call and matrix to allow for animation, kinda the best of both worlds in a way, animation with the vertex data locked on teh card
(this is assuming i've understood the extension right, hehe)


The vertices are affected by multiple bones, so they have to be transformed with multiple bone matrices; the only option is to manually update the vertex positions, which is precisely where VBO falls down. I'm planning on putting all the skinning code into a vertex shader eventually, which should solve this problem.

____________________________________________________________
www.elf-stone.com | Automated GL Extension Loading: GLee 2.00 for Win32 and Linux

[edited by - benjamin bunny on November 13, 2003 12:25:30 AM]

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

quote:Original post by benjamin bunny
quote:Original post by Anonymous Poster
from my expierence i can tell you, VAs are faster! and another advantage is that if you have created a vertex manager, and if you use indexed VAs, you can save a large amount of memory! (two points who are the same are only included once)


VAs are never going to be faster than VBO on a T&L card unless you''re doing something very wrong, or possibly you''re updating the geometry every frame (ie for skinning).

Here''s my experience, from a report on skinning and mesh rendering performance that I wrote recently. The bottom 3 rows are without animation or skinning, so they''re the most applicable to general mesh rendering. BTW, the skinning method I''m using here isn''t exactly optimal yet, so the figures for that are somewhat distorted. All these tests were done with a Radeon 9700 pro.

Anim-   Smooth Skinning	Render  FPS     Tris/sec        Time /ation	motion          Method			        Frame (MS)Yes	Yes	Yes	IM	27.77	1,329,405	36.01Yes	Yes	Yes	VA	46.8	2,240,410	21.37Yes	Yes	Yes	VBO	47.11	2,255,250	21.23Yes	No	Yes	IM	28.91	1,383,980	34.59Yes	No	Yes	VA	48.4	2,317,005	20.66Yes	No	Yes	VBO	49.49	2,369,185	20.21Yes	Yes	No	IM	53.39	2,555,886	18.73Yes	Yes	No	VA	119.23	5,707,779	8.39Yes	Yes	No	VBO	170.99	8,185,633	5.85No	No	No	IM	63.08	3,019,766	15.85No	No	No	VA	171.12	8,191,857	5.84No	No	No	VBO	300.01	14,362,079	3.33    

Abbreviations: IM: Immediate mode; VA: Vertex Arrays; VBO: ARB_vertex_buffer_object

[edit: fixed column headers]


[edited by - benjamin bunny on November 13, 2003 7:31:08 PM]

[edited by - benjamin bunny on November 13, 2003 7:32:13 PM]


Something isn''t right about that.. I''m running an athlon xp 1600, radeon 9200, and drawing my terrain + models I am hitting over 20M triangles per second... using just vertex arrays, so no clue how you''re getting such low numbers with normal VA''s and VBO''s. Actually, I am using lock/unlock with the vertex arrays. It falls back to not using lock/unlock if not available, I haven''t had a chance to implement VBO''s yet (I think it''s finally implemented for my card in the latest drivers, i have to check though, last time I looked it wasn''t there).
first: it seems some drivers have weird vbo issues resulting in bad performance. if you either allocate too much or too little memory (depending on card and driver) you might just get system memory. you could for example try to allocate less than 6mb of video memory or more than 12 (even if you dont need it, just for testing).

about skinning. it required vertex programs to let me see an efficient solution to the problem i had with it (meaning: i do absolutely NOT want to touch the vertices of the skin myself). the ability of storing 12 matrices/bones should easily let you do the whole skinning in the vertex shader, though having a lot of work to do for each vertex i would definitely make sure to use the cache as good as possible. more complex models would require multiple calls and changing the matrices.

btw. if you use lock/unlock and do that maybe only once it might very well be that the driver is copying it to video memory which might be more or less as fast as vbo, depending on how they implemented it. anyways, you are not using "just vertex arrays".
f@dzhttp://festini.device-zero.de
I was thinking, does anything actually prevent an opengl implementation from making a VBO behind the scenes when you compile a display list?
super genius
quote:Original post by Ready4Dis
Something isn't right about that.. I'm running an athlon xp 1600, radeon 9200, and drawing my terrain + models I am hitting over 20M triangles per second... using just vertex arrays, so no clue how you're getting such low numbers with normal VA's and VBO's. Actually, I am using lock/unlock with the vertex arrays. It falls back to not using lock/unlock if not available, I haven't had a chance to implement VBO's yet (I think it's finally implemented for my card in the latest drivers, i have to check though, last time I looked it wasn't there).


I suspect it's because I'm only sending 300 vertices per batch, which isn't particularly efficient with vertex arrays or VBO. I get much higher numbers with terrain, where I send data in blocks of at least 1039 vertices. Bear in mind also that lighting makes a big difference to frame rate.

quote:
about skinning. it required vertex programs to let me see an efficient solution to the problem i had with it (meaning: i do absolutely NOT want to touch the vertices of the skin myself). the ability of storing 12 matrices/bones should easily let you do the whole skinning in the vertex shader, though having a lot of work to do for each vertex i would definitely make sure to use the cache as good as possible. more complex models would require multiple calls and changing the matrices.

That's pretty much the solution I've come up with. My reason for implementing it in software first is as a fall-back where ARB_VP is not available.

____________________________________________________________
www.elf-stone.com | Automated GL Extension Loading: GLee 2.00 for Win32 and Linux

[edited by - benjamin bunny on November 14, 2003 3:28:22 PM]

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

i admit im a feature bitch. if a solutions doesnt look sleek and streamlined i put it aside until the right feature or extension allows to do it in the way i was hoping for. in other words, i would be to lazy to write a fall back, at least as long as im not paid for it ,)
f@dzhttp://festini.device-zero.de
I''m trying to get into the habit of coding fallbacks for in case I''m not working on my own computer. I always have my stuff on an FTP server so I can work on it at school. Unfortunately, integrated Intel graphics or TNT2s. . . Yeah, you get the picture.
-Ostsol
Well it''s not related to the topic but since there is some mention of skinning, i would like to ask exactly how you go about doing it.

You got the bones, affected vertices and some matrices thrown up by 3d modelling software like Max.

1)Do you calculate the new position of the vertices and then assemble them all into 1 array and pass it to the card? In this case how do you calculate the new position with just martrices? Do you extract the rotation/translation values from the matrice? If you do, how do you extract it?(Sorry im not good with Matrice math)

2) Do you render each bone then apply the matrice to the ModelView matrix then render another bone, etc..? If you do it this way, how do you calculate vertices being affected by more than 1 bone? I believe this method is faster since you only apply the matrice once per bone. But how will you do interpolation using this method?

This topic is closed to new replies.

Advertisement