Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59:
Felix K�hling wrote:
Hi,
I'm trying to get projective textures working on hardware that doesn't support homogenous texture coordinates with the new vertex setup code (t_vertex.[ch]). The problem with this is that the W coordinate of the hardware vertex must be computed from two vertex attributes, which is why the new vertex setup code can't generated it directly.
The solution I'm proposing emits homogenous texture coordinates and then calls a vertex post-processing hook in the driver that can compute W and 2D tex coords suitable for my crippled hardware from homogenous tex coords.
I'm attaching two patches. The first one implements the driver-independent functionality for hooking up a post-processing function. The second one demonstrates the changes to the Savage driver to support projective texturing using the post-processing hook.
I'd appreciate feedback (Keith?) if this is good for CVS or if there are other/better ideas for solving the same problem.
It's a hack, of course, but hardware like this really makes it difficult to keep things nice. There are quite a few drivers that are stuck waiting for a solution to this issue.
One question is what happens with the 'rastersetup-to-dma' fast render stages for unclipped primitives? It looks like in this approach you emit vertices from t_vb.c which are 1 dword larger than hardware expects and then fix things up afterwards, right? So you'd want to make sure you weren't doing that into a dma buffer...
True. But the savage driver doesn't do that (yet).
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. ;-)
Also, the above point about two different vertex sizes isn't really clear in the code & could use some explanation.
In balance, I think I prefer a slightly different solution to the problem:
1) Make sure rastersetup-to-dma isn't used with these types of vertices.
If I understand you correctly you're referring to what radeon_swtcl.c does in the radeon driver. AFAIK Savage and MGA are affected by this projective texture hack (maybe also r128). And neither have this kind of fast path (ATM). If there was a fast path then one would have to make sure to fall back to the _tnl_render_stage if one needs to fake homogenous texture coordinates.
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.
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
