I've just had too much spare time and though it would be interesting to see which mesa demos/tests have problems (lighting or otherwise), so here are the results of all tests which did not run correctly (of course quite a few tests wouldn't run at all due to missing arb_fp, arb_vp or whatever extension, I didn't list them).
cubemap: with hardware tcl inner sphere looks correct, outer cube has only blue face, the others are missing, and texture is more fuzzy (might be just a different lod bias?) compared to software mesa. tcl_mode=0 is even worse: inner sphere everything is only blue/white, outer cube same errors as above.
I believe the problem is that TexCoord3 commands are only getting their S and T coords passed to the hardware. That is, (S,T,R) texcoords aren't a supported vertex format at this time.
I had implemented texture cube maps and 3D textures in the R200 driver over a year ago, but wasn't sure how to go about implementing the TexCoord3 stuff.
fire: way too much fog is applied, the ground gets almost completely white. Happens with both tcl and tcl_mode=0.
isosurf: "Reflect" looks much different with hardware tcl (only in polygon mode fill, polygon mode line causes a tcl fallback and thus it will look the same as software tcl) than with tcl_mode=0 (LIBGL_ALWAYS_INDIRECT looks exactly the same as tcl_mode=0). Can't really say which one is correct though, the overall impression is still the same, it's just as if the colors are somehow reversed...
pointblast: (both with hardware tcl and without) the points are almost invisible. IIRC this was already mentioned some time ago to be because all points are drawn with size 1 only.
stex3d: the 3d texture fallback seems to be very slow. software mesa seems to run about 2-3 times faster than hardware acceleration using the fallback.
Not sure about that, but the TexCoord3 issue would also apply here.
occlude:
GL_HP_occlusion_test is not supported in r200 driver, though I believe the hardware should be able to support it (ATI supports this extension in their driver).
fogcoord:
doesn't work correctly with software mesa, all squares are white (test says should be white -> gray -> black)
GL_EXT_fog_coord is not implemented in r200 driver. Both the XiG and ATI driver support this in their driver, so I guess the hardware should support it too.
It seems OK w/ stand-alone Mesa. When you say software mesa, do you mean LIBGL_ALWAYS_INDIRECT? If so, it might be a client/server-side GLX bug.
projtex:
(both with tcl and tcl_mode=0) the projected texture coordinates are obviously wrong, the size of the projected texture doesn't even seem to depend on where the projection ray hits the object (both projected textures on the cube seem to have the same size).
seccolor:
works with hardware acceleration (with or without software tcl), but not correctly with software mesa (all squares are red).
Same story as for fogcoord.
stencilwrap:
fails all tests (with or without hardware tcl), always getting 0 or 255, software mesa works correctly.
yuvrect:
texture has pink tint (both with or without tcl), works ok with software mesa.
yuvsqure:
same problem as with yuvrect (only the left texture, the right one is correct).
Quite a few things to fix :-(
(cvs version from sometime 1-2 days ago, with Michel's latest lighting fix applied).
Roland
-Brian
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
