Bug 65192

I forgot to mention: I use the classic shader compiler at the moment and I have egl, gles1, gles2, vdpau and wayland enabled.

Full flags on portage:
[ebuild   R   #] media-libs/mesa-9999::x11  USE="egl gallium gles1 gles2 llvm nptl shared-glapi vdpau wayland -abiwrapper -bindist -classic -debug -gbm -opencl -openvg -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -xa -xorg -xvmc" MULTILIB_ABI="amd64 x86" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" VIDEO_CARDS="r600 (-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -radeon -radeonsi -vmware"

(In reply to comment #2)
> Setting R600_HYPERZ=0 in /etc/environment didn't help.

Are you sure this ended up in the environment of the screensaver hacks? Can you try e.g.

R600_HYPERZ=0 /usr/lib/xscreensaver/antmaze

manually to see if that works better? Same thing might be interesting for R600_DEBUG=sb (or R600_LLVM=0, but AFAICT you're building without the r600g LLVM compiler backend anyway?).

I did as suggested and ran:

R600_HYPERZ=0 /usr/lib/misc/xscreensaver/antmaze

This worked more often, but I could make it crash when using different screensavers. Using

R600_HYPERZ=0 /usr/bin/xscreensaver-demo

and switching between screensavers crashed as often as without R600_HYPERZ=0.
Also, the screensaver juggler3d crashed twice when exiting the window it ran in.

R600_DEBUG=sb didn't help either.

I also confirmed that environment variables are working as they should via setting GALLIUM_HUD.

(In reply to comment #3)
> R600_HYPERZ=0 /usr/bin/xscreensaver-demo
> 
> and switching between screensavers crashed as often as without R600_HYPERZ=0.

Beware that AFAIK the screensaver hacks aren't spawned from the xscreensaver-demo process but from the xscreensaver daemon process. Did you confirm that the latter saw the environment variable?

(In reply to comment #4)
> Beware that AFAIK the screensaver hacks aren't spawned from the
> xscreensaver-demo process but from the xscreensaver daemon process. Did you
> confirm that the latter saw the environment variable?

I'm very sure that the environment variable is seen. Today, I added it to my /etc/environment again, restarted, and confirmed it is there by echo $R600_HYPERZ, which printed 0, as expected.
I'm starting X manually (with startx), so I'm quite certain that the xscreensaver daemon process also sees the variable.

All the following tests have been done with R600_HYPERZ=0 in /etc/environment.

As I mentioned in my previous comment, starting antmaze with the command
R600_HYPERZ=0 /usr/lib/misc/xscreensaver/antmaze
works more often. In fact I couldn't get it to crash in about 25 tries today.

What did crash was again juggler3d on the third try when _closing_ its window. The command used was:
R600_HYPERZ=0 /usr/lib/misc/xscreensaver/juggler3d

Also, by using the xscreensaver-demo application (with R600_HYPERZ=0 in /etc/environment) and switching between random screensavers, I could trigger a crash quickly.

More info:
I tried again with juggler3d and it crashed first time upon exit. flurry also triggered the crash on exit.
So I now suspect that antmaze isn't problematic - it is not starting a screensaver that causes the crash, but closing one. As I switched screensavers randomly in xscreensaver-demo, I just by chance clicked on antmaze when I had a problematic screensaver selected previously.

Update: The crash just triggered with a fullscreen youtube video, after a few seconds of playing.

(In reply to comment #8)
> [...] the bug (or regression, I think it used to work about 2 months ago) 

Can you try confirming that, e.g. by trying Mesa from the 9.1 branch or an older snapshot from master?

Unfortunately I couldn't confirm my thoughts. But I still am quite sure I did not have those problems earlier - I had screensavers and youtube last year and didn't notice regular crashes. I frequently use this linux installation, in fact it's my main os for several years now, so I really would have noticed.
Maybe it's another package ? X, libdrm, radeon-ucode, xf86-video-ati come to mind. Maybe mostly radeon-ucode, as I have the feeling that the problems started at about the same time as the buzz on the uvd code drop.

Well, tests done (I could reproduce the crash on every of these with directly started juggler3d on closing the window, mostly first or second try):

mesa-9.0.3 (forgot to get glxinfo)

mesa-9.0.1.ebuild, glxinfo:
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 3.0 Mesa 9.0.1
OpenGL shading language version string: 1.30

mesa-8.0.4-r1.ebuild, glxinfo:
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 8.0.4
OpenGL shading language version string: 1.20
with 8.0.4, I got only garbage and a lot of these messages:
radeon: The kernel rejected CS, see dmesg for more information.
dmesg:
[ 1580.805418] radeon 0000:02:00.0: r600_cs_track_validate_cb invalid tiling 6 for 0 (0x08110668)
[ 1580.805463] radeon 0000:02:00.0: r600_packet3_check:1720 invalid cmd stream 573
[ 1580.805465] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !



I also tried the oldest kernel I have with 8.0.4, it's a vanilla 3.4.0-rc6. Even there I could get the same crash after closing the window with the garbage output.

I think this bug is fixed.

I retested for this issue on current mesa git (commit 	7568a89500c35f14cbd397f87c77acc915afc672) on kernel 3.10.0-rc7. I could start and exit juggler3d at least 20 times without crash as well as use the xscreensaver-demo application for switching between screensaver previews.

Sorry for not being able to nail down the issue better, but I have limited time.