is this good or bad?
Author
what about using ProcessVertices() to transform everything on the scene, and then render all the passes needed with the same results from ProcessVertices. wouldn''t that be faster than re-rendering everything for multiple passes? i imagine it''d be slower if there are 2, maybe 3 or less passes though.
Often each pass has another light so it won''t work then. It would work for terrain splatting or other multipass texturing tricks, but I dunno if ProcessVertices is much slower.
The most important thing to remember about ProcessVertices is it will *ALWAYS* be performed by the CPU so will never take advantage of any hardware vertex processing (H/W T&L) on the graphics chip (which should be thought of as "write only" devices in most cases).
Whether ProcessVertices() to transform and light (perhaps with a vertex shader) then multiple Draw*Primitive() calls from the transformed ProcessVertices result will be faster than multiple calls to Draw*Primitive() with untransformed data is pretty much application AND hardware dependent.
If your app is running on a machine with a non-T&L device (e.g. TNT, G400 etc, basically anything before a GeForce 256*), then using ProcessVertices in this way for multi-pass will ALWAYS be a good thing.
On a machine with hardware shader support (or just hardware T&L if your app uses fixed function vertex processing), whether it''s a win is something you should profile - and will be dependent on things such as:
- how complex your vertex shader is (more complex = more CPU cycles inside ProcessVertices)
- whether you have a lot of static vertex buffers (buffers for ProcessVertices should always be in system memory, the optimal place for static vertex data is in video or AGP memory which implies a lot of copying across the AGP bus which may be avoided with the multiple passes).
- the speed of the hardware T&L versus the speed of the software processing on the CPU.
- the amount of other demands there are for the CPU (anything which forces even a partial serialisation between CPU and GPU and burns lots of CPU cycles isn''t good *IF* you have lots of other work such as physics which needs doing on the CPU).
[*consumer level - 3DLabs had T&L parts out before nVidia, but they were aimed at the professional artist market]
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Whether ProcessVertices() to transform and light (perhaps with a vertex shader) then multiple Draw*Primitive() calls from the transformed ProcessVertices result will be faster than multiple calls to Draw*Primitive() with untransformed data is pretty much application AND hardware dependent.
If your app is running on a machine with a non-T&L device (e.g. TNT, G400 etc, basically anything before a GeForce 256*), then using ProcessVertices in this way for multi-pass will ALWAYS be a good thing.
On a machine with hardware shader support (or just hardware T&L if your app uses fixed function vertex processing), whether it''s a win is something you should profile - and will be dependent on things such as:
- how complex your vertex shader is (more complex = more CPU cycles inside ProcessVertices)
- whether you have a lot of static vertex buffers (buffers for ProcessVertices should always be in system memory, the optimal place for static vertex data is in video or AGP memory which implies a lot of copying across the AGP bus which may be avoided with the multiple passes).
- the speed of the hardware T&L versus the speed of the software processing on the CPU.
- the amount of other demands there are for the CPU (anything which forces even a partial serialisation between CPU and GPU and burns lots of CPU cycles isn''t good *IF* you have lots of other work such as physics which needs doing on the CPU).
[*consumer level - 3DLabs had T&L parts out before nVidia, but they were aimed at the professional artist market]
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
