I have been working on an OpenGL game for Ubuntu. Upgrading from 8.04 to 8.10 caused a major glitch in rendering. I have narrowed it down to the Mesa 3D drivers. The textures are loaded into OpenGL correctly, as the game runs normally (IE, it looks normal) for about 3 to 4 seconds before all of the textures become corrupt looking. This happens even if nothing happens in the game, other than letting it run for that long. It does NOT happen on any computer I've tested it on that does not use the Mesa drivers (it works fine on nVidia and ATI drivers) and it works fine on whatever version Ubuntu 8.04 had. It also works fine on 6.5.3 software drivers, as I manually installed them to test it (I was unable to compile the linux-dri version, so I only tested the software rendering one, even though the laptop I was using could (I believe) use the linux-dri version). It DOES happen with version 7.2, which I downloaded from the site and installed manually, in addition to whatever version comes with Ubuntu 8.10. I tried, unsuccessfully, to narrow down the problem. Here is the thread on Ubuntu forums: http://ubuntuforums.org/showthread.php?t=978335 Here is the rendering code for the game: http://code.google.com/p/odysi/source/browse/trunk/src/common/renderSystem.cpp The whole game can be downloaded/compiled from that site, though you would need the latest boost, CEGUI, and SQLite to compile it (sh autogen.sh; ./configure; make; make install; -- run odysi_mapeditor). I realize this may be a bug in my game and not a bug in the Mesa drivers, however I find it odd that it works fine on every system I have tested it on that does not use the Mesa drivers. I can provide more information about two systems it does not work on (both integrated graphics using the Mesa drivers) and three systems it does work on (two nVidia, one ATI) if needed.
Created attachment 20266 [details] Corrupt graphics This is a picture of how the game looks once the graphics become corrupt. The "normal" look can be found at http://code.google.com/p/odysi
We need to know at least the Mesa driver(s) used in the affected setup(s). Something like glxinfo | grep render should give this information.
(In reply to comment #2) > We need to know at least the Mesa driver(s) used in the affected setup(s). > Something like > > glxinfo | grep render > > should give this information. > The output that didn't have any version info, so here's that and some other things I thought might help: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 client glx vendor string: SGI client glx version string: 1.4 GLX version: 1.2 OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.2 OpenGL shading language version string: 1.10
So does it only happen with the software rasterizer, not with a hardware accelerated driver?
(In reply to comment #4) > So does it only happen with the software rasterizer, not with a hardware > accelerated driver? > I'm 95% sure it happens with both, but I installed 6.5.3 (which does not have the problem, by the way) on the only machine I have that has the hardware acceleration ability. I'll try to reinstall 7.2 and make sure this weekend.
(In reply to comment #5) > I'm 95% sure it happens with both, but I installed 6.5.3 (which does not have > the problem, by the way) on the only machine I have that has the hardware > acceleration ability. I'll try to reinstall 7.2 and make sure this weekend. > I'm having a hard time getting 7.2 linux-dri installed on my laptop (or, perhaps, getting 6.5.3 uninstalled). So I cannot test it with that right now. Is there any other information I can provide?
Ten year old bug, closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.