Bug 13258 - rubik xscreensaver is completely grey
Summary: rubik xscreensaver is completely grey
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2007-11-15 11:52 UTC by Chris Rankin
Modified: 2009-09-19 03:00 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

seom video capture file of the rubik screensaver (95.76 KB, application/octet-stream)
2007-11-15 11:54 UTC, Chris Rankin
Screenshot of rubik xscreensaver (13.71 KB, image/png)
2007-12-03 13:36 UTC, Chris Rankin

Description Chris Rankin 2007-11-15 11:52:29 UTC
The OpenGL hack "rubik" that comes with xscreensaver has lost all its coloured tiles, and is now a completely grey puzzle.
Comment 1 Chris Rankin 2007-11-15 11:54:25 UTC
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
Comment 2 Chris Rankin 2007-12-03 13:36:19 UTC
Created attachment 12919 [details]
Screenshot of rubik xscreensaver

This is xscreensaver 5.04, under Fedora 8 with a Radeon 9550 card.
Comment 3 Chris Rankin 2007-12-15 07:29:04 UTC
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.
Comment 4 Michel Dänzer 2007-12-15 09:18:56 UTC
Unless you disable AIGLX, it's the same driver.

FWIW, I can confirm the problem with the r300 driver.
Comment 5 Chris Rankin 2007-12-15 13:28:54 UTC
OK, disabling AIGLX and using LIBGL_ALWAYS_INDIRECT puts the colours back in my Rubik's cube. So this is R300 specific after all.
Comment 6 Chris Rankin 2008-03-24 06:46:08 UTC
This bug is still present with the xf96-video-ati (git) driver and Mesa (git), as of 2008-03-24.
Comment 7 Chris Rankin 2008-09-04 05:46:00 UTC
I have been examining the rubik code. Each individul sub-cube is drawn by a function called draw_cubit(), which has the following structure:

        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)

        glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, MaterialGray);
        /* Put sticker here */
        glNormal3f(0.00, 0.00, 1.00);
        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...

        glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, MaterialGray);
        /* Corners of cubit */
        glNormal3f(1.00, 1.00, 1.00);

        // And other 5 faces...


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.
Comment 8 Chris Rankin 2008-09-04 12:03:20 UTC
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.
Comment 9 Chris Rankin 2008-09-21 12:00:07 UTC
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)
Comment 10 Chris Rankin 2008-09-21 15:08:35 UTC
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
Comment 11 Maciej Cencora 2009-04-06 17:00:39 UTC
What card do you have?

I think I have traced the bug, but don't have the proper fix yet.
Comment 12 Chris Rankin 2009-04-07 00:55:33 UTC
(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.

Comment 13 Maciej Cencora 2009-04-07 06:18:06 UTC
I think this bug should be marked as duplicate of http://bugs.freedesktop.org/show_bug.cgi?id=17685

I posted a fix there.
Comment 14 Maciej Cencora 2009-07-04 09:38:17 UTC
Seems to be fixed with current mesa master. Can you confirm?
Comment 15 Chris Rankin 2009-07-05 05:39:03 UTC
(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...
Comment 16 Maciej Cencora 2009-07-05 06:13:45 UTC
(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.
Comment 17 Chris Rankin 2009-07-05 07:39:27 UTC
(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
Comment 18 Adam Jackson 2009-08-24 12:28:23 UTC
Mass version move, cvs -> git
Comment 19 Maciej Cencora 2009-09-19 03:00:42 UTC
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.