Archived

This topic is now archived and is closed to further replies.

OpenGL T&L

This topic is 5513 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone, I am wondering how are T&L done in OpenGL rendering pipeline especially on gfx cards with GPU. In DirectX you can choose between software T&L (done by CPU) and hardware T&L (entirely done by GPU). Now I would like to know how it is done in OGL. Probably it is driver dependant but maybe it''s not so obvious. The only way how to utilize the advantage of HW T&L in OGL is to write your own vertex program or am I totaly wrong and there''s another way? I am working on advanced 3D engine and want the ability to choose between SW and HW T&L but I am not sure about standard OGL rendering pipeline and how it is implemented.

Share this post


Link to post
Share on other sites
Are you sure? Does it mean that on Geforce there are all transformations and lighting calculations always done by hardware? Maybe you should test it first. On my system it seems like there is a difference between standard OGL T&L pipeline and my own written as vertex program. Maybe it is driver dependent though.

Share this post


Link to post
Share on other sites
quote:

Does it mean that on Geforce there are all transformations and lighting calculations always done by hardware?


Yes. As long as you stay in the limits of the hardware (eg. not enable more lights than the HW can handle).

quote:

On my system it seems like there is a difference between standard OGL T&L pipeline and my own written as vertex program


I guess you haven''t reprogrammed the whole fixed function pipeline, because that would be quite a big vertex program (there is an nvidia paper showing a full fixed function equivalent VP, it''s pretty huge). Shorter VP will of course lead to better performance, but at the cost of less functionality.

Share this post


Link to post
Share on other sites
Of course a minimal vertex program will be faster - it''s more simple since you''re bypassing a lot of the OpenGL calculation.

T&L is automatically done in hardware for OpenGL. The only things to watch out for are redundant copies of data for Vertex Arrays (try using various extensions like fence, var, compiled vertex arrays) and not using vertex arrays at all (like using glVertex3f...ick).


Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

Share this post


Link to post
Share on other sites
T&L is used automatically when transforming vertices. Matrix * Matrix multiplication is done on the CPU, only Vector * Matrix muls are done via T&L using the standard pipeline.

------------
- outRider -

Share this post


Link to post
Share on other sites
Ok, thank you guys for your replys. From what you have written I understand that all T&L in OGL is done by GPU if possible and it is still better to reprogram a standard pipeline by your own vertex program due to faster code unless you really need all the functionality of a standard pipeline. Probably I should test this teory first under specific conditions and see which variant is better for me. Thanks again.


[edited by - QWERTY on November 7, 2002 3:40:30 PM]

Share this post


Link to post
Share on other sites
Keep in mind that by writing your own vertex program, you''ll limit yourself to new generation 3D hardware, and your program won''t work on older hardware anymore (eg. GeForce2 or less).

Share this post


Link to post
Share on other sites
Aren''t vertex shaders emulated on the CPU for Geforce 1/2 cards? True it defeats the whole point, but it''d still be runnable, unlike if you start crowbaring in pixel shaders...

Share this post


Link to post
Share on other sites
I see no problem here Yann L. At startup I will check whether vertex programs are supported or not and based on the result I will use standard or my own geometry pipeline. Of course, I have to test if this approach is suitable and will increase the performance.

Share this post


Link to post
Share on other sites
You could do that. Just one problem: Even a GF2 (or similar) will happily report that it has vertex programs. It will not tell you, that those are software emulated and very slow. Either ask the user (or config file), or do some performance test timing, before just assuming a certain method.

Share this post


Link to post
Share on other sites
Thanks for your suggestion. I will do a performance test that will decide based on the result which method to use. BTW I didn''t know that vertex programs are emulated on GF2. Why it is so? AFAIK this card supports it in hardware.

Share this post


Link to post
Share on other sites
i think with GL_ARB_vertex_program you can check if it fits into your needs (native).. if nvidia is clever they return always false on the gf2.. so you _could_ detect hw..

dunno what they actually do..

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
Yeah, it should work using the GL_MAX_PROGRAM_NATIVE_* queries. I have no idea what they return on the GF2, theoretically 0. But I have no card right here that doesn''t support HW VPs, so I can''t test it.

BTW: nVidia''s 1.4 drivers are not beta anymore. Hmm, their Linux drivers are still 1.3, I don''t like that. At least, they now have NT 1.4 drivers.

Share this post


Link to post
Share on other sites
I think I missed something. What does those NATIVE vertex programs mean and what is the difference between native and non native? Are native vp executed directly by GPU and non native emulated by CPU or am I totaly wrong here? Any help would be appreciated.

Share this post


Link to post
Share on other sites
You could see it like that, yes. Actually the ARB_vertex_program extension defines a mechanism to query different resource limits of a VP execution environment, as supported by the current implementation. Note that this only refers to a 'higher performance environment' and not explicitely to a hardware implementation. So it is upon the manufacturer to return something useful. Most manufacturers will probably return the resource limits of the hardware, as that would be the most useful interpretation of that feature. But there is no guarantee that this is the case.

From the ARB_vertex_program specs:
Native resource counts will reflect the results of implementation-dependent scheduling and optimization algorithms applied by the GL.
If <pname> is PROGRAM_UNDER_NATIVE_LIMITS_ARB, GetProgramivARB returns 0 if the native resource consumption of the program currently bound to <target> exceeds the number of available resources for any resource type, and 1 otherwise.


Note that this will only work on ARB_vertex_program (OpenGL 1.4 compliant drivers for nVidia cards). NV_vertex_program does not support this feature.

/ Yann

[edited by - Yann L on November 10, 2002 7:05:54 PM]

Share this post


Link to post
Share on other sites