Bug#648626: GNOME 3's Metacity makes OpenGL applications unstable

2011-11-13 Thread Émeric Maschino
Package: metacity
Version: 2.34.1-2
Severity: important

Hello,

With the delivery of GNOME 3 into Testing, Metacity was upgraded from
version 2.30.1-3 to version 2.34.1-2.

Since then, I'm experiencing stability issue when running
OpenGL-intensive applications (e.g. ioQuake3-based applications or
WebGL Conformance Test Suite
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html):
application runs fine for 10-20 sec. and then seems to lock up.

Switching to a text console shows multiple instances of error messages like:

[drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(11)
[drm:radeon_cs_ioctl] *ERROR* Failed to schedule IB!

Stopping and restarting X didn't help: the display is then garbaged,
and switching back again to the text console reports the same error
messages.

This is with current Metacity 2.34.1-2 when running GNOME 3 in
fallback mode (I can't try GnomeShell at this time because of an udev
issue).

I'm pretty sure this has to deal with some Metacity processing now
performed by the GPU, whereas 2.30.1-3 was relying upon CPU. Indeed, I
had no problem with Metacity 2.30.1-3 that was previously in Testing.
However, I was experiencing the same kind of problem when switching
the window manager from Metacity to Mutter in the GNOME 2 era, and
IIRC, Mutter was heavily relying upon the GPU.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: ia64

Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages metacity depends on:
ii  gnome-icon-theme  3.2.1.2-1
ii  libatk1.0-0   2.2.0-2
ii  libc6.1   2.13-21
ii  libcairo2 1.10.2-6.1
ii  libcanberra-gtk0  0.28-3
ii  libcanberra0  0.28-3
ii  libgconf2-4   2.32.4-1
ii  libgdk-pixbuf2.0-02.24.0-1
ii  libglib2.0-0  2.28.8-1
ii  libgnome2-common  2.32.1-2
ii  libgtk2.0-0   2.24.7-1
ii  libgtop2-72.28.4-1
ii  libice6   2:1.0.7-2
ii  libmetacity-private0a 1:2.34.1-2
ii  libpango1.0-0 1.29.4-2
ii  libsm62:1.2.0-2
ii  libstartup-notification0  0.12-1
ii  libunwind70.99-0.3
ii  libx11-6  2:1.4.4-2
ii  libxcomposite11:0.4.3-2
ii  libxcursor1   1:1.1.12-1
ii  libxdamage1   1:1.1.3-2
ii  libxext6  2:1.3.0-3
ii  libxfixes31:5.0-4
ii  libxinerama1  2:1.1.1-3
ii  libxrandr22:1.3.2-2
ii  libxrender1   1:0.9.6-2
ii  metacity-common   1:2.34.1-2
ii  zenity3.2.0-1

Versions of packages metacity recommends:
ii  gnome-session-fallback [x-session-manager]  3.0.2-3

Versions of packages metacity suggests:
ii  gnome-control-center  1:3.0.2-3
ii  gnome-themes  2.30.2-1
ii  xdg-user-dirs 0.14-1

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#648626: GNOME 3's Metacity makes OpenGL applications unstable

2011-11-13 Thread Josselin Mouette
Le dimanche 13 novembre 2011 à 17:00 +0100, Émeric Maschino a écrit : 
 This is with current Metacity 2.34.1-2 when running GNOME 3 in
 fallback mode (I can't try GnomeShell at this time because of an udev
 issue).
 
 I'm pretty sure this has to deal with some Metacity processing now
 performed by the GPU, whereas 2.30.1-3 was relying upon CPU.

I find this dubious. The point of keeping metacity for the fallback mode
is that it still does everything in software, or only with RENDER
acceleration; it does not use OpenGL.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


signature.asc
Description: This is a digitally signed message part


Bug#648626: GNOME 3's Metacity makes OpenGL applications unstable

2011-11-13 Thread Émeric Maschino
2011/11/13 Josselin Mouette j...@debian.org:
 I find this dubious. The point of keeping metacity for the fallback mode
 is that it still does everything in software, or only with RENDER
 acceleration; it does not use OpenGL.

Could it thus be possible that RENDER acceleration globally
struggles the GPU so that it eventually can't process OpenGL request
correctly?

What has changed between Metacity 2.30 and 2.34 w.r.t 2D (3D?)
acceleration that could explain this issue?

I'm not sure if the lock up during the WebGL tests still appears on
the same test. If yes, I imagine it will help understand what's going
on. I'll try to have a reproduceable error.

 Émeric



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#648626: GNOME 3's Metacity makes OpenGL applications unstable

2011-11-13 Thread Émeric Maschino
2011/11/13 Émeric Maschino emeric.masch...@gmail.com:
 I'm not sure if the lock up during the WebGL tests still appears on
 the same test. If yes, I imagine it will help understand what's going
 on. I'll try to have a reproduceable error.

Unfortunately, WebGL test suite not always locks up on the same test :-(.

I fear this will be, once again on ia64, a nasty bug hard to reproduce
and fix...



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org