I have just *one* machine that replicates this issue, bizarrely. I'm hoping that might give me some more inspiration.

So far, it looks to be related to the VidMode change, changing resolution using xrandr, then starting the game and running at that resolution is fine. AFAICT, it is issuing the batches containing the copies for the swapbuffers and the scanout does appear to match the frontbuffer (and the output is lit)... But those copies appear to have no affect... The implication would seem to be that we disagree with mesa over the name of the backbuffer (hence copying from a clear buffer when asked to swap).

I had this bug even with Sandy Bridge (Core i5 2500K), but I didn't apply any xorg patch.

Did you also include...?

http://cgit.freedesktop.org/~ickle/xserver/commit/?id=2715e0092a1fbda1aa06aab5760084a4030c727c

http://cgit.freedesktop.org/~ickle/xserver/commit/?id=7e72229cc3fbb949647bc910c84cd4d2f22695fc

http://cgit.freedesktop.org/~ickle/xserver/commit/?id=e9fa77b3c2fdbc0553ff45013511a6d38e5c6531

http://cgit.freedesktop.org/~ickle/xserver/commit/?id=f0089d21cdf87a1078aaa7f27d1827ee05fae7a6

What the fuck, it fixed the problem and... it's so damn fast! From 57fps to 90+fps in openarena, I can't believe it!
You did a so damn good job, congrats!

I didn't notice it during the benchmark, but there are lots of artifacts, something like a *HEAVY* flickering. There is no problem when running it windowed.

Let's recap the current status: your X server now has all the dri2 patches? You see the flicker during normal gameplay (vblank_mode=1) or during the benchmark (vblank_mode=0)? Any warnings in dmesg, Xorg.log?

Flicker is usually caused by when we get the front/back buffers muddled up. But equally it could be a bug lurking elsewhere in the pageflipping code.

Might be worth compiling with --enable-debug[=full] to see if that catches any errors. With --enable-debug=full, it will be quite slow as it generates a voluminous log file which may be helpful if you can reproduce the flicker with it enabled.

> your X server now has all the dri2 patches?
Yes, it has 8 patches now (the 4 I linked + the 4 you linked).


>You see the flicker during normal gameplay (vblank_mode=1) or during
> the benchmark (vblank_mode=0)?
I always keep SwapBufferWaits disabled and vblank_mode=0, during the benchmark it was simply too fast to notice it. Everything works flawlessly if it's not fullscreen.


> Any warnings in Xorg.log?

Yes, but I wouldn't have notice them if it wasn't for grep:

laptop ~ # cat /var/log/Xorg.0.log | grep "(EE)"
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    68.898] (EE) Query no Synaptics: 6003C8
[    68.898] (EE) SynPS/2 Synaptics TouchPad Unable to query/initialize Synaptics hardware.
[    68.910] (EE) PreInit returned 11 for "SynPS/2 Synaptics TouchPad"
laptop ~ # cat /var/log/Xorg.0.log | grep "(WW)"
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    67.419] (WW) intel(0): Option "SwapBuffersWait" is not used
[   200.178] (WW) intel(0): sna_dri_get_msc:1483 get vblank counter failed: Invalid argument
[   341.049] (WW) intel(0): sna_dri_get_msc:1483 get vblank counter failed: Invalid argument
[   341.070] (WW) intel(0): sna_dri_get_msc:1483 get vblank counter failed: Invalid argument
[   344.717] (WW) intel(0): sna_dri_get_msc:1483 get vblank counter failed: Invalid argument
[   344.722] (WW) intel(0): sna_dri_get_msc:1483 get vblank counter failed: Invalid argument




>Any warnings in dmesg?

Just something backlight related, since 2.6.39 intel has native backlight support, but it just sucks too hard to use it and so I patch the kernel with samsung-backlight and it complains about duplicate driver or something similar:

[   18.364160] ACPI: AC Adapter [ADP1] (on-line)
[   18.590489] samsung_backlight: found laptop model 'X360'
[   18.590512] ------------[ cut here ]------------
[   18.590520] WARNING: at drivers/video/backlight/backlight.c:314 backlight_device_register+0xfb/0x16e()
[   18.590523] Hardware name: X360                       
[   18.590526] samsung: invalid backlight type
[   18.590528] Modules linked in: samsung_backlight(+) soundcore snd_page_alloc ac power_supply tpm_tis tpm psmouse sky2 pcspkr serio_raw tpm_bios processor thermal fan evdev container
[   18.590547] Pid: 392, comm: modprobe Not tainted 3.0.0-rc7 #1
[   18.590550] Call Trace:
[   18.590557]  [<ffffffff81042a4d>] ? warn_slowpath_common+0x78/0x8c
[   18.590562]  [<ffffffff81042b00>] ? warn_slowpath_fmt+0x45/0x4a
[   18.590569]  [<ffffffff812b79c9>] ? device_private_init+0x3a/0x40
[   18.590573]  [<ffffffff81206c3d>] ? backlight_device_register+0xfb/0x16e
[   18.590580]  [<ffffffffa007b01a>] ? dmi_check_cb+0x1a/0x1a [samsung_backlight]
[   18.590586]  [<ffffffffa007b0e8>] ? samsung_init+0xce/0xfe6 [samsung_backlight]
[   18.590592]  [<ffffffffa007b01a>] ? dmi_check_cb+0x1a/0x1a [samsung_backlight]
[   18.590598]  [<ffffffff81002078>] ? do_one_initcall+0x78/0x131
[   18.590604]  [<ffffffff8106ee20>] ? sys_init_module+0xb7/0x207
[   18.590610]  [<ffffffff81403792>] ? system_call_fastpath+0x16/0x1b
[   18.590613] ---[ end trace d27716271cc15a8d ]---
[   18.619196] ACPI: Battery Slot [BAT1] (battery present)
[   18.736303] iTCO_vendor_support: vendor-support=0
[   18.738982] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06
[   18.739332] iTCO_wdt: Found a ICH9M-E TCO device (Version=2, TCOBASE=0x0460)
[   18.739421] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   18.767676] samsung_laptop: found laptop model 'X360'
[   18.768660] ------------[ cut here ]------------
[   18.768671] WARNING: at fs/sysfs/dir.c:455 sysfs_add_one+0x8c/0x9e()
[   18.768674] Hardware name: X360                       
[   18.768677] sysfs: cannot create duplicate filename '/class/backlight/samsung'
[   18.768680] Modules linked in: samsung_laptop(+) iTCO_wdt iTCO_vendor_support rfkill snd battery samsung_backlight soundcore snd_page_alloc ac power_supply tpm_tis tpm psmouse sky2 pcspkr serio_raw tpm_bios processor thermal fan evdev container
[   18.768708] Pid: 392, comm: modprobe Tainted: G        W   3.0.0-rc7 #1
[   18.768711] Call Trace:
[   18.768718]  [<ffffffff81042a4d>] ? warn_slowpath_common+0x78/0x8c
[   18.768723]  [<ffffffff81042b00>] ? warn_slowpath_fmt+0x45/0x4a
[   18.768729]  [<ffffffff811395e8>] ? sysfs_add_one+0x8c/0x9e
[   18.768733]  [<ffffffff8113a2f1>] ? sysfs_do_create_link+0x100/0x1a7
[   18.768740]  [<ffffffff812b800d>] ? device_add+0x216/0x5d0
[   18.768746]  [<ffffffff810372ac>] ? complete_all+0x32/0x41
[   18.768752]  [<ffffffff81206c4e>] ? backlight_device_register+0x10c/0x16e
[   18.768759]  [<ffffffffa00a401d>] ? dmi_check_cb+0x1d/0x1d [samsung_laptop]
[   18.768765]  [<ffffffffa00a4532>] ? samsung_init+0x515/0xfe3 [samsung_laptop]
[   18.768771]  [<ffffffffa00a401d>] ? dmi_check_cb+0x1d/0x1d [samsung_laptop]
[   18.768776]  [<ffffffff81002078>] ? do_one_initcall+0x78/0x131
[   18.768782]  [<ffffffff8106ee20>] ? sys_init_module+0xb7/0x207
[   18.768788]  [<ffffffff81403792>] ? system_call_fastpath+0x16/0x1b
[   18.768792] ---[ end trace d27716271cc15a8e ]---




> Flicker is usually caused by when we get the front/back buffers muddled up.
> But equally it could be a bug lurking elsewhere in the pageflipping code.

There are also artifacts like horizontal scans, like with noisy analog transmissions. I'm sorry but I don't how to describe it.

> Might be worth compiling with --enable-debug

Where should I enable debug? xorg-server? libdrm? mesa? xf86-video-intel? All of them?

Telepathy failed. Enable debug in the ddx [xf86-video-intel].

