Am Mittwoch, 14. Januar 2004 01:09 schrieb Brian Paul:
> Roland Scheidegger wrote:
> > 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=3D0 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=3D0.
> > 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=3D0
> > (LIBGL_ALWAYS_INDIRECT looks exactly the same as tcl_mode=3D0). 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.
Can you verify the "clipping bug" (with r200) when you move the window to t=
right and below side/corner?
It is still there for months.
> > 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=3D0) 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
@home: <Dieter.Nuetzel () hamburg ! de>