Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Issues with ATI V3200

JauJau Jeegoo
Registered User
Join date: 21 Nov 2006
Posts: 4
12-03-2006 10:22
I've been playing with SL under Linux for a couple of weeks now, and I have a problem that just won't go away. I've tried a large number of driver and option combinations including a much older one and a much newer one. Currently I've settled on 2.6.18-1.2849.fc6 with fglrx xorg-x11-drv-fglrx-8.29.6-1.lvn6, because the suspend to RAM functionality works and the newer ones don't.

The issue is this. Upon logging on, the client is OK for a coupel of seconds, then it gets _really_ slow, and spits out
fglX11AllocateManagedSurface: __FGLTexMgrAllocMem failed!!
over an dover again. What happens next is the really weird part. Under some circumstances it gets better almost right away, but it will go bad once I visit something with lots of polygons (or textures?).
Usually, after about 5 minutes of a stuttering client, the problem goes away completely and never comes back until I restart or reinit the display (e.g. switch to fullscreen).

I don't think this is the shared mem permission problem for the following reasons:
1) There's not problems with permissions of /dev/shm by ls -l
2) The client can create its file in there just fine
3) No other xclient shows the same problem
4) It shouldn't get better after a while if it were.

I had thought that the 1.13 version fixed this, but I think the test grid wasn't busy enough to show the problem. I suspected a hardware problem, since I was having artifacts in windows, but a driver upgrade fixed that issue. I've put on a few hours in windows without problems.

Other things I noticed. If I turn on FSAA it seems to never get better. It seems to get faster if the window is small. This is a bit annoying since recently resizing the window from small to large gives sig11. At one point I did an strace on the binary when it was emitting thos messages and saw this:

ioctl(16, 0x4008642b, 0xbfdd66b0) = 0
ioctl(16, 0x4008642a, 0xbfdd65e8) = 0
ioctl(16, 0xc0146440, 0xbfdd6530) = -1 ENOMEM (Cannot allocate memory)
ioctl(16, 0xc0146440, 0xbfdd6530) = -1 ENOMEM (Cannot allocate memory)

0xc0146440 looks to me like it corresponds to the DRM_RADEON_CP_INIT ioctl.

I don't know if y'all are trying to run some special ATI texture command directly or if it's from within ATI's hacked up opengl driver.

Other info:
It's an IBM t43p with a 2GHZ P4 M with 1GB of RAM.
Distro is fedora core 6, but I also tried briefly under Ubuntu Dapper with an older kernel/ fglrx driver- same results.
I tried disabling all of the opengl extensions and tried with and without
"KernelModuleParm" "locked-userpages=0"
(many times fwiw :) )
None of these driver tweaks seem to have any effect.
JauJau Jeegoo
Registered User
Join date: 21 Nov 2006
Posts: 4
Fixed?
12-22-2006 05:28
This problem went away, but came back after an upgrade.

I haven't test it thoroughly, but it looks like the problem goes away with the following diff on the shell script script:

18c18
< export LL_GL_BASICEXT=x
---
> #export LL_GL_BASICEXT=x
31,32c31
< #export LL_GL_BLACKLIST=abcdefghijklmno
<
---
> export LL_GL_BLACKLIST=

So basically, the problem seems to happen when
LL_GL_BASICEXT=x
is set. I don't know if
LL_GL_BLACKLIST=
does anything interesting.