Well, i wouldn’t like to bring some bad news concerning the VBO extension but…
the specs are saying: 2.8A.1 Vertex Arrays in Buffer Objects
--------------------------------------
Blocks of vertex array data may be stored in buffer objects with the
same format and layout options supported for client-side vertex
arrays. However, it is expected that GL implementations will (at
minimum) be optimized for data with all components represented as
floats, as well as for color data with components represented as
either floats or unsigned bytes.
Blah blah which sounds like VBO is a VAO sequel! ;-))
Anyhow, let’s imagine i really don’t care about using floats &| bytes where it is intended to with the following vertex format ->
Moreover, using the same data structures with CVA or other mechanism instead of VBO there is no problem… argh…
Of course there’s no problem; they have to do a copy to video-card accessible memory anyway.
The hardware cannot recognize most formats for most components. It can recognize floats for components, as well as GL_BYTE for colors. That’s it. If you use anything else, it will impose a significant speed hit under VBO. So, don’t do it.
Under CVA, since there’s a copy anyway, they have the ability to convert any data you store into an appropriate format for the video card.
Originally posted by Korval: The hardware cannot recognize most formats for most components. It can recognize floats for components, as well as GL_BYTE for colors. That’s it. If you use anything else, it will impose a significant speed hit under VBO. So, don’t do it.
.
Well, i agree that there should be some performance penalties when using data components that are not matching the hardware.
As far as i know, early GF boards can support GL_SHORT for normals (using VAR) so i expect them to be treated as is internally.
Moreover, i only got a problem with rendering which is certainly related with how normals dataformat are interpreted in the case of GL_BYTE,GL_SHORT and GL_INT
In other words, if it works with CVA (even with an internal conversion from the driver)
it should work with VBO and even with speed penalties :))
Finally, regarding FLOAT versus others components types i was amazed to see (using VAR again) that GPU was faster processing short structures including GL_SHORT for vertex coordinates, GL_UNSIGNED_BYTE for colors and finally GL_SHORT for normals vs
a all in GL_FLOAT structure
Korval you’re pointing out what is written into the specs ->
2.8A.1 Vertex Arrays in Buffer Objects
--------------------------------------
…
However, it is expected that GL implementations will (at
minimum) be optimized for data with all components represented as
floats, as well as for color data with components represented as
either floats or unsigned bytes.
…
ok then, not regarding the speed others components should work aswell?
There was a problem in some drivers where mixing numbered attributes for some arrays, and legacy names/bindings for others, would make it not work right. I forget the details, but if you’re using both VertexAttribPointer and NormalPointer, this might be the issue.
allright, waiting for the implementation fix (if there is a bug there… nv guys any comment?)
Now, for testing pruposes, i would like to switch from VAR to VBO or any other GL mechanism.
Unfortunately it seems that it causes probs to have VAR and VBO both initialised. Of course, they are certainly using the same memory allocation mechanism (when u need to store data onboard -equ- static) thus, at first i tried to only disable GL_VERTEX_ARRAY_RANGE_NV but using VBO then i get no display anymore…
Finally i tried to free VAR memory using:
…
wglFreeMemoryNV(pFastMem);
…
but it seems that VBO always fall back to vertexArrays, something like there is no more Vram available = switch to VA.
I’ve got a Radeon 9800 pro. If I use gl_short as an vertex attrib format, the program becomes incredible slow. With gl_float there is no problem. The GF4 has had no problems when using gl_short. Is this a hardward limitation of the Radeon 9800?
Well, it was already that case using VAO…
(much more buggy btw)
ATI implementation seems rather limited in term of functionality regarding the available formats. Thus as suggested by Korval and the specs you should use float everywhere to get the best results from one board to another. :((
as it is written : this is a minimum ;(
Anyhow… what about the speed on your radeon using GL_SHORT? same as CVA i guess? ;-))
What kind of struct do you use?
drivers version?
With 44.90 Nv implementation just do like the Radeon implemenations, with customs formats they fallback to VertexArrays mechanisms… (well, it seems too… something similar btw)