On Sat, Apr 05, 2003 at 07:37:13AM +0100, Keith Whitwell wrote: > José Fonseca wrote: > >For now I'll be also plugging in the C++ classes into into the existent > >T&L code, but in the future I may want to change the way the software > >T&L interfaces with the [hardware] rasterizers, since the current > >interface makes it difficult to reuse vertices when outputing tri- or > >quad-strips, i.e., you keep sending the same vertices over and over > >again, even if they are the same betweeen consecutive triangles. > > Honestly, that's just not true. You can hook these routines out in a bunch > of different ways. > > Look at t_context.h - the tnl_device_driver struct. In here there's two > table sof function pointers 'PrimTabVerts' and 'PrimTabElts' which hand off > whole transformed, clipped primitives - tristrips, quadstrips, polygons, > etc. - to the driver. Hook these functions out and you can send the > vertices to hardware however you like.
I thought the interface exposed by t_dd_tritmp.h was the only kind of interface exposed by TnL. I really have to study the TnL a little more (perhaps doing a quick documentation too). > Also look at tnl_dd/t_dd_dmatmp.h, as used in mga/mgarender.c and elsewhere > -- > this is an even more direct route to hardware and is very useful if you > have a card that understands tristrips, etc. It probably isn't much use > for a mach64, though. Quite the opposite: Mach64's triangle setup engine is designed in such way that allows you to update vertices selectively (i.e., for each vertice in the DMA buffer you specify which of the 3 vertices of the traingle setup engine you're updating) allowing to cope with triangle strips or any kind. So it may be useful at some time to switch to t_dd_dmatmp.h instead of t_dd_tritmp.h on the Mach64 driver. > Clipped triangles are more difficult to handle, we currently call > tnl->Driver.Render.PrimTabElts[GL_POLYGON] for each clipped primitive. If > you can think of a better solution & code it up, I'd be interested to see > it. It would be interesting to see some other approaches, but I think this > one actually ends up not being too bad. For the rasterization I was also considering using a two stage producer-consumer scheme: A->B->C. The producer A is chosen according the vertex format, while C is always the same and only emits the vertice(s) received to the hardware. Vertices don't necessarily have to be copied across the stages and a reference can be used whenever needed. For dealing with clipped vertices when passing them to B there would be a clipped flag associated with every vertex and they would all follow some ordering convention. B could be implemented to just call the Polygon version of B, or being smarter and reuse some of the vertices already downstream. José Fonseca ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
