Open GL and hardware T&L

[slaterat]

Does open GL use the harware T&L on crrent generation videocards? Or does the cpu handle thses calculations?

 

[OpenGL guy]

Does open GL use the harware T&L on crrent generation videocards? Or does the cpu handle thses calculations?

Completely driver and HW dependent. If your HW supports T&L, chances are the driver will use it.

 

[K.I.L.E.R]

One thing I don't understand, why is it that games in GL can use T&L if they haven't been programmed with it in mind.

But Direct3D on the other hand, you must program for it.

 

[OpenGL guy]

One thing I don't understand, why is it that games in GL can use T&L if they haven't been programmed with it in mind.

But Direct3D on the other hand, you must program for it.

It depends on the game. Some games do their own transforms. This applies to both OpenGL and D3D. In OpenGL, as long as you use the API's transform routines, you can get HWTL. In D3D, this won't be the case unless you select HARDWARE_VERTEX_PROCESSING or MIXED_VERTEX_PROCESSING when you create your D3D device.

 

[K.I.L.E.R]

Thanks for clearing that up.
I wander how many games use their own transform calcs?

 

[OpenGL guy]

Thanks for clearing that up.
I wander how many games use their own transform calcs?

Lots of old games, because they could do things more efficiently than a general purpose driver. Now that pretty much all chips have HWTL/VS things are done in the drivers 99% of the time.

 

[nutball]

One thing I don't understand, why is it that games in GL can use T&L if they haven't been programmed with it in mind.

The fixed-function OpenGL pipeline was designed with hardware acceleration in mind. The idea being each pipeline stage could be either a software or a hardware implementation. The driver would sort it all out, the application would only care at the level of whether performance was acceptable or not. Generally the more expensive the hardware, the further up the pipeline the software stopped and the hardware started.

 

[Rodéric]

To me the T part is computing the vertex pos using the current modelview matrix, in that case, I don't think that many games don't use hardware Transform and rely on their own routines.

The Light side however is less likely to be used in older games, and newer titles also, either it was light mapping, or it is now per pixel lighting, which doesn't use the traditional L part.

The interesting gl calls being glMatrixMode, glMultMatrix, glLoadMatrix, glLoadIdentity. glTranslate and glRotate being less usefull.

(In animation systems you build matrices from quaternions and such, so rotate and translate are useless.)

Who here know how many games provide the API with FINAL vertex coords and so use an Identity ModelView ?

 

[Humus]

I wouldn't call glRotate and glTranslate useless. It's commonly used to init the modelview matrix from position and euler angles.

 

[Rodéric]

I wouldn't call glRotate and glTranslate useless. It's commonly used to init the modelview matrix from position and euler angles.

Indeed.
I didn't meant that they were ALWAYS useless ^^

I was just trying to say that the 'Hardware Transform' capabilities, are about transforming vertices by modelview, more than anything else.

Pre T&L era seems very old, like dinosaurs... and T&L seems very old already ^^ New era is programmable hardware through High Level Shader Language

 

[archie4oz]

New era is programmable hardware through High Level Shader Language

Actually if you've been around a while and subscribe the the Sutherland wheel of reincarnation, then this too is pretty old skool... (anybody program TIGA boards or do Interactive Renderman on an i860?)

 

[Simon F]

New era is programmable hardware through High Level Shader Language

Actually if you've been around a while and subscribe the the Sutherland wheel of reincarnation, then this too is pretty old skool... (anybody program TIGA boards or do Interactive Renderman on an i860?)

Indeed - there was a presentation on this at Graphics Hardware and it was mentioned at Siggraph this year. Apparently even the very first documented frame buffer (Kajiya, Sutherland, and Cheadle: 1975) had some programability, and later systems like IKONAS and Pixar's CHAP system, were completely programmable. It was later that things swung around to faster but more rigid dedicated HW with, eg, SGI.

 

[Rodéric]

Thanks for the history lesson guys.