Hi Keith,
I'm attaching my current solution for the Savage driver. I'm going to commit this later today. It doesn't need any modifications of the common TNL code. It is probably not the most efficient solution though, since it requires an indirect function call for each emitted vertex. That said, I havn't noticed any performance regressions which may be because the Savage hardware is quite slow in relation to my CPU (mobile Athlon XP 2000+).
Also see my comments below ...
Am Sa, den 18.12.2004 schrieb Keith Whitwell um 0:37:
Felix Kühling wrote:
Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59:
[snip]
Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right?
Right. But that would have been broken with t_dd_vbtmp.h too. ;-)
No, t_dd_vbtmp.h *does* undo the projection, look around line 534.
Ok, sorry. I missed that detail. Though I do have a question about this code:
rqdst = 1.0 / qdst; dst->v.u0 *= rqdst; dst->v.v0 *= rqdst; dst->v.w *= rqdst;
Shouldn't the last line say:
dst->v.w *= qdst;
I don't claim to understand the math behind this completely, but that would be the analogue thing to the code around line 277.
[ ... your other reply ... ]
I can think of the i810 and mga which both have this projective texture issue *and* have the fast path (in i810render.c and mga_render.c respectively). It (used to be?) a worthwhile optimization.
I didn't know about the i810 driver. But in the MGA driver the render stage is disabled. AFAICT it has been since the transition to Mesa 4. Anyway, my solution is very driver-specific. Whoever is going to port this to i810 will have to deal with the fallback case to the _tnl_render_stage.
I'd like to implement a render stage for the Savage driver at some point. This way we could reduce the number of vertices emitted to the hardware by using triangle strips and fans where appropriate. It would also minimize the impact of indirect function calls per vertex.
Hi Felix,
Your patch looks good to me. If you're looking for ways to avoid the indirect function call, probably the way to do it is to somehow try and get onto the DO_FALLBACK path. This is difficult for PTEX vertices as there is no GL state to say 'OK, I'm going to do PTEX vertices now', it is just based on what comes down the pipe, and we don't have a very good set of triggers for that.
But, if you could find a way to detect that you were expecting PTEX vertices, then the i915 driver (intel_tris.c, intel_atten_point()) might be a model for how to do this.
Keith
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
