I'm using GF boards and static data with VAR extension and i'm trying to get the best performances with parallelisation in mind.
When i say parallelisation, i don't think to multi-threading or such things, i just want to order things suitable for the best CPU vs GPU efficiency!
So in other words:
I'm displaying my scene with one frame delay, then pre-ordered primitives (MIPMAP_LEVEL->MATERIAL_IDS->LIGHT_IDS)
are ready for drawing and with static data and VAR everything is located onboard and should be cool for the GPU to work alone with its own memory).
After this filling sequence CPU shouldn't deal again with OpenGL or maybe with little states changes like Fog &| Ambient and so on.. (is this a problem? could it broke the // process?)
But anyway, the most important job for the CPU after this is:
to insert primitives in the OrderingTable for the next frame (game display).
game management (entities behavior and so on)
So what i'm trying to do?
My goal is to make the GPU & CPU work independently on their own side.
As an example, the more CPU time u use before sending primitives to draw your scene, the less GPU time you'll get
to draw it until the end of the frame/vertical retrace period (please don't tell me to work with vsync off, thx)
just bcoz GPU will start its work after a bunch of burned cycles by the CPU!! )
note: Unfortunately i'm unable to test this on GF coz i'm working on a TnT2 at the moment and displaying primitives with this kind of implementation is sequential and wait until drawing is complete!
Thus it doesn't change anything to send from the begining of the frame or when CPU has finished its others tasks.
what do you think of the technique? Is this the best method for GPU efficiency?
Moreover, i've noticed strange results with & without ordered primitives using LIGHTS_IDS for final sort method.
Well, it looks that undordered prims (per light) is faster using GPU for lighting while nicely ordered prims is a faster method using others FPU/SIMD GL implementations...
[This message has been edited by Ozzy (edited 05-04-2002).]