[SOLVED] glxgears (or any opengl app):fully black window

Question

With the latest mesa 7.9, kernel 2.6.36.1 and xorg 1.9.2 repo updates i cannot get anymore opengl apps to work.
X starts only with KMS (without segfaults), but when i try (ex.) glxgears i get:
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
and no FPS output.
I've tried stracing and ltracing and i get both stuck on
strace ==> read(3, "\26\0!\0\2\0\200\1\2\0\200\1\206\0\340\0\0\0\0\0,\1,\1\1\0\0\0\0\0\0\0", 4096) = 32
                    poll([{fd=3, events=POLLIN}], 1, -1
(fd 3 is a socket)
ltrace ==> glClear(16640, 0x7fffc634b8f0, 0x85f798, -1, 1
I'm on a RV530 (mobility radeon x1600)
$ glxinfo | grep -i opengl
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV530
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20
OpenGL extensions:
No WW && no EE in Xorg.0.log or errors in dmesg, with or without xorg.conf
Last edited by speps (2011-08-06 00:02:29)

Answer 1

@ConnorBehan
Thank for your reply. I'm on a Mobility Radeon x1600 (RV530) @ x86_64.
Bored to build my own non gallium package every time, so this time
I decided to tackle the issue.
I discovered that running glxgears (or any opengl app) with one of
vblank_mode=0 glxgears
vblank_mode=1 glxgears
solves the black hole issue.
Seems like if there is no .drirc or env variable, vblank_mode unset
is the default and it causes the empty output.
So to solve the black output create a ~/.drirc with
<driconf>
    <device screen="0" driver="dri2">
        <application name="all">
            <option name="vblank_mode" value="0" />
        </application>
    </device>
    <device screen="0" driver="r300">
        <application name="all">
            <option name="vblank_mode" value="0" />
        </application>
    </device>
</driconf>
you can use both "0" or "1" as you need.
Nevertheless, the gallium performances are still worst.
I get about ~350 FPS with glxgears and a lot of apps or games
that run smooth with old drivers (sauerbraten, assaultcube ... )
are still unusable.
AlienArena behaviour is quite interesting, and could be helpful.
As it starts, it plays its logo animation painful slowly at one
frame at second, but it ends quickly.
The main menu is really smooth it plays animations in background
fine and has a great reactivity.
Any sub-menu instead, makes the whole input and output lag and
becomes unusable (it's so hard point at any option, starting a
game becomes impossible)
The main menu, and the sub-menus seems to be the same on a first
look (same animations, etc) but there is some difference that
could be the key to solve all this issues definitely.
Also, I get some slowness with 2d acceleration that i solved
almost by disabling EXAPixmaps
by filling /etc/X11/xorg.conf.d/20-radeon.conf with
Section "Device"
    Identifier "r"
    Driver "radeon"
    Option "EXAPixmaps" "off"
EndSection
Let me know if this work also for you.
Maybe it could be also better in your case, since seems like
a lot of performance issues are related to the x86_64.
Do not give up hope
@AndyRTR
What about letting ati-dri provide both gallium and old
modules in different paths, so choosing which one to use
could be done by application with
LIBGL_DRIVERS_PATH=/path/to/driver appname
? It could be appreciated since a lot gallium users
encounters issues like this.
And what about --enable-gallium-llvm? I read it would improve
performances for many cards. Are there tests with this in
the Arch environment? Cheers