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. > 2) Emit vertices with a seperate 'q' coordinate, as if the hardware > supported projective-textured vertives. That's what I'm doing already. > 3) Create point, line, triangle functions which translate from idealized > to hardware vertices and make sure that they get used for all primitives. Ok. This seems to be the only real difference to my approach. Also this way no changes to the generic TNL-code would be needed at all. Actually that's not such a bad idea after all. > > This probably works out slightly slower but is going to be much easier > to make work correctly, and there is a much better chance of getting a > correct result. > > Keith > Thanks for the feedback. Let's see if I can come up with an elegant hack along these lines. -- | Felix K�hling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | ------------------------------------------------------- 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
