Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote:
>> > - TuxRacer: Tux looks white!
>>
>>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
>
> This is harmless debugging output.
>
>>radeonUploadTexImages: ran into bound texture
>
>>If I play for a longer time, loads of those radeonUploadTexImages
>>messages appear.... A bug?
>
>
> Possibly, does it still occur with the latest packages, which are now
> available from
>
> deb http://people.debian.org/~daenzer/dri-trunk/ ./
>
> ?
First of all, there seems to be a (small?) error in the package:
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.
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. Most debug messages are gone now (e.g. when dragging the
glxgears window), but the problems with Tuxracer remain.
For completeness, this is what i hvae installed now:
goemon:~> dpkg -l | grep trunk
rc drm-trunk-module-2.4.19 10.00.Custom+2002.10.02-1
DRI CVS trunk DRM modules
ii drm-trunk-module-2.4.19-k7 10.00.Custom+2002.11.06-1
DRI CVS trunk DRM modules
ii drm-trunk-module-src 2002.11.06-1
Source for the DRI CVS trunk DRM modules
ii xlibmesa3-dri-trunk 2002.11.06-1
DRI CVS trunk version of Mesa 3D graphics library
ii xserver-xfree86-dri-trunk 2002.10.02-2
The DRI CVS trunk XFree86 X server
>
>>Also, in the syslog:
>>Nov 8 20:06:57 goemon kernel: [drm:radeon_freelist_get] *ERROR*
>>returning NULL!
>
>
> This can happen intermittently without being a problem, or it can bea
> symptom of a lockup.
It's still in the syslog when running Tuxracer.
>>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.
>>?????????
>>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 sure what you wanna know; post to Xpert@XFree86.Org (beware,
> moderated for non-subscribers) describing the problem in detail.
OK.
> 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.
>>I have the AGP Aperture set to 64MB, or doesn't this have to do with
>>AGPSize?
>
>
> It's the upper limit. The radeon driver doesn't do AGP texturing
> currently so it uses 3 MB of AGP memory at most. Anything more is
> basically wasted.
OK. I'll leave it to default then.
>
>>- When X is booted, the screen stays black for quite a long time. My
>>monitor reports that the frequency is only 2Hz or so, and almost goes
>>off. But just before it goes off, my xdm login screen appears. Is there
>>a reason for this long delay?
>
>
> It's probably the driver querying the monitor via DDC.
>
>
>>Can I make it shorter?
>
>
> Option "NoDDC" or "NoVBE" may help.
It doesn't make any difference. With the latter, I get this in the log:
(WW) RADEON(0): Option "NoVBE" is not used
> You can boot into single user mode by passing 'single' as an
argument to
> the kernel.
Ah, *that* was it... THanks!
>>PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
>>PPS: Visit my homepage at http://manuel.msxnet.org/
>
> Funny, my first computer was an MSX, from Canon IIRC. :)
Hehhe! Probably a Canon V-20. MSX is one of my greatest hobbies. :-)
--
Grtjs, Manuel
PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/
Reply to: