Platform: IVB/HSW/BYT/BDW Libdrm: (master)libdrm-2.4.54-17-ge8c3c1358ecaf4e90f7d43762357ae6f8e2022b6 Mesa: (master)acaed8f41d3cf57092f3fe3a607b8069c72b57f1 Xserver: (master)xorg-server-1.15.99.902-121-g2f5cf9ff9a0f713b7e03863648 Xf86_video_intel:(master)2.99.912-227-g8587b2fff218537c6ff568ac3ef Cairo: (master)8a605472d201e30ddcf3895d554cc4143cd54fb2 Libva: (master)c61d8c6ce9ffc27320e9e177c1e1123d5f1b5014 Libva_intel_driver:(master)c5cb17ea86f0065a939d3636dd26651c93d497c8 Kernel:(drm-intel-nightly)git-16025d Bug detailed description: ---------------------------------------------- Screen flicker when running Synmark_v6_OglTexMem512 on IVB/HSW/BYT/BDW. The problem exists on gnome-session and Raw X. It’s Xserver regression. Please see dmesg.log and Xorg.0.log. By bisected show the first bad commit is : commit 7ca458493aa2f0aa091c989ea0768611e0730bf5 Author: Chris Wilson <chris@chris-wilson.co.uk> AuthorDate: Wed May 28 08:14:00 2014 +0100 Commit: Keith Packard <keithp@keithp.com> CommitDate: Mon Jun 2 13:11:18 2014 -0700 xfree86: Report Present as a built-in module Reproduce steps: --------------------------------------------- 1, xinit 2, ./synmark2 OglTexMem512
Created attachment 102589 [details] dmesg.log
Created attachment 102590 [details] Xorg.0.log
This happens also in other tests (e.g. FillPixel and FillTexSingle), at least on BDW.
Still seeing frame "ping pong" with DRI3 on BYT & HSW. There's no such issue with DRI2. I'm not anymore seeing it in TexMem tests, but in FillPixel & FillTexSingle, GfxBench 3 fill test and Unigine Heaven, very clearly in last one. I think it happens also in GLB 2.7 tests which are windowed, so it doesn't seem to be screen flip related. Tests where it happens are memory bandwidth bound. Not sure whether them running <60FPS is a factor, maybe it just makes the issue more visible. Can't say whether it still happens also on BDW, at least there's no clear frame ping-poing there. -> A separate tester is in progress to investigate frame updates better (one with increasing number on each frame).
Kevin wrote the tester for this utilizing his earlier Wrath framework: https://github.com/nomovok-opensource/wrath After building Wrath sdl-counter, one can run it with something like this: LD_LIBRARY_PATH=release ./sdl-counter fullscreen on width 1920 height 1080 layer_count 100 Test blends many layers to make itself GPU memory bandwidth bound. Despite being memory bandwidth bound and with low enough FPS to simulate those aspects of the tests where this issue happens, I haven't see this issue with the test. All frames come in order and all are shown on Linux. I.e. triggering condition is something else than just "slow & mem BW limited". Btw. Testing on Windows 8.1 reveals that while at fullscreen every frame ends on screen, in windowed/composited mode some frames may get skipped even although test is running <60 FPS (they of course all still come in right order).
(In reply to Eero Tamminen from comment #4) > I'm not anymore seeing it in TexMem tests, but in FillPixel & FillTexSingle, > GfxBench 3 fill test and Unigine Heaven, very clearly in last one. I think > it happens also in GLB 2.7 tests which are windowed, so it doesn't seem to > be screen flip related. Current FillPixel & FillTexSingle tests expect backbuffer contents to be valid, but this is not correct assumption, so update issues with those tests can be ignored. Other tests don't seem to have this invalid expectation, so issues with them should be real.
I run through all the tests mentioned here and several others on BDW & SKL with latest gfx stack and I don't see the issue anymore (in tests that aren't itself buggy). So, I think it's now fixed, re-open if you still see it. Btw: with latest Mesa, one can use this to verify whether DRI3 is actually used by the application: LIBGL_DEBUG=verbose glxinfo 2>&1 | grep DRI (I.e. whether X, DDX and Mesa all support DRI3 and whether it's enabled.)
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.