Created attachment 97258 [details] reproducer Starting from 10.1 release, Mesa/i915 has a blit fastpath for glDrawPixels. It seems to not work properly for some, but not all, users, instead producing a black window or a window showing contents from elsewhere on the screen. I've been unable to reproduce it on my hardware. Software versions on which the problem is observed: Xorg 1.15, xf86-video-intel 2.99.911, Mesa 10.1 So far it's known that UXA is not affected; with SNA: IVB and HSW are affected. A few users affected by the problem are gathered at https://github.com/amonakov/primus/issues/138; since I couldn't reproduce the problem I'll encourage them to add themselves to CC here. A test case is attached. It expects the number of frames to draw as the first argument (./a.out 1000).
It sounds like a missing intel_prepare_render() in mesa, tbh. I haven't found a failing machine either.
I'm affected by this bug, anything I can do to help? Log created by the test program is attached.
Created attachment 97303 [details] Log by "reproducer"
Found a machine on which the test case fails. It neither works with SNA nor UXA. Mesa is simply not rendering the upload into the backbuffer.
That's with 10.1.0-4ubuntu4 on ivb, but works with both UXA/SNA and mesa.git.
Somehow I got my laptop in a state where the problem is in effect. Investigating. It bisects to commit 3224f0c978f02f52bb8c2bdc8df33294e2fdaf30 Author: Fredrik Höglund <fredrik@kde.org> Date: Thu Feb 13 21:07:09 2014 +0100 glx: Fix the default values for GLXFBConfig attributes Switching config->drawableType back to 0 "fixes" the problem. Otherwise somehow qsort returns an array of fbconfigs where an 8x msaa config comes first (wtf, but it still should draw something, right?)
OK. So bisect blames an innocent commit for two reasons: 1. Xorg-1.15 does not have this fix yet: http://cgit.freedesktop.org/xorg/xserver/commit/glx?id=96a28e9c914d7ae9b269f73a27b99cbd3c465ac8 (the usual question applies: how could things possibly work before?) 2. PREFER_SMALLER in fbconfig_compare assumes limited range, and does not sort random visualSelectGroups properly (it says -1000000000 is "more than" 2000000000 due to overflow). So when the bisected-to commit reduces the number of configs passed to qsort, the order becomes different even if Xserver returns the same bogus visualSelectGroups. Hacking around the xorg bug in mesa by clamping selectgroups to 0 fixes the test for me. And also explains why people were seeing lower performance with new stack. Next Xorg releases should fix it for real. So the only thing left on the table is i965-blit-glDrawPixels not working with MSAA. I'll file that on the Mesa side.
Mesa/i965 blit bug is filed as https://bugs.freedesktop.org/show_bug.cgi?id=77412
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.