On the advice of Michel D\"anzer of the debian-x mailing list, I'm writing this e-mail. Our e-mails can be reread here:
http://lists.debian.org/debian-x/2002/debian-x-200211/msg00077.html
I'll try to summarize the problems here, now.
Since I was having some problems with the 3D rendering of my Radeon 32MB SDR card, I sent a mail to the debian-x mailing list. These were the problems I described:
The 3D acceleration seems to work fine, but there are minor problems:
- TuxRacer: Tux looks white! Something is wrong with the colors of the Tux character in this game, only the shadows on the poor penguin's body is shown. I have seen it work perfectly on other computers (with some nvidia card). For the rest, it seems to work just fine.
- Armagetron: when more than 3 players are in the game, the 'motor bikes' get partly invisible; something goes wrong with the textures. When leaving the program, I can see lots of these messages from stdout/stderr:
radeonUploadTexImages: ran into bound texture
and in my syslog I get:
Nov 4 20:19:37 goemon kernel: [drm:radeon_freelist_get] *ERROR* returning NULL!
Nov 4 20:20:08 goemon last message repeated 492 times
- Return to Castle Wolfenstein: the program seems to work fine, although the framerate is quite low. However, after a short while things go wrong: bitmaps seem to get corrupted. E.g. the 'health percentage' numbers flicker and when I look at the notebook, it flickers and shows wrong bitmaps and such. Huge corruption. Also in the game menu this occurs and in the game 'world' itself, only the sky flickers sometimes. The fonts in general flicker too, showing wrong bitmaps. In other words: many, many glitches. Also here, I get this in the term I started the game in:
radeonUploadTexImages: ran into bound texture
The upgrade from X 4.1.x to 4.2.1 didn't help at all in this.
So, Michel advised me to install snapshot packages as described here:
http://dri.sourceforge.net/snapshots/README.Debian
Lots of problems were solved, but some remained and a few new ones arose:
TuxRacer:
Hah! Tux looks normal now!
However, still problems with Tuxracer: with the new drivers, the game slows down incredibly about every second. It seems to go smoooth, almost stops then, continues smoothly then, almost stops again, etc.
In my terminal this appears:
radeonUpdatePageFlipping allow 0 current 0
radeon_makeX86Normal3fv/195 CVAL 0 OFFSET 14 VAL 40763f60
radeon_makeX86Normal3fv/196 CVAL 4 OFFSET 20 VAL 40763f64
radeon_makeX86Normal3fv/197 CVAL 8 OFFSET 25 VAL 40763f68
radeon_makeX86Normal3fv done
radeonUploadTexImages: ran into bound texture
radeonUploadTexImages: ran into bound texture
radeonUploadTexImages: ran into bound texture
radeonUploadTexImages: ran into bound texture
radeonUploadTexImages: ran into bound texture
radeonUploadTexImages: ran into bound texture
If I play for a longer time, loads of those radeonUploadTexImages messages appear.... A bug? Also, in the syslog:
Nov 8 20:06:57 goemon kernel: [drm:radeon_freelist_get] *ERROR* returning NULL!
The problems in Return to Castle Wolfenstein were completely gone. Armagetron was rendered correctly when setting RADEON_NO_VTXFMT=1, but was already a lot better than the old drivers.
Then, I installed the latest packages from
deb http://people.debian.org/~daenzer/dri-trunk/ ./
The xserver-xfree86-package I had to downgrade again:
"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."
Michel said:
So, now I am using this: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.
ii drm-trunk-module-2.4.19- 10.00.Custom+2002.11.06- DRI CVS trunk DRM modules
ii xlibmesa3-dri-trunk 2002.11.06-1 DRI CVS trunk version of Mesa 3D graphics library
hi xserver-xfree86-dri-trun 2002.10.02-2 The DRI CVS trunk XFree86 X server
The problems with TuxRacer are now the following:
- Every about 0.4 seconds, the speed goes down dramatically for a short
while (0.2 sec?), after which it continues normally. The first few
seconds work normally though (I tried the Bunny Hill level) and also at
the end things get slightly better.
- Lots of these messages on the screen: radeonUploadTexImages: ran into
bound texture
Note that I started off with a TuxRacer that worked fine, except that Tux's body was white. But with the new drivers, the gameplay is ruined! ;-)
Michel expected me to be low on texture memory, so I grepped my log file:
(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d50000
This he found little. I don't really understand this, since the problem didn't really occur with the old drivers, I *have* 32MB RAM on my card and other programs don't show any problems (including very complicated games like Return to Castle Wolfenstein).
However, since Michel is more of an expert than I am:
How can it be so little while having 32MB of videoRAM?The amount of memory available for textures is the total amount of video RAM minus the amount occupied by the front, back and depth buffers and the pixmap cache. In your case, approximately 32*1024*1024 - 4*1600*1200*4Why do almost all other GL apps work fine, even Return to Castle Wolfenstein and the Quake 3 Arena demo? I guess they need a lot more texture memory.
I agree that they probably use a larger total amount of textures than tuxracer, but they may keep uploading textures and still be playable as long as there's always enough room for all the textures needed to render a single primitive...
This implies that it is a problem of TuxRacer not taking into account my situation as well as the other apps do. The "shocky" behaviour of TuxRacer is then explained:
> ... whereas this may not be true with tuxracer, which might require > falling back to software rendering. > RADEON_DEBUG=fall tuxracer 2>/tmp/tuxracer.fallbacks > should give information about that. I get all kinds of messages like this: VFMT_FALLBACK from radeon_fallback_CallList VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK radeonUploadTexImages: ran into bound texture Radeon begin tcl fallback Rasterization fallback Radeon begin rasterization fallback: 0x1 Texture mode Radeon end tcl fallback Rasterization fallback Radeon end tcl fallback Radeon end rasterization fallback: 0x1 Texture mode VFMT_FALLBACK from radeon_fallback_DrawElements VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK Radeon begin tcl fallback Texgen unit 0 Radeon end tcl fallback Texgen unit 0 Radeon end tcl fallback VFMT_FALLBACK from radeon_fallback_DrawElements VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK VFMT_FALLBACK from radeon_Materialfv Radeon begin tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Radeon begin tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback VFMT_FALLBACK from radeon_fallback_CallList VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK VFMT_FALLBACK_OUTSIDE_BEGIN_END from radeonVtxfmtUnbindContext
Another thing that came up:
So, hereby my report. I hope you're not too much annoyed by the long mail with all the quotes, but I didn't want to leave out information that might possibly be important.By the way, I managed to let X hang a couple of times using 3D apps:1) I ran the molecule3D demo of xscreensaver in the root window, then I moved my 'workspace' clip of WindowMaker to the left and it hung
2) I played CannonSmash, a table tennis simulation game, and in the middle of a game it hung (the X server i.e.).
Hanging X servers are really annoying, by the way... You have to reboot! (Keyboard locked...)
True, and unfortunately it's very hard to avoid all lockups, and investigating them is highly non-trivial and time consuming. It would still be an idea to report these to the dri-devel list so the developers are aware of the problems and can try to track them down when they have time.
My old and new configs and log messages can be found here:
http://manuel.msxnet.org/Xlogconfig2.tar.gz
http://manuel.msxnet.org/Xlogconfig.tar.gz
The former with the new drivers the latter with the original ones.
Thanks in advance for looking at my problems and thanks already for making drivers for my Radeon! ;-) Keep up the good work.
If there's any more information I can give, or tests I can do, please let me know. Also, please Cc: any reply to my address: [EMAIL PROTECTED] Thanks!!
Best regards,
Manuel Bilderbeek
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
