Problem with VBOs

Originally posted by jide:
[b] …
What have you got if you use VBO without indicies ?

Also, give the full sources, I guess it will be easier. [/b]
Not sure but I think after I removed the lines the speed was almost the same as using indices.

Anyway, if anyone is interested here are the links to source and exe. The VBO code is in the ABTNode class (InitializeVBOs, Render…)

Source (1.7MB)
Exe (1.2MB)

It’s an app I coded last year but I had never used VBOs hehe…

Originally posted by Komat:
[b]
It is combination of two things:

  1. One or more from those lines (probably something from the glHints) forced the driver to do software vertex processing instead of using hw vertex processing unit because the hw does not support that particular feature.
  1. The VBO content was very likely stored in video memory or other uncached memory so the graphics card does have fast access to it. Reading from such memory by CPU is very slow, especially if special care is not taken.

Because the driver was emulating vertex processing on CPU and was reading from the memory optimized for GPU access, the result was slow. Without the VBOs, the driver was reading data from cached memory that is optimized for access by the CPU and the performance was significantly better. When you commented out those lines, the vertex processing reverted to the hw one which has no problems with reading from the memory in which the VBO was stored. [/b]

Thanks for that explanation :slight_smile:

Originally posted by jide:
I really don’t understand why a glHint could participate to produce such a drop. Isn’t that glHint only a hint for the driver, not an obligation to exectute ?
Yes, it is not obligation. The driver was tasked to use the highest quality option and it probably decided to provide the highest quality regardless of the cost. That is perfectly valid behaviour and maybe it was beneficial for some old pre-VBO application.