Bug 30483 - r600g makes kwin (ab)use 100% CPU
Summary: r600g makes kwin (ab)use 100% CPU
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2010-09-29 17:24 UTC by Öyvind Saether
Modified: 2010-12-16 11:26 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Öyvind Saether 2010-09-29 17:24:58 UTC
1. Use r600g as of today ("eselect mesa r600 set gallium" on Gentoo)
2. Enable desktop effects in kwin
3. kwin now uses 100% CPU doing.. who knows.

I've tried disabling every effect in kwin, doesn't matter. Tried changing other settings also, makes no difference. kwin works fine with r600c.

I started kwin, waited a while, it keeps on using 100% CPU forever so how long should not matter, and ran gdb kdm $pid. bt gave this: 

(gdb) bt
#0  0x00007fe94bb7101b in memcpy () from /lib/libc.so.6
#1  0x00007fe931000379 in util_copy_rect () from /usr/lib64/dri/r600_dri.so
#2  0x00007fe9310020c5 in util_resource_copy_region ()
   from /usr/lib64/dri/r600_dri.so
#3  0x00007fe930f75c30 in st_texture_image_copy ()
   from /usr/lib64/dri/r600_dri.so
#4  0x00007fe930fac50d in st_finalize_texture ()
   from /usr/lib64/dri/r600_dri.so
#5  0x00007fe930fa1698 in finalize_textures () from /usr/lib64/dri/r600_dri.so
#6  0x00007fe930f9e306 in st_validate_state () from /usr/lib64/dri/r600_dri.so
#7  0x00007fe930f72885 in st_draw_vbo () from /usr/lib64/dri/r600_dri.so
#8  0x00007fe930f97b64 in vbo_exec_vtx_flush () from /usr/lib64/dri/r600_dri.so
#9  0x00007fe930f933c5 in vbo_exec_FlushVertices_internal ()
   from /usr/lib64/dri/r600_dri.so
#10 0x00007fe930f95212 in vbo_exec_FlushVertices ()
   from /usr/lib64/dri/r600_dri.so
#11 0x00007fe930e856e6 in _mesa_PopAttrib () from /usr/lib64/dri/r600_dri.so
#12 0x00007fe94a4a5ca0 in KWin::PaintClipper::Iterator::~Iterator() ()
   from /usr/lib/libkwineffects.so.1
#13 0x00007fe94a4b1a68 in KWin::renderGLGeometry(QRegion const&, int, float cons
t*, float const*, float const*, int, int) () from /usr/lib/libkwineffects.so.1
#14 0x00007fe94bf0de18 in KWin::SceneOpenGL::Window::renderQuads(int, QRegion co
nst&, KWin::WindowQuadList const&) () from /usr/lib/libkdeinit4_kwin.so
#15 0x00007fe94bf121b4 in KWin::SceneOpenGL::Window::performPaint(int, QRegion,
KWin::WindowPaintData) () from /usr/lib/libkdeinit4_kwin.so
#16 0x00007fe94bf0303e in KWin::Scene::finalDrawWindow(KWin::EffectWindowImpl*,
int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so
#17 0x00007fe94bf1b855 in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindo
w*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so
#18 0x00007fe94bf01f2b in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so
#19 0x00007fe94bf1b955 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so
#20 0x00007fe94bf03a4c in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) () from /usr/lib/libkdeinit4_kwin.so
#21 0x00007fe94bf04f67 in KWin::Scene::paintSimpleScreen(int, QRegion) ()
   from /usr/lib/libkdeinit4_kwin.so
#22 0x00007fe94bf01f77 in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so
#23 0x00007fe94bf1ba52 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so
#24 0x00007fe94bf03c75 in KWin::Scene::paintScreen(int*, QRegion*) ()
   from /usr/lib/libkdeinit4_kwin.so
#25 0x00007fe94bf13d9f in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) () from /usr/lib/libkdeinit4_kwin.so
#26 0x00007fe94befe87c in KWin::Workspace::performCompositing() ()
   from /usr/lib/libkdeinit4_kwin.so
#27 0x00007fe94be827c2 in KWin::Workspace::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkdeinit4_kwin.so
#28 0x00007fe94776fda6 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/qt4/libQtCore.so.4
#29 0x00007fe94776c656 in QObject::event(QEvent*) ()
   from /usr/lib64/qt4/libQtCore.so.4
#30 0x00007fe94838cecc in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /usr/lib64/qt4/libQtGui.so.4
#31 0x00007fe9483934cb in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib64/qt4/libQtGui.so.4
#32 0x00007fe94b6cc0e8 in KApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libkdeui.so.5
#33 0x00007fe94775cb0b in QCoreApplication::notifyInternal(QObject*, QEvent*)
    () from /usr/lib64/qt4/libQtCore.so.4
#34 0x00007fe94778957a in ?? () from /usr/lib64/qt4/libQtCore.so.4
#35 0x00007fe94778978b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop:---Type <return> to continue, or q <return> to quit---
:ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#36 0x00007fe94843cc15 in ?? () from /usr/lib64/qt4/libQtGui.so.4
#37 0x00007fe94775b432 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#38 0x00007fe94775b7fd in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#39 0x00007fe94776043b in QCoreApplication::exec() ()
   from /usr/lib64/qt4/libQtCore.so.4
#40 0x00007fe94be9d43b in kdemain () from /usr/lib/libkdeinit4_kwin.so
#41 0x00007fe94bb0ebbd in __libc_start_main () from /lib/libc.so.6
#42 0x00000000004006e9 in _start ()
(gdb) quit
A debugging session is active.

        Inferior 1 [process 379] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/bin/kwin, process 379

I have no idea if the bt help anything at all. Please let me know if I can somehow provide any usefull information and how to get it.

Also, I've whined like a spoiled child about this here: http://www.phoronix.com/forums/showthread.php?t=26196
Comment 1 Michel Dänzer 2010-09-30 02:27:19 UTC
Unless the backtrace is the same all or at least most of the time, a profile from sysprof or oprofile would probably be more useful.
Comment 2 Öyvind Saether 2010-09-30 15:16:10 UTC
I've used too much time trying to figure out how to run the oprofile, I recompiled the kernel with support for it and tried searching for some example of how to use it for hours. Could you please just tell me what commands to run in order to get any useful information from it?
Comment 3 Fredrik Höglund 2010-10-05 10:42:09 UTC
Profiling data confirms what the backtrace shows.

It seems we take this path each time we use a texture after calling glXBindTexImageEXT.
Comment 4 Jerome Glisse 2010-10-07 12:41:57 UTC
Can we have the profiling data attached to bug ?

Btw sysprof is lot easier to use
Comment 5 Michel Dänzer 2010-10-07 14:27:25 UTC
Looks like the problem is an unnecessary copy of the pixmap contents as part of glXBindTexImageEXT(). The fact that the copy is done in software just adds insult to injury, but really it should be possible to use the BO of the pixmap directly.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.