Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use t_vertex. It is only a conversion for SW TCL, and it's not quite complete. I've managed to clean up all the crashes that I could find, but I've only tested with gears, geartrain, and tunnel. There are some known problems:
- The textures in tunnel are not quite right. They're sort of zig-zaggy.
- The colors of two of the gears in gears are swapped. The red gear is blue and the blue gear is red. The green gear is correct.
One other thing I forgot to mention. I had to ifdef out the call to r200SetVertexFormat in r200PointsBitmap, so I assume glBitmap is broken for the SW TCL path.
I chopped out all of the _r200_render_stage stuff from r200_swtcl.c. It is unused (due to bad interactions with UT2k3), and was only confusing me. When this patch gets committed, that code can go back in, I think.
There are two hacks that I had to do to get things working. Neither of these needed to be done by the i830 or savage drivers. First, I had to add a "viewport" matrix that remains an identity matrix. This is because the Radeon chips do the viewport transform in hardware. tnl_dd/t_dd_vbtmp.h had the ability to handle hardware like this, but t_vertex apparently does not.
Just specify that element as 'EMIT_4F' or 'EMIT_3F', rather than 'EMIT_4F_VIEWPORT'.
Ah. Okay. I guess that's what I get for relying on cut-and-paste so heavilly. :)
Second, I had to force TNL to always produce project coordinates. Again, the Radeon hardware can do the final projection in hardware almost all the time, but due to the way the i830 and savage drivers use use tnl->vb.NdcPtr (actually VB->NdcPtr) I couldn't see a way around this. I may just be missing something there.
I do have one other question that probably only Keith or Daniel can answer. :) Can t_vertex replace the immediate-mode API code-gen in the radeon and r200 drivers? It seems like it should be able to, but I'm not sure I can see exactly how. Does the HW TCL side just need a tnl_attr_map just like the SW TCL side? I think looking at the SW TCL code for so long has fried my brain...
The immediate-mode codegen pretty much cuts out the tnl module altogether and builds hardware vertices directly. The t_vertex.c code would be redundant in that case. If you just mean using this logic to determine the vertex format, I suppose it's possible, but you'll run into differences between what is needed pre-TCL vs. what is being calculated here for vertices post-TCL.
What I want is to reduce redundant code. :) The assembly stubs for the radeon / r200 codegen is very similar to the t_vertex stubs. The logic for selecting which stubs to use is also very similar. It seems like it should be possible to re-use some of that and cut a bunch of code from those drivers. The added benefit is that stubs / codegen for new processors (i.e., x86-64, PowerPC, etc.) or new instuction set additions (i.e., SSE3, etc.) only needs to be added once.
Here specifically -- if you don't want to do viewport transform in sw, don't tell t_vertex.c to EMIT_xF_VIEWPORT.
Also - I'm not sure why you feel that COLOR1 or FOG (vertex fog, right?) require the W coordinate, though certainly the old code did work that way, this new code will differ from the old code in other respects so why maintain this old limitiation?
There are two things happening here. When I wrote this code I first added this to the existing r200SetVertexFormat. One of my validations was the the fmt_0 & fmt_1 values matched *exactly* what the old code generated. Since the old code worked, that allowed me to eliminate one source of errors.
The other thing is that I tried to keep that code I pulled from the i830 driver as close as possible to the i830. This was done for the same reasons.
It all looks like you're on the right track. I can see you're getting tied up with trying to maintain the idea of a "tiny" vertex format rather than looking at what that really meant & identifying the situations where a W coordinate really is necessary. Specifically, if there's no texture and no pixel fog (which r200 doesn't enable), you can do the perspective divide in software and send a smaller vertex. Otherwise, you'll want to send XYZW anyway, so the hardware might as well do the divide.
I'm going to look at the code you sent out. In any case, adding support for fog_coord would be a good thing. :)
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
