On Sam, 2002-11-09 at 13:29, Manuel Bilderbeek wrote: > Setting up xserver-xfree86-dri-trunk (2002.11.06-1) ... > Argument "180=" isn't numeric in numeric lt (<) at > /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 25. Hmm, might be caused by some cruft left over in the postinst. Cleaning that up for the next version. > But, huge problems when trying to run 3D apps. Simple stuff like glgears > works fine, but e.g. Tuxracer and Armagetron are extremely slow and this > appears on the terminal: > goemon:~> armagetron > radeonUploadTexImages: upload texture failure on both local and AGP > texture heaps, sz=350208 > radeonUploadTexImages: upload texture failure on both local and AGP > texture heaps, sz=175104 > and many more of similar lines. > Hardware acceleration is enabled, though. > > I downgraded the xserver-xfree86-dri-trunk package, which solved the > problem. Ah, this might be related to the integration of RandR support. There's a buglet which causes the server to use insane virtual resolutions, leaving no space for textures. A workaround is to explicitly set the virtual resolution in the display subsection. I'll look into integrating the fix for the next version. > Most debug messages are gone now (e.g. when dragging the > glxgears window), but the problems with Tuxracer remain. What problems exactly? Note that it is slow in depth 24, and it shows some incorrect rendering unless RADEON_TCL_FORCE_DISABLE=1 is set. [ armagetron ] > >>This problem is completely gone now! The game seems to work just fine! > > > > Really? I need to set RADEON_NO_VTXFMT=1 for the textures to be > > rendered correctly. > > It reallly works. The problem may not be obvious if you don't have the skies enabled, but you should notice the floor texture changing when you go to the menu with Esc. > >>????????? > >>I just logged in and the problem is back! And it's *massive*!! It's far > >>worse than I've ever seen. Any change on the screen produces this > >>interference now....! :-( I don't understand it at all... How could it > >>have been solved for that particular time? > > > > Weird. > > Definately. It seems to be a driver problem though, not a cable problem, > since I once had it working... (That was, adding the option, logging > out, restarting X with CTRL ALT BS and then logging in again...) Not so sure, I'd expect a driver problem to be 100% reproducible. > > James Ralston posted it to Xpert on July 21st under the subject 'adding > > radeon driver documentation'. > > I can't seem to decode his attachment... Please e-mail that draft to me, > if you have it... Thanks in advance. Attached. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Attachment:
radeon.4x.gz
Description: GNU Zip compressed data