Bug 98784

Oops. Croteam logo is indeed there aftewards.

Also observed on Polaris10 and Juniper XT. Looks like the game's flipping between two pages of tiled junk.

Running with LIBGL_DRI3_DISABLE set eliminates the flashing junk, but no further rendering (except for Steam overlay) is done until initialisation is completed.

Works correctly with LLVM 3.8 and Mesa 12.0.3.

(In reply to Vedran Miletić from comment #0)
> Created attachment 128072 [details]
> Talos rendering in place of Croteam logo
> 
> I'm using Mesa and LLVM git snapshots on kernel 4.8.8 on Tonga (R9 380X).

Maybe something else, but llvm master does currently have an issue. You could try llvm with the commit reverted.

https://llvm.org/bugs/show_bug.cgi?id=31019

(In reply to Andy Furniss from comment #4)
> (In reply to Vedran Miletić from comment #0)
> > Created attachment 128072 [details]
> > Talos rendering in place of Croteam logo
> > 
> > I'm using Mesa and LLVM git snapshots on kernel 4.8.8 on Tonga (R9 380X).
> 
> Maybe something else, but llvm master does currently have an issue. You
> could try llvm with the commit reverted.
> 
> https://llvm.org/bugs/show_bug.cgi?id=31019

This actually fixes bug 98783 and bug 98785. Just not this one. :-D

Further findings: similar flickering occurs in Talos Principle latest public beta (not in stable) when switching GPU Speed from High to Ultra, after clicking Apply. The setting gets applied after a while, as expected.

Can you try with LIBGL_DRI3_DISABLE=1 ? This will use DRI2 and it should fix the flickering.

After bisecting, the first bad commit seems to be:

commit d3d33918c79d9e87aedaf6f70ed39f75eed262a0
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Aug 17 17:02:04 2016 +0900

    loader/dri3: Overhaul dri3_update_num_back
    
    Always use 3 buffers when flipping. With only 2 buffers, we have to wait
    for a flip to complete (which takes non-0 time even with asynchronous
    flips) before we can start working on the next frame. We were previously
    only using 2 buffers for flipping if the X server supports asynchronous
    flips, even when we're not using asynchronous flips. This could result
    in bad performance (the referenced bug report is an extreme case, where
    the inter-frame stalls were preventing the GPU from reaching its maximum
    clocks).
    
    I couldn't measure any performance boost using 4 buffers with flipping.
    Performance actually seemed to go down slightly, but that might have
    been just noise.
    
    Without flipping, a single back buffer is enough for swap interval 0,
    but we need to use 2 back buffers when the swap interval is non-0,
    otherwise we have to wait for the swap interval to pass before we can
    start working on the next frame. This condition was previously reversed.
    
    Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97260
    Reviewed-by: Frank Binns <frank.binns@imgtec.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    (cherry picked from commit 1e3218bc5ba2b739261f0c0bacf4eb662d377236)
    
    Squashed with commit:
    
    loader/dri3: Always use at least two back buffers
    
    This can make a significant difference for performance with some extreme
    test cases such as vblank_mode=0 glxgears.
    
    Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
    Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
    Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
    Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
    (cherry picked from commit dc3bb5db8c81e7f08ae12ea5d3ee999e2afcbfd1)

:040000 040000 aa5cf86f1e98d023f9539a6a15654fd9754101a2 fb92ad057feeb3fbff38d808c71c7e5e1cead9af M	src

I confirm, LIBGL_DRI3_DISABLE=1 fixes flickering in Talos, blender and firefox' opengl-accelerated videos

This is likely a Talos bug, making incorrect assumptions about the number of buffers / the contents of the back buffer after SwapBuffers. If somebody can make an apitrace reproducing the problem, that could help confirm.

I made traces of Talos and blender affected by this bug
I'm sorry, but I couldn't upload it anywhere else:

http://file.karelia.ru/t8766g/

The apitrace seems to confirm a Talos bug. It looks like Talos tries to clear the back buffer with glClear, but it still has a non-default framebuffer object bound with glBindFramebuffer, so the glClear doesn't affect the back buffer.

I'd like someone else to take a look and confirm this though.

*** Bug 99452 has been marked as a duplicate of this bug. ***

I have just wrote an e-mail to Croteam support, attaching the URL of this bugreport. I will let you know about any their reply.

With the permission of Dean Sekulic of Croteam, I attach here his replies to my e-mail message:

===============
I've just double checked and we definately set GL_DRAW_FRAMEBUFFER to 0 (default back buffer) before clear.
So wild guess would be that this is a driver issue...?!
Or I missed something. :/ 
[...]
Please do investigate, as I'm not 100% sure that we did everything correctly from our side.
===============

Michel Dänzer and the others, what do you think about?

Thanks for raising the issue with Croteam.

(In reply to Germano Massullo from comment #14)
> I've just double checked and we definately set GL_DRAW_FRAMEBUFFER to 0
> (default back buffer) before clear.

When I look at the trace from comment #10 in qapitrace, I see a bunch of glBindFramebuffer(GL_DRAW_FRAMEBUFFER, ...) calls in frame 0, the last one being

 glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 31)

After that, there are no glBindFramebuffer calls for a long time. GL_DRAW_FRAMEBUFFER isn't set to 0 before frame 777, after which the flickering stops, and the window contents start looking as expected.

I've now also confirmed this with running glretrace in gdb and setting a breakpoint at _mesa_BindFramebuffer.

I'd definitely like somebody else to confirm the above though, to make sure I'm not missing anything.

I can't reproduce the glitch any more. Perhaps today's update of the game fixed it?

(In reply to Torbjörn Andersson from comment #16)
> I can't reproduce the glitch any more. Perhaps today's update of the game
> fixed it?

I still experience the problem even after the update