[RV370 X300] "unable to allocate texture" running celestia

Created an attachment (id=20595)
Xorg.0.log - original report

Forwarding this bug from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/257419

[Problem]
In several 3D apps, the rendering is incorrect, X becomes sluggish, and the following error message is printed to Xorg.0.log:

[driAllocateTexture:636] unable to allocate texture
[driAllocateTexture:636] unable to allocate texture

The issue occurs with both XAA and EXA.

[Original Report]
1) Intrepid - 8.10
2) celestia: 1.5.1+dfsg1-1
    xserver-xorg-video-ati: 1:6.9.0+git20080802.1f3eee36-1ubuntu1
3) To see the earth
4) I just saw its outline

I saw the following error messages in a terminal until I exited the program:

[driAllocateTexture:636] unable to allocate texture
[driAllocateTexture:636] unable to allocate texture

A couple of times X has become unresponsive and I had to ssh in to kill celestia.

I've included a screencast of the behavior in case that is any help.
http://launchpadlibrarian.net/16732015/celestia-driAllocateTexture.ogg

[Second Report]
I'm seeing the exact same error message repeated while trying to run xbmc on Intrepid. The mouse pointer is also very laggy and the framerate is near zero. I have a Radeon Mobility 9000 (RV250). I just tried switching to EXA from XAA, and the problem remains. I've attached my Xorg.0.log. Is it possible that all of the people seeing this bug are ATI users? I'm running "Version: 1:6.9.0+git20081003.f9826a56-0ubuntu2" of xserver-xorg-video-ati.

Created an attachment (id=20596)
Xorg.0.log - second report

Created an attachment (id=20609)
Xorg.0.log from 9100 IGP

