The OpenGL hack "rubik" that comes with xscreensaver has lost all its coloured tiles, and is now a completely grey puzzle.
Created attachment 12575 [details] seom video capture file of the rubik screensaver The seom video player can be downloaded from: svn co svn://dbservice.com/big/svn/seom/trunk seom
Created attachment 12919 [details] Screenshot of rubik xscreensaver This is xscreensaver 5.04, under Fedora 8 with a Radeon 9550 card.
I've just managed to reproduce this bug with LIBGL_ALWAYS_INDIRECT=1 set, so I don't think it can be r300 related after all.
Unless you disable AIGLX, it's the same driver. FWIW, I can confirm the problem with the r300 driver.
OK, disabling AIGLX and using LIBGL_ALWAYS_INDIRECT puts the colours back in my Rubik's cube. So this is R300 specific after all.
This bug is still present with the xf96-video-ati (git) driver and Mesa (git), as of 2008-03-24.
I have been examining the rubik code. Each individul sub-cube is drawn by a function called draw_cubit(), which has the following structure: draw_cubit() draw_stickerless_cubit() if (back face visible) draw back sticker; if (front face visible) draw front sticker; if (left face visible) draw left sticker; if (right face visible) draw right sticker; if (bottom face visible) draw bottom sticker; if (top face visible) draw top sticker; I have discovered that commenting out the call to draw_stickerless_cubit() here allows the colored stickers to be seen again. It also makes the program run a LOT faster, i.e. there is no longer a huge decrease in performance for larger rubik's cubes. The draw_stickerless_cubit() function look like this: #define CUBELEN 0.50 #define CUBEROUND (CUBELEN-0.05) #define STICKERLONG (CUBEROUND-0.05) #define STICKERSHORT (STICKERLONG-0.05) #define STICKERDEPTH (CUBELEN+0.01) draw_stickerless_cubit: glBegin(GL_QUADS); glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, MaterialGray); /* Put sticker here */ glNormal3f(0.00, 0.00, 1.00); glVertex3f(-CUBEROUND, -CUBEROUND, CUBELEN); glVertex3f(CUBEROUND, -CUBEROUND, CUBELEN); glVertex3f(CUBEROUND, CUBEROUND, CUBELEN); glVertex3f(-CUBEROUND, CUBEROUND, CUBELEN); // And other 5 faces... /* Edges of cubit */ glNormal3f(-1.00, -1.00, 0.00); glVertex3f(-CUBEROUND, -CUBELEN, -CUBEROUND); glVertex3f(-CUBEROUND, -CUBELEN, CUBEROUND); glVertex3f(-CUBELEN, -CUBEROUND, CUBEROUND); glVertex3f(-CUBELEN, -CUBEROUND, -CUBEROUND); // And other 5 faces... glEnd(); glBegin(GL_TRIANGLES); glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, MaterialGray); /* Corners of cubit */ glNormal3f(1.00, 1.00, 1.00); glVertex3f(CUBEROUND, CUBEROUND, CUBELEN); glVertex3f(CUBELEN, CUBEROUND, CUBEROUND); glVertex3f(CUBEROUND, CUBELEN, CUBEROUND); // And other 5 faces... glEnd(); It seems to be the GL_QUADS part of draw_stickerless_cubit() that makes everything very slow, with the stickerless cube somehow masking the colors.
Another interesting point is that once they've been revealed by removing the call to draw_stickerless_cube(), the colored stickers are now shown being drawn in the wrong places. The "solved" rubik's cube clearly isn't solved at all; nor should two faces of the same cubit have the same color sticker.
Amazing! Someone has just checked in a lot of code that seems to have fixed rubik, moebius, antinspect and the other OpenGL screensavers! Wheee :-) !!! This one perhaps? commit 32ef6e75839d6be283e034436e5dd34eabb67958 Author: Keith Whitwell <keith@tungstengraphics.com> Date: Sat Sep 20 08:26:11 2008 -0700 mesa: move fixed function vertex program builder from tnl to core mesa Also unify caching of fragment and vertex programs in shader/prog_cache.c` Brought across from gallium-0.2 Or maybe these? commit 6b146214dc16b441376d8dcaba21bcc4256a2402 Author: Keith Whitwell <keith@tungstengraphics.com> Date: Sat Sep 20 06:43:24 2008 -0700 mesa: move rastpos helper to tnl commit 7ce597508e7400e962c8fdb2d255f9887cb9c710 Author: Keith Whitwell <keith@tungstengraphics.com> Date: Sat Sep 20 06:34:23 2008 -0700 mesa: improved driver query interface Brought over from gallium-0.2 branch. Or possibly this: commit e019ead5d76fd4e6e7d47d23e0284058391e1e29 Author: Brian Paul <brian.paul@tungstengraphics.com> Date: Tue Jun 17 11:29:59 2008 -0600 mesa: add parenthesis (cherry picked from commit c366fd83b617db6c8c064802ff4bf120d654507d)
My mistake - this isn't fixed at all! Instead, Mesa is using swrast_dri.so because of this error with r300_dri.so: $ LIBGL_DEBUG=1 /usr/libexec/xscreensaver/rubik libGL error: dlopen /usr/local/lib/dri/r300_dri.so failed (/usr/local/lib/dri/r300_dri.so: undefined symbol: _tnl_ProgramCacheDestroy) libGL error: unable to load driver: r300_dri.so
What card do you have? I think I have traced the bug, but don't have the proper fix yet.
(In reply to comment #11) > What card do you have? > > I think I have traced the bug, but don't have the proper fix yet. Great news :-)!!And I still have the Radeon 9550.
I think this bug should be marked as duplicate of http://bugs.freedesktop.org/show_bug.cgi?id=17685 I posted a fix there.
Seems to be fixed with current mesa master. Can you confirm?
(In reply to comment #14) > Seems to be fixed with current mesa master. Can you confirm? It certainly doesn't work with vanilla Fedora 11 (Mesa 7.6-devel), and mesa-git is failing to compile for me: $ configure --with-dri-drivers=r300,swrast --disable-gallium $ make gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS @RADEON_CFLAGS@ -DRADEON_COMMON=0 ../common/dri_util.c -o ../common/dri_util.o gcc: @RADEON_CFLAGS@: No such file or directory gmake[5]: *** [../common/dri_util.o] Error 1 I'm also getting a lot of noise in my dmesg log: rubik:7817 freeing invalid memtype c8102000-c8112000 rubik:7817 freeing invalid memtype c8112000-c8122000 rubik:7817 freeing invalid memtype c8122000-c8132000 rubik:7817 freeing invalid memtype c8132000-c8142000 rubik:7817 freeing invalid memtype c8142000-c8152000 rubik:7817 freeing invalid memtype c8152000-c8162000 rubik:7817 freeing invalid memtype c8162000-c8172000 rubik:7817 freeing invalid memtype c8172000-c8182000 rubik:7817 freeing invalid memtype c8182000-c8192000 rubik:7817 freeing invalid memtype c8192000-c81a2000 rubik:7817 freeing invalid memtype c81a2000-c81b2000 rubik:7817 freeing invalid memtype c81b2000-c81c2000 rubik:7817 freeing invalid memtype c81c2000-c81d2000 rubik:7817 freeing invalid memtype c81d2000-c81e2000 rubik:7817 freeing invalid memtype c81e2000-c81f2000 rubik:7817 freeing invalid memtype c81f2000-c8202000 rubik:7817 freeing invalid memtype c8202000-c8212000 rubik:7817 freeing invalid memtype c8212000-c8222000 rubik:7817 freeing invalid memtype c8222000-c8232000 rubik:7817 freeing invalid memtype c8232000-c8242000 rubik:7817 freeing invalid memtype c8242000-c8252000 rubik:7817 freeing invalid memtype c8252000-c8262000 rubik:7817 freeing invalid memtype c8262000-c8272000 rubik:7817 freeing invalid memtype c8272000-c8282000 rubik:7817 freeing invalid memtype c8282000-c8292000 rubik:7817 freeing invalid memtype c8292000-c82a2000 rubik:7817 freeing invalid memtype c82a2000-c82b2000 rubik:7817 freeing invalid memtype c82b2000-c82c2000 rubik:7817 freeing invalid memtype c82c2000-c82d2000 rubik:7817 freeing invalid memtype c82d2000-c82e2000 rubik:7817 freeing invalid memtype c82e2000-c82f2000 rubik:7817 freeing invalid memtype c82f2000-c8302000 Something doesn't look right...
(In reply to comment #15) > (In reply to comment #14) > > Seems to be fixed with current mesa master. Can you confirm? > > It certainly doesn't work with vanilla Fedora 11 (Mesa 7.6-devel), and mesa-git > is failing to compile for me: Try make realclean and then autogen.sh before running configure.
(In reply to comment #16) > Try make realclean and then autogen.sh before running configure. Running autogen.sh again did the trick, and yes, my rubiks cube is no longer grey. But it's still slow, and these messages are appearing in my kernel log: rubik:16882 freeing invalid memtype c8102000-c8112000 rubik:16882 freeing invalid memtype c8112000-c8122000 rubik:16882 freeing invalid memtype c8122000-c8132000 rubik:16882 freeing invalid memtype c8132000-c8142000 rubik:16882 freeing invalid memtype c8142000-c8152000 rubik:16882 freeing invalid memtype c8152000-c8162000 rubik:16882 freeing invalid memtype c8162000-c8172000 rubik:16882 freeing invalid memtype c8172000-c8182000 rubik:16882 freeing invalid memtype c8182000-c8192000 rubik:16882 freeing invalid memtype c8192000-c81a2000 rubik:16882 freeing invalid memtype c81a2000-c81b2000 rubik:16882 freeing invalid memtype c81b2000-c81c2000 rubik:16882 freeing invalid memtype c81c2000-c81d2000 rubik:16882 freeing invalid memtype c81d2000-c81e2000 rubik:16882 freeing invalid memtype c81e2000-c81f2000 rubik:16882 freeing invalid memtype c81f2000-c8202000 rubik:16882 freeing invalid memtype c8202000-c8212000 rubik:16882 freeing invalid memtype c8212000-c8222000 rubik:16882 freeing invalid memtype c8222000-c8232000 rubik:16882 freeing invalid memtype c8232000-c8242000 rubik:16882 freeing invalid memtype c8242000-c8252000 rubik:16882 freeing invalid memtype c8252000-c8262000 rubik:16882 freeing invalid memtype c8262000-c8272000 rubik:16882 freeing invalid memtype c8272000-c8282000 rubik:16882 freeing invalid memtype c8282000-c8292000 rubik:16882 freeing invalid memtype c8292000-c82a2000 rubik:16882 freeing invalid memtype c82a2000-c82b2000 rubik:16882 freeing invalid memtype c82b2000-c82c2000 rubik:16882 freeing invalid memtype c82c2000-c82d2000 rubik:16882 freeing invalid memtype c82d2000-c82e2000 rubik:16882 freeing invalid memtype c82e2000-c82f2000 rubik:16882 freeing invalid memtype c82f2000-c8302000 I can confirm that it's not using swrast accidentally: $ LIBGL_DEBUG=verbose /usr/libexec/xscreensaver/rubik libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0) libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
Mass version move, cvs -> git
The main problem is fixed, so I'm closing this bug. If the screensaver is still too slow, you should create new bug report.
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.