Created attachment 49181 [details]
xorg.log with full debug

Here it is, it take down the whole X server while closing openarena :D

I am going to remove immediately the debug option because even switching from firefox to thunderbird is a pain in the ass with debugit enabled -.-

That we hit an assert is good to know, it gives me to something to track down at least...

I've been trying to reproduce this on an gm965 (which is closely related to the gm45) and I haven't yet seen the flicker using an external DVI output, either in the benchmarks or running the game by hand, with and without debugging enabled.

If you look in /var/log/gdm/:0.log* hopefully the assertion failure message from when X dies will have been recorded. Otherwise if I can ask you hook gdb up to your Xserver and play the game one more time with debugging. Note, you will need to ssh in from a second computer to attach gdb.

As soon as I start "gdb /usr/bin/Xorg $(pidof X)" from ssh I lose control of mouse and keyboard in my laptop and so I can't start openarena anymore :(

Hmm, that gdb invocation looks wrong (but it has been some time since I RTFM): try sudo gdb --pid=$(pidof X) (again from a remote ssh login).

I still loose control of my mouse and my keyboard :(

Any suggestion? Should something like "wait 10 && openarena" work? It would be enough to trigger the flickering but I will have to click to "exit" to trigger the X crash and I will not be able to do it  without the keyboard :(
Also, with debug enabled the X server behaves strangely: clicking on the "X" to close an application does switch to another one @_@

I'm not actually sure. Loosing apparent control of input devices is expected when attaching gdb to X, as X is suspended until you tell gdb to continue. That's why we need to attach gdb from a remote computer so that we can monitor X without needing its display. You could use a .gdbinit script to tell gdb to automatically continue, but you would still loose control when X crashed and we would still not get the backtrace, unless we told it to automatically dump the stacktrace and exit. Hmm.

Even more bizarre is that the behaviour should not change with debug enabled. Granted I may have made a typo or two, but I hope insignificant...

(In reply to comment #16)
> I still loose control of my mouse and my keyboard :(

When gdb has started you will in your ssh session be presented with a prompt, right? What happends if you write "contiune" and press enter?

The original issue should now be fixed in a recent xserver, and the debug should now be debugged!

Yes, the original issue is fixed (thanks!).
I'm sorry if it took so much time to answer but I get a bad day trying to find a working combo of kernel/xorg for a daily use with SNA :/
With linux-3.0.x everything seemed to work except konsole (yes, kde's terminal emulator!) which is very strange: as soon as I started konsole xorg did crash XD
With xorg-server-1.11.99.2, linux-3.2-rc6+ and latest libdrm/mesa/xf86-video-intel SNA does work flawlessly (except vaapi being 25% slower).

vaapi is affected? how?

I use 3.2 with i915.i915_enable_fbc=0 as that is causing some nasty issues on my SNB laptops. You also definitely want a 3.1+ kernel since I've tweaked SNA to assume we LLC on SNB and the kernel doesn't yet have the feature flag for me to use the old code paths for SNB on older kernels.

Can you grab some profiling data with vaapi?

I know, that's strange (after seeing konsole taking down the whole xorg server that's not so strange after all :)

Multi threaded decoding (SwapbuffersWait OFF):

mplayer2 -vc ffh264 -lavdopts threads=3 -benchmark -nosound <file>

Time elapsed: 81.897s


vaapi (kwin desktop effects OFF, SwapbuffersWait OFF, NO SNA):

mplayer -vo vaapi -va vaapi -benchmark <file>
Time elapsed: 82.468s


vaapi (kwin desktop effects OFF, SwapbuffersWait OFF, SNA):

mplayer -vo vaapi -va vaapi -benchmark <file>

Time elapsed: 101.282s


Here is the test video I used: http://www.sendspace.com/file/qv2ws9 (86 seconds, 200MB)


I do use libva git g45-h264 branch (http://cgit.freedesktop.org/libva/log/?h=g45-h264) + latest 5 patches from http://cgit.freedesktop.org/vaapi/intel-driver/log/?h=g45-h264


I did also boot with i915.i915_enable_fbc=0 and i915.lvds_downclock=0.


> Can you grab some profiling data with vaapi?

Yes, just let me know how.

It seems sendspace removed the file, I uploaded it on my own server:
http://files.linuxsystems.it/test.mkv

vaapi should be better, but since the libva driver is extremely poor I don't hold much hope. Only that SNA should be no worse than UXA.