Am Mittwoch, 14. Januar 2004 02:56 schrieb Roland Scheidegger:
> 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).
> Could someone please fix this bug of epic dimensions ;-).
Use this one:
Re: [Dri-devel] [trunk] r200 current CVS
Datum: Sonntag - 20:58:26
> 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).
No, not seen here (r200) without and with Andreas fix.
progs/demos>
progs/demos> 9899 frames in 5.000 seconds = 1979.800 FPS
12200 frames in 5.000 seconds = 2440.000 FPS
12097 frames in 5.000 seconds = 2419.400 FPS
_During_ full X compilation (make -j3 World) ;-)
Linux version 2.6.1-0-smp-DN ([EMAIL PROTECTED]) (gcc-Version 3.3.1 (SuSE
Linux)) #1 SMP Mon Jan 12 21:25:29 CET 2004
Now, I can finally go and test Q3A for smp support, again...
Greetings,
Dieter
> >> 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? 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
