Jump to content

  • Log In with Google      Sign In   
  • Create Account


VBO slow


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Tommato   Members   -  Reputation: 128

Like
0Likes
Like

Posted 18 March 2013 - 12:10 PM

Hi All
 
I've implemented VBO but got a slower render (only 1 fps vs 3 fps without VBO).
After series of experiments I've found the problem is caused by using GL_DOUBLE for at least one chunk (vertices, normals, UVs etc). With GL_FLOAT for everything my results are good: 17 fps with VBO. So my questions are:
 
- is a low speed normal/expected with GL_DOUBLE ?
- how can I make VBO faster yet?
 
My setings are:
 
OpenGL Vendor: ATI Technologies Inc.
OpenGL Renderer: ATI Radeon HD 2600 OpenGL Engine
OpenGL Version: 2.1 ATI-1.6.36
 
Vertices 756,780
Polygons 1,169,235
Objects 150
VBO buffers: 150 * 2 = 300 
(GL_ARRAY_BUFFER_ARB + GL_ELEMENT_ARRAY_BUFFER_ARB) both GL_STATIC_DRAW_ARB
Using glDrawElements
Shading: gourand
Total VBO RAM: 42,513.104
 
Thanks
Tom

Edited by Tommato, 18 March 2013 - 12:11 PM.


Sponsor:

#2 Waterlimon   Crossbones+   -  Reputation: 2313

Like
0Likes
Like

Posted 18 March 2013 - 12:23 PM

AFAIK usually you would use floats and not doubles on the GPU

 

Thats a lot of triangles and your GPU doesnt seem that powerful, so i would say your usage of VBO's isnt the problem, simply the amount of work youre trying to do.

 

Assuming your shader isnt full of ifs, what you should do is reduce the amount of triangles you draw. Dont draw objects outside the screen, draw far away stuff with lower detail (LoD)...


Edited by Waterlimon, 18 March 2013 - 12:24 PM.

Waterlimon (imagine this is handwritten please)


#3 mhagain   Crossbones+   -  Reputation: 7328

Like
2Likes
Like

Posted 18 March 2013 - 01:05 PM

Unless you have the GL_ARB_vertex_attrib_64bit extension available you can safely assume that any GLdouble vertex input is going to be software emulated - in immediate mode by casting your glVertex3d parameters down to float, with VBOs by potentially running your entire per-vertex pipeline in software.  Obviously that would result in VBOs being somewhat slower than immediate mode code, which is exactly what you've observed.

 

Double-precision support in hardware is still relatively new (requiring SM5 hardware IIRC), and the moral of the story is that even if the GL spec allows it for a particular call, don't always assume that it means your hardware supports it (especially if it's from an older part of GL that pre-dates hardware T&L).

 

How can you go faster still?  If you're not already doing it, then consider interleaving your vertex struct.  I.e. instead of:

 

GLfloat positions[ARBITRARY_NUMBER];
GLfloat normals[ARBITRARY_NUMBER];
GLfloat texcoords[ARBITRARY_NUMBER];

 

Use:

 

struct myVertex
{
    GLfloat position[3];
    GLfloat normal[3];
    GLfloat texcoord[2];
};

myVertex vertices[ARBITRARY_NUMBER];

 

This can be a win as it means that your GPU can now read all data for each vertex together, and without having to do any random jumping around in memory.

 

Another thing you can do, since you have an older GPU that only supports GL2.1, is to use GL_UNSIGNED_SHORT instead of GL_UNSIGNED_INT for your GL_ELEMENT_ARRAY_BUFFER, if you can get away with it.  This is also coming back to the "don't always assume that hardware supports what the GL spec allows" point, and a GPU that old may not support 32-bit indices very well (or at all!)

 

Finally, and to cut down on buffer changes, you could consider packing all objects into a single VBO (rather than 150 * 2 separate VBOs) and using the parameters to your glDrawArrays/glDrawElements calls (or the offsets specified by your gl*Pointer calls) to select which object gets drawn.  This may or may not be compatible with using 16-bit indices however, so you'll need to profile both approaches and see which works best for you.


Edited by mhagain, 18 March 2013 - 01:15 PM.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#4 Geometrian   Crossbones+   -  Reputation: 1413

Like
0Likes
Like

Posted 18 March 2013 - 05:48 PM

you can safely assume that any GLdouble vertex input is going to be software emulated . . . with VBOs by potentially running your entire per-vertex pipeline in software

Perhaps I'm missing something, but it was my understanding that when transferring a static VBO from the client to the GPU, the actual data is copied over--so any doubles ought to have been already converted to floats in this case as well?

In the face of this, I might suspect something else may be afoot; for example, are you sure you're using VBOs, or are you using vertex arrays accidentally instead?


And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.

#5 mhagain   Crossbones+   -  Reputation: 7328

Like
0Likes
Like

Posted 18 March 2013 - 06:24 PM

Perhaps I'm missing something, but it was my understanding that when transferring a static VBO from the client to the GPU, the actual data is copied over--so any doubles ought to have been already converted to floats in this case as well?

 

The data type is only specified at the gl*Pointer stage, by which point the VBO has already long been copied over.  glBufferData itself is totally type agnostic; it doesn't care whether you've floats, doubles, plain text or even a JPEG in there - it just transfers a block of memory to the buffer object.  gl*Pointer is what defines how that memory is interpreted.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#6 Tommato   Members   -  Reputation: 128

Like
0Likes
Like

Posted 20 March 2013 - 06:11 AM

Unless you have the GL_ARB_vertex_attrib_64bit extension available you can safely assume that any GLdouble vertex input is going to be software emulated -

Thanks for your complete answer, clear now

 

Thanks all for your replies. The spedup to 17 fps (from inital 3-4) is a real progress for my app, but how good it is for VBO? Just some articles promises huge speedups like in 100 or more times (although IMO it's out of common sense). In other words should I apply more efforts to achieve better performance or it's already acceptable enough? Note: with GL_DYNAMIC_DRAW_ARB I've 14-15 fps (instead of 17 with static)

 

Thanks

Tom



#7 wintertime   Members   -  Reputation: 1574

Like
0Likes
Like

Posted 20 March 2013 - 12:06 PM

The advantage of a VBO is basically just that the data can be put in there and uploaded once and then used multiple times for drawing(thats what static draw is hinting at). If someone does not follow this pattern and changes the data every frame and then immediately draws from it there is not much to gain for him compared to a vertex array(there you are supposed to give dynamic draw hint though it depends on the driver how/if that makes a difference).

I very much doubt a 100 times speedup even if those people only specified single vertices in immediate mode.



#8 mhagain   Crossbones+   -  Reputation: 7328

Like
0Likes
Like

Posted 23 March 2013 - 08:02 AM

I can see how 100x could be achievable.  First of all the program has to be completely vertex-bound, let's say drawing millions of points with each individual point being in it's own glBegin/glEnd pair.  Then, it needs to be doing virtually nothing else on the GPU - so all of those points are offscreen.  Switch that to using a VBO and a single draw call, and you'll see huge performance increases of that magnitude.

 

For more realistic real-world programs that people actually write you're not going to see increases like that at all.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS