On Sun, 2003-07-27 at 05:16, Keith Whitwell wrote: > Bertrand Lamy wrote: > > > > I have found 3 bugs in the DRI driver. See the attached file for description. Each > > program is the 'minimal' code to get the bug. > > I also give my computer configuration. > > > > I am quite sure that the bugs lie in the driver cause: > > - it does not bug when using mesa and no 3D card (program launched with noglx) > > - it does not bug on others computers: one with a nvidia card, one with another > > ATI radeon > > > > PS: I have joined a shot of the bug obtained with the program test_gl3.c > > I've fixed this one (test_gl3.c) & am working on the others.
Keith, while you're debugging the Radeon drivers... :) I just did a little testing roundup with the r200 driver: The good news is that the lighting looks much better in bzflag now, although there's still a little oddity: when you turn around, the brightness of all the walls changes abruptly at some points. Another improvement is quakeforge, which looks perfect now (console was broken before). Also, armagetron, chromium, criticalmass, egoboo, empty-space, evas_test, glaxium, pinball (emilia), quake2, most of the rss-glx hacks, soulride and stellarium work fine as before. Unfortunately, these changes broke lighting for billard-gl, foobillard, fsv, gltron and some of the rss-glx hacks; some parts of these look too dark now. Another regression is that some things are invisible in amoeba (some textures) and crack-attack (pretty much everything involved in the actual game :). Other visibility problems were already there before in csmash (the menu text, R200_NO_VTXFMT works around it) and trackballs (you don't see much except the fog in some levels). Yet another regression is a hang in celestia (about a minute into the demo), space-orbit (on startup) and tuxkart (when starting a game). They don't block the X server and can be killed without problems though. Also, there's still the long standing 'some vertices intermittently have random colors with many lights' problem in bzflag and lightlab (seems to depend on the light direction) (and NWN, etc., but I can't test those...); this seems to be fixed or at least improved in noegnud though. (Note that it used to occur in billard-gl as well, maybe the lighting regression hides this in some apps) Another problem that was already there before is that the spheremap on the balls in foobillard and the environment map on the ice in tuxracer are broken. R200_NO_TCL works around all of these problems, unless stated otherwise. It seems to have no influence on the last problems I observed though: the lighting is broken on Tux in tuxracer, he looks too bright. Don't know when this was introduced. And there are gaps between adjacent texture parts in amoeba, noegnud and tuxracer at least; while these may be app bugs, the driver used to deal with them more gracefully. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
