Frontbuffer applications aren't flushing correctly. GLUT Olympic rings run single buffered (-sb) on llvmpipe, swr, and softpipe displays corruption. (https://www.opengl.org/archives/resources/code/samples/glut_examples/examples/olympic.c) Other frontbuffer applications display similar errors. Bistected to: eceb6710024716433069d705fbd873d6d136c2cc is the first bad commit commit eceb6710024716433069d705fbd873d6d136c2cc Author: Thomas Hellstrom <thellstrom@vmware.com> 2017-06-20 14:12:50 Committer: Thomas Hellstrom <thellstrom@vmware.com> 2017-08-02 04:55:35 mesa/st: Reduce the number of frontbuffer flush calls The mesa state tracker was needlessly flushing the front buffer even if it hadn't been drawn to since the last flush. This was happening during glXSwapBuffers if we at some point previously had set that frontbuffer as a read- or draw renderbuffer, or at glFlush() or glFinish() if we at some point previously had rendered to the front buffer. Since the frontbuffer flush typically means a full drawable copy, it's a pretty big waste.
I can second this on radeonsi/RX580. 'olympic -sb' show no corruption per se, but no animation (ring movement), here. With commit eceb6710024716433069d705fbd873d6d136c2cc reverted 'olympic -sb' is fine, again.
"no animation" may be a better description. This is exactly what I'm seeing on llvmpipe, swr, and softpipe.
I'm seeing the 'no animation' on i965 too. Sometimes animation happens but most of the time not.
Created attachment 133985 [details] [review] Patch that should fix the issue This patch fixes the issue on my side. Please verify!
(In reply to Tapani Pälli from comment #3) > I'm seeing the 'no animation' on i965 too. Sometimes animation happens but > most of the time not. @Tapani If this is seen on i965/DRI, this commit is probably not to blame since it only touches gallium code.
Verified. Your patch does fix this issue. Does this negate the original intent of your "Reduce the number of frontbuffer flush calls"?
(In reply to Bruce Cherniak from comment #6) > Verified. Your patch does fix this issue. > > Does this negate the original intent of your "Reduce the number of > frontbuffer flush calls"? Nope, we're still skipping the frontbuffer flush when there was nothing rendered to the frontbuffer, (which we didn't do before). But contrary to before, we're updating the framebuffer state after each frontbuffer flush.
Sounds like the right solution then. Thanks for taking a look at this.
(In reply to Thomas Hellström from comment #4) > Created attachment 133985 [details] [review] [review] > Patch that should fix the issue > > This patch fixes the issue on my side. Please verify! Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> on radeonsi/RX580 Thank you Thomas.
Tested-by: Bruce Cherniak <bruce.cherniak@intel.com>
Actually this patch seems to fixes some issues I had with some applications lately (specifically QtCreator didn't redraw properly and old screen content would show up instead). Tested-By: Gert Wollny <gw.fossdev@gmail.com> on r600g/HD 6870
Looks like Thomas pushed patch 6e2b87c7e9 to fix this issue. Top of tree now works correctly. I'll mark this resolved/fixed. Fixed with: commit 6e2b87c7e92b090dc2a08735f6ac96a95266730b Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Thu Sep 7 10:45:10 2017 +0200 mesa/st: Fix frontbuffer rendering regression This fixes a regression introduced with commit "mesa/st: Reduce the number of frontbuffer flush calls" where we, after flushing the front buffer marked it as not-rendered-to, the idea being that it should be marked as "rendered-to" again as soon as any rendering was touching the front. Now the latter part never happened, because it was part of a state validation and we never marked that part of the state as dirty. So mark the framebuffer state dirty after a frontbuffer flush.
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.