• Advertisement

Archived

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

Speed of GL_ARB_vertex_buffer_object

This topic is 5366 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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
Advertisement
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
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
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
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
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
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
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
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
Found my problem.
I did away with mapped values and just through they in a malloc array( instead of STL vector).

Share this post


Link to post
Share on other sites

  • Advertisement