I've just seen there are some fixes very recently in the drm module forcubemap: 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.
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).
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).
Yes, I've always used LIBGL_ALWAYS_INDIRECT. In the end, it should runstex3d: 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.
pretty much the same code as stand-alone mesa, or not? 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?
Roland
------------------------------------------------------- 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
