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.
eceb6710024716433069d705fbd873d6d136c2cc is the first bad commit
Author: Thomas Hellstrom <firstname.lastname@example.org> 2017-06-20 14:12:50
Committer: Thomas Hellstrom <email@example.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.
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>
Thank you Thomas.
Tested-by: Bruce Cherniak <firstname.lastname@example.org>
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 <email@example.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.
Author: Thomas Hellstrom <firstname.lastname@example.org>
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.