Geometry storage in modern 3D hardware

Hello,

I’m actually rather new to OpenGL but I figured my question belonged on this board.

I was wondering if anyone can point me to any detailed information on how modern (or relatively modern) 3D accelerators receive, store, and process geometry data. Information on how particular OpenGL implementations handle it would be a plus.

I’ve been reverse engineering some fairly old arcade 3D hardware that was cutting edge in 1996 (done by Real3D and based on the Pro-1000.)

It consists of 2 GPUs which seem to operate in parallel and use common memory areas for storing textures and geometry data. Performance is rated at 1 million quads/s or 2 million triangles/s (probably mostly marketing hype ) It also seems to have the ability to have geometry and stored in VROM (not sure yet if it internally performs a transfer to some sort of cache RAM – ROM is usually slow after all.)

Anyway, it has something referred to as “culling RAM” which basically stores a form of scene graph data.

The GPUs can walk through this and parse simple data tables and draw commands. The commands reference 3D models in VROM or in polygon memory. The GPUs rasterize models (composed of triangles, quads, and strips for both) until they hit a stop bit.

Basically, the idea is that geometry data and scene data does not have to be changed much by the CPU once it is uploaded. In fact, the only updates that the CPU performs per frame are sometimes just a single 3x4 matrix upload to adjust a transform matrix (the scene graph data specifies which matrix in the culling RAM to use.)

Do modern GPUs behave in an analogous way? It almost seems as though the geometry has to be uploaded on a per-frame basis. I haven’t investigated OpenGL’s commands for making display lists or using vertex arrays and how they might be cached by the GPU, so I could be underestimating the cleverness of modern GPUs with regards to how they manage geometry.

I’m really just curious and hope someone can answer my questions or point me in the right direction. I’ve been searching around but haven’t found anything particularly descriptive.

Thanks!

Originally posted by trzy:
It almost seems as though the geometry has to be uploaded on a per-frame basis. I haven’t investigated OpenGL’s commands for making display lists or using vertex arrays and how they might be cached by the GPU, so I could be underestimating the cleverness of modern GPUs with regards to how they manage geometry.

You can upload vertex (and index) data with OpenGL. It’s not a whole modell, but it’s the main part of the objects.
See VBO extension.

VBO = Vertex Buffer Object
GL_ARB_vertex_buffer_object is the whole name.

-SirKnight

Originally posted by Csiki:
You can upload vertex (and index) data with OpenGL. It’s not a whole modell, but it’s the main part of the objects.
See VBO extension.

How is it done without this extension? The code I’ve seen seems to just draw everything each frame. I glanced over Quake II, for example, and it appeared to use glVertex3f() calls to update the scene and I don’t think it even used display lists.

I read up on display lists and it seems that a sophisticated GL implementation could convert the data written to a list into some internal geometry data stored in the GPU’s RAM.

Is this how today’s high-performance Nvidia and ATI cards handle lists?

It just seems awfully wasteful to upload vertex data on each frame when all that’s really needed in many cases is just some new matrix data.

Originally posted by trzy:
How is it done without this extension? The code I’ve seen seems to just draw everything each frame. I glanced over Quake II, for example, and it appeared to use glVertex3f() calls to update the scene and I don’t think it even used display lists.

Display lists are very very static, and the programer doesn’t know the time cost of the creation.
The VBO extension is quite new, you won’t find it in older programs (there were some vendor dependent solution though).


I read up on display lists and it seems that a sophisticated GL implementation could convert the data written to a list into some internal geometry data stored in the GPU’s RAM.

Again. We (programers) don’t know what the display list exactly do. It may happen that the data stored in the CPU’s memory, but in a more GPU friendly format, and easier to send to the graphics card.


Is this how today’s high-performance Nvidia and ATI cards handle lists?

Only the driver manufacturers know.


It just seems awfully wasteful to upload vertex data on each frame when all that’s really needed in many cases is just some new matrix data.

Yes. That’s why you can upload the vertex data once, and use more…
This is the VBO.
New programs are using DrawArrays and DrawElements instead of VertexXXX.

VBO is new but before it, there was Nvidia’s VAR (vertex array range) and it’s AGP memory allocation technic.

ATI had it’s own method VAO (vertex array object) which probably made use of AGP as well.

I think no other company had anything similar. So you had to use compile lists and such on those.

You can read about the specs at
http://oss.sgi.com/projects/ogl-sample/registry/

Originally posted by trzy:
[b]Hello,

I’m actually rather new to OpenGL but I figured my question belonged on this board.

I was wondering if anyone can point me to any detailed information on how modern (or relatively modern) 3D accelerators receive, store, and process geometry data. Information on how particular OpenGL implementations handle it would be a plus.

I’ve been reverse engineering some fairly old arcade 3D hardware that was cutting edge in 1996 (done by Real3D and based on the Pro-1000.)

It consists of 2 GPUs which seem to operate in parallel and use common memory areas for storing textures and geometry data. Performance is rated at 1 million quads/s or 2 million triangles/s (probably mostly marketing hype ) It also seems to have the ability to have geometry and stored in VROM (not sure yet if it internally performs a transfer to some sort of cache RAM – ROM is usually slow after all.)

Anyway, it has something referred to as “culling RAM” which basically stores a form of scene graph data.

The GPUs can walk through this and parse simple data tables and draw commands. The commands reference 3D models in VROM or in polygon memory. The GPUs rasterize models (composed of triangles, quads, and strips for both) until they hit a stop bit.

Basically, the idea is that geometry data and scene data does not have to be changed much by the CPU once it is uploaded. In fact, the only updates that the CPU performs per frame are sometimes just a single 3x4 matrix upload to adjust a transform matrix (the scene graph data specifies which matrix in the culling RAM to use.)

Do modern GPUs behave in an analogous way? It almost seems as though the geometry has to be uploaded on a per-frame basis. I haven’t investigated OpenGL’s commands for making display lists or using vertex arrays and how they might be cached by the GPU, so I could be underestimating the cleverness of modern GPUs with regards to how they manage geometry.

I’m really just curious and hope someone can answer my questions or point me in the right direction. I’ve been searching around but haven’t found anything particularly descriptive.

Thanks![/b]

Seems like an efficient way to handle this kind of stuff, CPU bus utilization in this case would be so low, quite impressive hardware.

Originally posted by amdTB:

Seems like an efficient way to handle this kind of stuff, CPU bus utilization in this case would be so low, quite impressive hardware.

Yeah. The host CPU was a 66MHz PowerPC for the initial version of the hardware. The graphics capabilities were quite impressive.

Thanks for all the responses. It seems like the newer extensions and display lists are much more efficient when it comes to handling vertex data.

I’ve heard Direct3D uses vertex buffers that can be uploaded to the card but I’m not planning on using Direct3D since I need OpenGL’s portability.