Brian Paul wrote:
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.
I've just seen there are some fixes very recently in the drm module for the cubic offsets which I've missed before (as I don't update the drm module every time I'll compile the 3d driver). Unfortunately, these fixes seem to effectively prevent ANY app which use any texturing to work at all... (drmCommandWrite: -22).
Who checked in those changes?
Could someone please fix this bug of epic dimensions ;-). This also seemed to cause a drop in glxgears performance (one of the few apps which don't use texturing...) by a factor of 10 or so (but yes, it is using hardware rendering).
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.
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.
Yes, I've always used LIBGL_ALWAYS_INDIRECT. In the end, it should run pretty much the same code as stand-alone mesa, or not?
They should basically be the same.
Though there were some glx fixes too recently (not sure if I had them already), retried it but it still doesn't run correctly.
Tried it with stand-alone Mesa (it's enough to set LD_LIBRARY_PATH to Mesa/lib, yes?) and both fogcoord and seccolor did work correctly. However, stencilwrap now fails instead?
I don't actually have an R200 card to test with right now.
-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
