The problem described in https://bugs.freedesktop.org/show_bug.cgi?id=28002 actually also happens with the ati driver. Just that with the ati driver, it is less visible (the car position jumps less), but with LIBGL_ALWAYS_INDIRECT it also becomes a lot more smooth.
Please attach (as opposed to paste) the output of glxinfo with and without LIBGL_ALWAYS_INDIRECT.
Created attachment 35599 [details] LIBGL_ALWAYS_INDIRECT=true glxinfo
Created attachment 35600 [details] glxinfo
Comment on attachment 35599 [details] LIBGL_ALWAYS_INDIRECT=true glxinfo description is command line used
Quite a few more extensions are available with direct rendering, e.g. GLX_SGI_video_sync. Maybe there's a problem with one of those. Might be interesting to, with direct rendering: * If the maniadrive process hogs the CPU: Get a profile with sysprof or oprofile. * Otherwise: Interrupt execution at regular intervals in gdb and see if it's in a particular place most of the time.
It doesn't hog cpu, and the performance decrease in fps is minimal. After 30ish ^Cs in gdb the most common backtrace pattern is: Program received signal SIGINT, Interrupt. 0xffffe424 in __kernel_vsyscall () (gdb) bt #0 0xffffe424 in __kernel_vsyscall () #1 0xb6e92b16 in poll () from /lib/i686/libc.so.6 #2 0xb5e94c10 in ?? () from /usr/lib/libxcb.so.1 #3 0xb5e96c14 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #4 0xb637e33b in _XReply () from /usr/lib/libX11.so.6 #5 0xb69828a8 in ?? () from /usr/lib/libGL.so.1 #6 0xb6982fae in glXMakeCurrentReadSGI () from /usr/lib/libGL.so.1 #7 0xb6983103 in glXMakeCurrent () from /usr/lib/libGL.so.1 #8 0xb6f6deea in myglutGetEvents () from /usr/lib/libraydium.so.0 #9 0xb6f6e004 in glutMainLoop () from /usr/lib/libraydium.so.0 #10 0xb6f33120 in raydium_callback () from /usr/lib/libraydium.so.0 #11 0x08053fe6 in ?? () #12 0xb6ddcb96 in __libc_start_main () from /lib/i686/libc.so.6 #13 0x0804b8c1 in ?? () the second most common pattern is: Program received signal SIGINT, Interrupt. 0xb6e92aa1 in poll () from /lib/i686/libc.so.6 (gdb) bt #0 0xb6e92aa1 in poll () from /lib/i686/libc.so.6 #1 0xb5e94c10 in ?? () from /usr/lib/libxcb.so.1 #2 0xb5e951c2 in ?? () from /usr/lib/libxcb.so.1 #3 0xb5e95591 in xcb_writev () from /usr/lib/libxcb.so.1 #4 0xb637e12c in _XSend () from /usr/lib/libX11.so.6 #5 0xb69831a8 in ?? () from /usr/lib/libGL.so.1 #6 0xb69a1e7a in ?? () from /usr/lib/libGL.so.1 #7 0xb6f53890 in raydium_particle_draw_all () from /usr/lib/libraydium.so.0 #8 0xb6f32fe3 in raydium_callback_image () from /usr/lib/libraydium.so.0 #9 0xb6f57158 in raydium_rendering_finish () from /usr/lib/libraydium.so.0 #10 0x08052a85 in ?? () #11 0xb6f6dfff in glutMainLoop () from /usr/lib/libraydium.so.0 #12 0xb6f33120 in raydium_callback () from /usr/lib/libraydium.so.0 #13 0x08053fe6 in ?? () #14 0xb6ddcb96 in __libc_start_main () from /lib/i686/libc.so.6 #15 0x0804b8c1 in ?? () only a few times I got a "random" different backtrace, eg: Program received signal SIGINT, Interrupt. 0xb62a800c in pthread_once () from /lib/i686/libpthread.so.0 (gdb) bt #0 0xb62a800c in pthread_once () from /lib/i686/libpthread.so.0 #1 0xb692b9d7 in ?? () from /usr/lib/libGL.so.1 #2 0xb69376d4 in ?? () from /usr/lib/libGL.so.1 #3 0xb6ef84c1 in raydium_osd_printf () from /usr/lib/libraydium.so.0 #4 0x0804c91d in ?? () #5 0x08052a80 in ?? () #6 0xb6f16fff in glutMainLoop () from /usr/lib/libraydium.so.0 #7 0xb6edc120 in raydium_callback () from /usr/lib/libraydium.so.0 #8 0x08053fe6 in ?? () #9 0xb6d85b96 in __libc_start_main () from /lib/i686/libc.so.6 #10 0x0804b8c1 in ?? ()
Possible next steps would be trying to figure out if it really needs to call glXMakeCurrent() so often / why that takes such a long time.
(In reply to comment #7) > Possible next steps would be trying to figure out if it really needs to call > glXMakeCurrent() so often / why that takes such a long time. I tried to find in the svn log in http://raydium.org/svn.php?all= but neither there neither a way to do a svn checkout and then a svn annotate... If you look at http://raydium.org/svn.php?f=/trunk/raydium/myglut-x11.c, in "void myglutGetEvents (void)" it calls it for ConfigureNotify events, but also always call when leaving that function. The only non local exits are for ClientMessage and DestroyNotify events. Maybe it was some kind of workaround to some bug. I made a bug report also at the maniadrive forum at: http://memak.raydium.org/viewtopic.php?f=10&t=2115 as it appears to be a raydium or maniadrive bug. At least based on your comment. Thanks.
Just for the record, I made a build commenting the call to glxMakeCurrent() and tested on an ati and intel card. In the ati, it appears to have resolved the issue, but framerates become reported as like 9 fps, and it was indeed somewhat choppy, but the car did not keep "jumping". With the intel card it did not make any difference, and still LIBGL_ALWAYS_INDIRECT=true would correct the issue in the alternate build (and framerate as over 150 fps in both cards/computers). [ talking about intel card because I also reported the problem in https://bugs.freedesktop.org/show_bug.cgi?id=28002 ]
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/126.
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.