| Bug ID | 98784 |
|---|---|
| Summary | Talos Principle rendering flickering garbage on start instead= of Croteam logo |
| Product | Mesa |
| Version | git |
| Hardware | All |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | vedran@miletic.net |
| QA Contact | dri-devel@lists.freedesktop.org |
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).
Since the last Talos Principle update, I get flickering garbage rendered on
start in place where Croteam logo should be. It looks in style of the attac=
hed
screenshot, varying in colors and shapes. There are no GPU faults or anythi=
ng.
| What | Removed | Added |
|---|---|---|
| Summary | Talos Principle rendering flickering garbage on start instea= d of Croteam logo | Talos Principle rendering flickering garbage on start instea= d of its logo and loading squares |
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.
| What | Removed | Added |
|---|---|---|
| Keywords | regression |
Works correctly with LLVM 3.8 and Mesa 12.0.3.
(In reply to Vedran Mileti=C4=87 from comment #0) > Created attachment 128072 [deta= ils] > Talos rendering in place of Croteam logo >=20 > I'm using Mesa and LLVM git snapshots on kernel 4.8.8 on Tonga (R9 380= X). Maybe something else, but llvm master does currently have an issue. You cou= ld try llvm with the commit reverted. https://llvm.org/= bugs/show_bug.cgi?id=3D31019
(In reply to Andy Furniss from comment #4) > (In reply to Vedran Mileti=C4=87 from comment #0) > > Created at= tachment 128072 [details] > > Talos rendering in place of Croteam logo > >=20 > > I'm using Mesa and LLVM git snapshots on kernel 4.8.8 on Tonga (R= 9 380X). >=20 > Maybe something else, but llvm master does currently have an issue. You > could try llvm with the commit reverted. >=20 > https://llvm= .org/bugs/show_bug.cgi?id=3D31019 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=3D1 ? This will use DRI2 a= nd it should fix the flickering. After bisecting, the first bad commit seems to be: commit d3d33918c79d9e87aedaf6f70ed39f75eed262a0 Author: Michel D=C3=A4nzer <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.c= gi?id=3D97260 Reviewed-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Eric Anholt <eri= c@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=3D0 glxgears. Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back&q= uot;) Cc: "12.0 11.2" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.c= gi?id=3D97549 Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Tested-by: Dieter N=C3=BCtzel <Dieter@nuetzel-hh.de> (cherry picked from commit dc3bb5db8c81e7f08ae12ea5d3ee999e2afcbfd1) :040000 040000 aa5cf86f1e98d023f9539a6a15654fd9754101a2 fb92ad057feeb3fbff38d808c71c7e5e1cead9af M src
I confirm, LIBGL_DRI3_DISABLE=3D1 fixes flickering in Talos, b= lender 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/
| What | Removed | Added |
|---|---|---|
| Resolution | --- | NOTOURBUG |
| Status | NEW | RESOLVED |
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 ob= ject 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.
| What | Removed | Added |
|---|---|---|
| CC | germano.massullo@gmail.com |
*** Bug 99452 has been marked as a dupl= icate 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.
Thanks for raising the issue with Croteam. (In reply to Germano Massullo from = comment #14) > I've just double checked and we definately set G= L_DRAW_FRAMEBUFFER to 0 > (default back buffer) before clear. When I look at the trace from comme= nt #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 flicke= ring 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.
With the permission of Dean Sekulic of Croteam, I attach here = his replies to my e-mail message: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. :/=20 [...] Please do investigate, as I'm not 100% sure that we did everything correctly from our side. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Michel D=C3=A4nzer and the others, what do you think about?
I can't reproduce the glitch any more. Perhaps today's update = of the game fixed it?
(In reply to Torbj=C3=B6rn Andersson from comment #16) > I can't reproduce the glitch any more. Perhaps t= oday's update of the game > fixed it? I still experience the problem even after the update