[Xpress 200M] compiz crashed with SIGSEGV in pthread_mutex_lock() due to compiz loading on rez > texture size

When I boot into Natty with Ubuntu Classic desktop, compiz windows decorator is either not loaded or has crashed quietly. No windows decorator is available.

Running "metacity --replace" restores the windows decoration and allows me to use the system.

When I try to run compiz with "compiz --replace &", the whole system get corrupted visually even though the system is still functioning and responding. The extent of functionality cannot be determined as the display is all messed up.

By killing compiz from another tty, the session was restored with the following error:

r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!

$ glxinfo | grep Open
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RC410
OpenGL version string: 2.1 Mesa 7.10.1
OpenGL shading language version string: 1.20
OpenGL extensions:

When I switch to a lower display res for both my notebook (1024x768) and lcd monitor (1024x768), compiz runs without error.

Increasing the resolution gradually, I managed to reproduce the display corruption which was automatically resolved when the display res change confirmation dialog time out.

Below is the error output when I increase the resolution to 1440 x 900 (ext LCD monitor) and 1280 x 1024 (notebook):

$ r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
compiz (core) - Warn: Couldn't bind background pixmap 0x2600001 to texture
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
compiz (core) - Warn: Couldn't bind background pixmap 0x2600001 to texture
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
compiz (core) - Warn: Couldn't bind background pixmap 0x2600001 to texture
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!

$ dmesg | grep drm
[ 30.930770] [drm] Initialized drm 1.1.0 20060810
[ 31.409572] [drm] radeon defaulting to kernel modesetting.
[ 31.409578] [drm] radeon kernel modesetting enabled.
[ 31.415104] [drm] initializing kernel modesetting (RS400 0x1002:0x5A62).
[ 31.415149] [drm] register mmio base: 0xC0000000
[ 31.415151] [drm] register mmio size: 65536
[ 31.415342] [drm] Generation 2 PCI interface, using max accessible memory
[ 31.415372] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 31.415374] [drm] Driver supports precise vblank timestamp query.
[ 31.415387] [drm] radeon: irq initialized.
[ 31.415681] [drm] Detected VRAM RAM=128M, BAR=256M
[ 31.415685] [drm] RAM width 128bits DDR
[ 31.424607] [drm] radeon: 128M of VRAM memory ready
[ 31.424610] [drm] radeon: 512M of GTT memory ready.
[ 31.424638] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 31.456089] [drm] radeon: 3 quad pipes, 1 z pipes initialized.
[ 31.492259] [drm] Loading R300 Microcode
[ 31.537152] [drm] radeon: ring at 0x0000000080001000
[ 31.537176] [drm] ring test succeeded in 2 usecs
[ 31.537327] [drm] radeon: ib pool ready.
[ 31.537400] [drm] ib test succeeded in 0 usecs
[ 31.542558] [drm] Panel ID String: QDS
[ 31.542563] [drm] Panel Size 1280x800
[ 31.543782] [drm] Radeon Display Connectors
[ 31.543786] [drm] Connector 0:
[ 31.543789] [drm] VGA
[ 31.543792] [drm] DDC: 0x68 0x68 0x68 0x68 0x68 0x68 0x68 0x68
[ 31.543794] [drm] Encoders:
[ 31.543796] [drm] CRT1: INTERNAL_DAC2
[ 31.543798] [drm] Connector 1:
[ 31.543799] [drm] LVDS
[ 31.543802] [drm] DDC: 0x198 0x198 0x19c 0x19c 0x1a0 0x1a0 0x1a4 0x1a4
[ 31.543805] [drm] Encoders:
[ 31.543806] [drm] LCD1: INTERNAL_LVDS
[ 32.020859] [drm] fb mappable at 0xD0040000
[ 32.020863] [drm] vram apper at 0xD0000000
[ 32.020865] [drm] size 5185536
[ 32.020867] [drm] fb depth is 24
[ 32.020869] [drm] pitch is 5760
[ 32.132044] fb0: radeondrmfb frame buffer device
[ 32.132046] drm: registered panic notifier
[ 32.132060] [drm] Initialized radeon 2.8.0 20080528 for 0000:01:05.0 on minor 0

seems totally like a driver issue, affecting mesa.

did compiz work for you in the previous version of Ubuntu?

Yes it did. Unfortunately I can only verify that compiz was working in Jaunty, 'cos I was not able to get Karmic, Lucid or Maverick to work on my machine at all.

Thanks! ... any other info that might be useful?

btw, I need to add " acpi=off noacpi nolapic" in my kernel boot up.
Also, I am using grub 0.97

Same here with the Ubuntu standard desktop. Compiz crash after login, may be related to using the eZoom. Despite crash, I still have 3D hw accel, zoom and window decorations. In relation to this bug I am using radeon as well.

No, not really a driver issue. Rather, you're pushing the hardware beyond its capabilities.

The X300 radeon card in the Xpress 200M is capable only of a maximum 2048x2048 combined screen dimension when running compiz. See bug #555641.

Arrange your screens top/bottom instead of left/right and you should be fine (it'll fit inside the 2048x2048 limit.) Also, remove the virtual resolution specification in your xorg.conf - shouldn't be needed anymore.

On the X/mesa side of things, this is really a dupe of bug 555641, which is basically a wishlist for upstream's Shatter functionality (which allows building a screen up from multiple texture buffers, each of which would fit within the gpu's texture limits).

