Archived

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

Lyve

Speed of GL_ARB_vertex_buffer_object

Recommended Posts

Lyve    116
Hello members, do some people have any experiences using the GL_ARB_vertex_buffer_object extension? What speed increase do you get in comparison with glDrawArrays() / glDrawElements using normal local buffers? I have a Geforce 3 Ti 200 with a AMD XP 2400+ as host CPU and there''s no difference in speed. I installed the latest drivers 44.03 (downloaded today). Maybe this is normal because the driver from NVidia doesn''t support it in hardware for a Geforce 3? I doubt that because I thought hardware vertex buffers are supported since a long time (at least in DirectX, I thought the new extension is something similar?) I will check it tomorrow at my workplace, there I have a Geforce 4 Ti 4200 with an AMD XP 1800+, maybe the results are better. Any tips or explanations for my Geforce 3?

Share this post


Link to post
Share on other sites
Corrail    133
Maybe I''m wring but I think I''ve reard that nVivia drivers aren''t very fast with ARB_vbo. So this could be a driver problem.

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

"If it looks good, it is good computer graphics"
"If it looks like computer graphics, it is bad computer graphics"

Corrail
corrail@gmx.at
ICQ#59184081

Share this post


Link to post
Share on other sites
python_regious    929
Depends how many vertices you''re rendering, and where the vertices were placed. I only have experience with the NV extension, and I got a 50% speed increase using that... ( rendering 35000 poly''s ).

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
Lyve    116
Actually I need it to render 320.000 *POINTS* together with normals, no polygons.
But especially with points I would think that it is a BIG difference if the points are stored in video rather than computer memory, because the fillrate is not very high, in contrast to the AGP bus usage.

Share this post


Link to post
Share on other sites
BGCJR    100
there is no difference between VAR and VBO with speed.
I''m using GF FX 5600 w/256. I guess it''s a bridge for all video cards.

Bobby

Share this post


Link to post
Share on other sites
Lyve    116
If there''s no speed difference, why does the extension exist? At least a Geforce FX should show a difference I think.

Share this post


Link to post
Share on other sites
BGCJR    100
i thought i can''t use it for both nvidia and ati.
It runs on GF FX but on an ATI 9700 pro, it crashes.

now, How am I suppose to debug it?

The ARB is suppose to run on both between video cards.
this same program before adding VBO worked fine on both.
There are issues about VBO.

Bobby

Share this post


Link to post
Share on other sites
_DarkWIng_    602
VBO will help you if you are geometry bound. Speed-ups can be anywhere from 0 to 300% (I''ve got about 50-150% increase in my terrain engine). If you aren''t getting any speedups you are either not geometry bound or (more likely) doing something wrong. In your case with particels. You have to create DYNAMIC_DRAW_ARB buffer and only write to it (never read from VBO - it will kill your performance).

Corrail : nVidia''s drivers work just great with VBO (same speed as VAR)

You should never let your fears become the boundaries of your dreams.

Share this post


Link to post
Share on other sites
Corrail    133
Oh, ok.
I thought I''ve read that nVivida had problems in earlier drivers with them.

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

"If it looks good, it is good computer graphics"
"If it looks like computer graphics, it is bad computer graphics"

Corrail
corrail@gmx.at
ICQ#59184081

Share this post


Link to post
Share on other sites
RipTorn    722
Ok..

this is a complex one, since there are several things that can cause performance issues...

The advantage of GL_ARB_vertex_buffer_object, or the Ati/Nvidia equivalents (which are a waste of time now) mostly comes into play with static geometry. Dynamic data can be sped up if you upload the data before you actually draw from it (so the video card doesn''t need to wait for the copy to complete) but it''s not as significant.

Simply put, it''s also a matter of fill rate. A particle system, for example, is an example of something that VBO won''t help you with at all.

Using standard arrays with glDrawElements, you will be looking at a maximum triangle/sec throughput rate of around about 4-6 million triangles a second (on agp 4x)... This is when there are no other bottlenecks, and fill rate isn''t an issue at all, and the cpu is mostly idle. If you drawing solidly though, and the cpu is busy, etc, then 2 million is a more realistic limit.

That said, if the data is already there for the video card, then it can simply ''go nuts'' and draw away, not having to worry about waiting for the data/cpu. This is where VBO can give you _massive_ speed improvments, getting to a decent chunk of the theoretical speed of the video card... With small triangles, being lit by 1 point light, 1 texture, etc, it''s possible to get a radeon 9500-9800 into the 50-60 million tris/sec area.

The thing is you usually don''t get triangles this small, this is where fill rate is the biggest hit. A quake3-style map, where every pixel is drawn one or two times, is always going to max out at X frames per second, be it showing 3,000 triangles or 30,000. since it fills the whole screen, it''s just because of this, you can generally add a lot of extra detail without much of a performance hit.

As for hardware,
geforce 1 and the origianl Radeon were the first cards to do hardware transform and lighting.
And if the ati card is crashing, it may be a lack of driver support in the version you have, since this is a very new extension.

It should be noted that D3D8+ effectivly forces you to do what this extension does. Which is a very good thing.

| - Project-X - On hold.. - | - adDeath - | - email me - |

Share this post


Link to post
Share on other sites
BGCJR    100
I differ.
You can load the data on the fly and still have great performance. my model editor does this. And 4 opengl windows and 81000 poly scene in each is just alittle sluggish.


Bobby

Share this post


Link to post
Share on other sites
vincoof    514
quote:
Original post by Lyve
If there''s no speed difference, why does the extension exist? At least a Geforce FX should show a difference I think.


If there is no difference between VAR and VBO, that''s absolutely normal.
VAR is already a vertex throughput improvement.

Anyway, the first NVIDIA drivers I''ve tested did not give any performance boost, when any. But now they seem to be much better.
As a side note, this time ATi was more reactive. That was probably because the VBO extension is closer to the ATI_VAO extension than the NV_VAR one.

Share this post


Link to post
Share on other sites