Another report: I have an ASUS M6R laptop (see http://www.fi.muni.cz/~kas/m6r/ for HW details), ATI Radeon Mobility 9100 IGP (see attached Xorg.0.log), and the problem appeared after today's upgrade from Fedora 9 to Fedora 10 in an "In the Groove" game which I run under Wine, and which used to work in F9. The game is very slow with CPU at 100 %, and the "unable to allocate texture" messages are printed to stdout of wine.

Versions of software:
does not work:
xorg-x11-server-Xorg-1.5.3-5.fc10
xorg-x11-drv-ati-6.9.0-54.fc10
works:
xorg-x11-server-Xorg-1.5.2-3.fc9
xorg-x11-drv-ati-6.8.0git1-15.fc9

A short update to the comment #2:

downgrading only the xorg-x11-server-Xorg package to 1.5.2-3.fc9 (and the xorg-x11-drv-evdev which had an explicit dependency on the 1.5.3 X server,
but _not_ the xorg-x11-drv-ati package) fixes the problem. So most probably the problem is in the core xorg-x11-server-Xorg package between the 1.5.2 and 1.5.3 version.

The texture memory areas are probably just too small for the failing apps:

(II) RADEON(0): Will use 2176 kb for textures at offset 0x01b98000

(II) RADEON(0): Will use 6464 kb for textures at offset 0x0135e000

(II) RADEON(0): Will use 960 kb for textures at offset 0x01e08000

With the IGP, you may be able to increase the amount of video RAM in the BIOS setup. For the other cards, you can try reducing the depth or maximum desktop size or play with Option "FBTexPercent".

Re: comment #4:
I have 32 MB of video memory set in BIOS, and it worked without a problem
in previous releases. I have tried to add FBTexPercent 40, but I have still got many "unable to allocate texture" errors with 1.5.3 X server and 6.9.0 ATI driver.

Re: comment #3:
I was only partly right: downgrading _both_ the core xorg-x11-server-Xorg package _and_ the xorg-x11-drv-ati driver fixes the problem fully.

Downgrading the X server only but not the driver makes the "unable to allocate texture" messages disappear, but the game is _sometimes_ sluggish. If I understand it correctly, it slows down when the new screen background or some other "new" texture is firstly used after some time. So probably even this has something to do with allocating textures inside the ATI driver.

(In reply to comment #5)
> I have tried to add FBTexPercent 40, but I have still got many "unable to
> allocate texture" errors with 1.5.3 X server and 6.9.0 ATI driver.

The default value is 50, so that makes the amount of texture memory available even smaller...

As for old vs. new versions of the server and driver, please attach a log file from a working and non-working case each.

Created an attachment (id=20739)
Xorg.0.log from 1.5.2 (9100 IGP)

Created an attachment (id=20740)
Xorg.0.log from 1.5.3 (9100 IGP)

Here you are: 1.5.2 is the working case, 1.5.3 is the non-working one.

(In reply to comment #8)
>
> Here you are: 1.5.2 is the working case, 1.5.3 is the non-working one.

As you can see from comparing the log files:

* It's not the same version of the driver: E.g. only the 1.5.3 log contains the lines about Max desktop size vs. the Virtual directive. The driver from the working case may reserve a smaller maximum desktop size by default, leaving more video RAM for textures. If you don't need the additional space for resizing or rotating the virtual screen resolution, use the Virtual directive to limit the maximum desktop size.
* 1.5.2 uses XAA whereas 1.5.3 uses EXA. This can again have an impact on the amount of video RAM available for textures.

The net result is

(II) RADEON(0): Will use 8704 kb for textures at offset 0x1770000

in the working case but only

(II) RADEON(0): Will use 960 kb for textures at offset 0x01e08000

in the non-working case.

OK, limiting the Virtual resolution manually fixes the problem for me.
However: with the 1.5.3 server, it stops working after the suspend-to-disk/resume cycle. It used to work even after resume.

(In reply to comment #10)
> OK, limiting the Virtual resolution manually fixes the problem for me.
> However: with the 1.5.3 server, it stops working after the
> suspend-to-disk/resume cycle. It used to work even after resume.
>

Does work how? texture problem? X locks up?

Sorry for not being specific enough. After suspend-to-disk and resume when I start the ITG game (which worked normally first time), it acts as if it was not 3D-accelerated at all (i.e. _very_ slow, probably 1 fps).

your kernel may need this patch:
http://cgit.freedesktop.org/mesa/drm/commit/?id=6905c7a29d2a3bc0e605a09b98ac02a4a50893d0

This patch is apparently already included in 2.6.28-rc8 kernel, which is what I am currently running :-(

(In reply to comment #12)
> After suspend-to-disk and resume when I start the ITG game (which worked
> normally first time), it acts as if it was not 3D-accelerated at all (i.e.
> _very_ slow, probably 1 fps).

Do the 'unable to allocate texture' messages appear again then? If not, it's probably a separate issue.

I have the same issue with xscreensaver's GLSlideshow screensaver.

When I set the value of "Always show at least this much of the image" option between 75% and 100%, I get the error message when the screensaver starts and I don't see the pictures. When I change the setting to somewhere between 50% to 75% the issue disappears.

I am using Xubuntu Jaunty 9.04.

Hi, may I ask if you're still experiencing the problem? Because I do and it's really painful (even 2d performance is quite slow in some cases, dri is enabled). Now gentoo closed support for proprietary ati-drivers - fglrx. Opensource driver radeon does not work as should - I'm still getting "[driAllocateTexture:635] unable to allocate texture" when trying playing 3d games. There are also other minor gpu related issues. Is it ok that even that Ati M 9600 is quite old card there are still such issues?
Do I have to open new bug?

> even 2d performance is quite slow in some cases, dri is enabled).

Ok, it's not that painful :-)
I resolved the 2d slow performance...removed the EXA option (which is recommended btw). With XAA the 2d performance is fast like a charm.
Even though I would like to resolve this problem and get the state as with fglrx (which wasn't perfect either in some cases).

Closing as these problems should be vastly mitigated under DRI2. If not, open new bugs.