However, that functionality is a _long_ way off. In the mean time, I think compiz needs to include a check for the maximum texture size compared with the resolution during boot. This may be a compiz regression, since it used to do this in the past, c.f.:

http://ubuntuforums.org/showthread.php?p=4166024
"""
I am running an integrated ATi XPRESS 200 Series video card.
Here is my COMPIZ :
Checking for Xgl: not present.
...
Checking for Composite extension: present.
Comparing resolution (1440x900) to maximum 3D texture size (2048) Passed.
...
"""

So I will leave the compiz task open here. Possibly it's a dupe of other bugs, this is not an uncommon problem. I'm going to close out the mesa task as Won't Fix, since it's definitely a _valid_ issue, but not something we can really fix on the X side easily, rather than marking this as a dupe, since some work does need done on the compiz side here.

(Btw, there may also need to be similar checks in gnome-settings-daemon if it is used to change monitor layouts while compiz is running, however that's a separate problem...)

@Bryce, you wrote

> No, not really a driver issue. Rather, you're pushing the hardware beyond its capabilities.

> The X300 radeon card in the Xpress 200M is capable only of a maximum 2048x2048 combined screen dimension when running compiz. See bug #555641.

Appreciate your time in looking into this, and your explanation.
While I agree that the driver may not support going beyond 2048 x 2048, I disagree that the hardware is not capable of doing it.

For the past (nearly) two years since Jaunty, I have been using this same notebook with Xpress 200M, enjoying full compiz capability at extended desktop mode with 1440x900 (LCD on video out) + 1280x1024 (notebook LCD). All these with the whistle and bells of 3d desktop etc etc. So, clearly the hardware is capable of compiz effects at larger than 2048x2048.

Granted, the new driver and driver model (DRM etc) may assume or put contraints on the Xpress 200M graphics hardware, and understandably, such constraints cannot be easily fixed.

I'll try with the up-down layout instead of the left-right layout and update this thread again.

Thanks again for all the replies.

Update: I just tried stacking the extended display in a top-bottom layout as suggested, but compiz crashes (no artifacts).

$ compiz --replace &
[1] 31095
Backend : gconf
Integration : true
Profile : default
Adding plugins
Initializing core options...done
Initializing bailer options...done
Initializing detection options...done
Initializing composite options...done
Initializing opengl options...done
Initializing decor options...done
Initializing mousepoll options...done
compiz (core) - Error: Plugin 'text' not loaded.

compiz (shift) - Warn: No compatible text plugin loaded
Initializing shift options...done
Initializing gnomecompat options...done
Initializing place options...done
Initializing snap options...done
Initializing resize options...done
Initializing wall options...done
Initializing vpswitch options...done
Initializing move options...done
Initializing animation options...done
Initializing expo options...done
Initializing ezoom options...done
Initializing workarounds options...done
Initializing staticswitcher options...done
Initializing fade options...done
compiz (core) - Error: Plugin 'text' not loaded.

compiz (ring) - Warn: No compatible text plugin loaded
Initializing ring options...done
Initializing scale options...done

[1]+ Segmentation fault (core dumped) compiz --replace

This issue has an interesting symptom on my Radeon X300SE. Compiz appears to be starting normally, but just as it finishes the screen turns into a jumbled mess of my desktop wallpaper. More interesting is if I enable Enhanced Zoom Desktop and zoom in or out, the screen alternates between that jumbled mess and the wallpaper itself - not zoomed, and with nothing else present (no windows, panels etc), but also not distorted at all. Trying to take a screenshot crashes the X server so I've attached a photo instead.

The system still works just fine; I can even grab windows and move them around with the still-visible cursor (which still changes when over a text field, etc) - I just can't see them, nor anything other than this jumbled mess (or the intact wallpaper if I try to zoom).

It also displays a fairly self-explanatory error message in the terminal:
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!

I wonder if a possible workaround is to not draw the root window, but draw one "fake" root window for each display (or each 2048x2048 region of the display area), copying from the real one or just displaying the desktop wallpaper on it, and not allow any window to be larger than that size? It seems like only the root window is likely to ever get that big in most setups, and there's not really much reason I know of not to split it into multiple windows, which would avoid creating such large textures. (A better idea of course is to split windows into multiple textures, but that requires xrandr 1.4.)

Anyway I just wanted to note that odd symptom and the error message in case anyone else had been asking about it.

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

Actually it looks like what I was experiencing was Bug #789385 - a very similar and related issue, but not the same bug.

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. Compiz, in particular, is in heavy development and this bug may have been fixed in the development version of Ubuntu (12.04) if not on your current version. If you are able, it would be of great help if you could confirm if the bug still exists by testing a livecd (available at ubuntu.com). When you test it and it is still an issue, kindly upload the updated logs by running apport-collect <bug #> and any other logs that are relevant for this particular issue. If you are unable to test the development version, please let us know if you are able to reproduce this issue on Ubuntu 11.10.

Thank you for your help and patience.

I'm currently running Oneric KDE ... with full compositing effects using XRender. Crashes on OpenGL.

Is there any info that I can help provide?

@Observer, thanks for the reply. Have you tweaked compiz via an external manager (such as CCSM)? If yes, please try resetting CCSM to the defaults as that may have triggered this issue.

Also, as I stated in comment 17, it would certainly be beneficial if you could test the dev version (12.04) to see if it has been fixed.

[Expired for Compiz Core because there has been no activity for 60 days.]

[Expired for compiz (Ubuntu) because there has been no activity for 60 days.]