Bug 101867

Summary: Launch options window renders black in Feral Games in current Mesa trunk
Product: Mesa Reporter: Marc Di Luzio <mdiluzio>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: major    
Priority: medium CC: caberliner, devurandom, johan.gardhage, mdiluzio, root, thellstrom
Version: git   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 101911    
Attachments: attachment-22344-0.html

Description Marc Di Luzio 2017-07-21 08:53:30 UTC
Using Mesa git, currently all Feral games with a pre-game options window render a permanent black frame and are un-playable without settings hacks to skip the options.

Tested primarily on an RX 470, but seen on other radeon cards as well.

Issue is caused by commit 81fb1547772d42c527318837d4207ecdb6899e5d
URL: https://cgit.freedesktop.org/mesa/mesa/commit/?id=81fb1547772d42c527318837d4207ecdb6899e5d

Logging this now in case a fellow developer is already investigating a similar issue and wants to chime in. We'll be attempting to find the root cause, but additional help would be appreciated.
Comment 1 James Legg 2017-07-21 17:06:48 UTC
In loader_dri3_swap_buffers_msc, dri3_find_back increments the index used for selecting the back buffer (draw->cur_back) to the second (index 1) out of two buffer slots because the buffer in the first slot (index 0) is busy. When there is no buffer in the now selected slot, loader_dri3_swap_buffers_msc fails without swapping. This was introduced in 81fb1547772d42c527318837d4207ecdb6899e5d, previously it would have reused the busy buffer and swapped something, even if it resulted in tearing.

When a clear occurs, dri3_get_buffer is used to create a buffer, which also uses dri3_find_back, but this stays on the slot index for the not yet created buffer. However, the options window is not using glClear. It does exactly one draw, with glDrawElementsBaseVertex, that covers the whole window. glDrawElementsBaseVertex doesn't seem to validate the framebuffer in the same way as glClear, so it is stuck on the index with uncreated back buffer despite repeatedly drawing and swapping.
Comment 2 Tim Writer 2017-07-21 17:07:01 UTC
Created attachment 132819 [details]
attachment-22344-0.html

 I'm hosting meetings this week. E-mail responses will be delayed. Regards, Tim
Comment 3 Michel Dänzer 2017-07-24 07:58:30 UTC
(In reply to James Legg from comment #1)
> glDrawElementsBaseVertex doesn't seem to validate the framebuffer in
> the same way as glClear, [...]

That sounds like the core of the problem.

Can you create an apitrace demonstrating the problem?
Comment 4 Marek Olšák 2017-07-24 13:05:47 UTC
Michel, why do you need apitrace? You can have all games from Feral because you are an AMD employee and long-standing Mesa contributor.
Comment 5 Marc Di Luzio 2017-07-24 13:21:41 UTC
(In reply to Marek Olšák from comment #4)
> Michel, why do you need apitrace? You can have all games from Feral because
> you are an AMD employee and long-standing Mesa contributor.

Michel already has an all access key.

We're making a trace/minimum test case though, it'd be good to make sure this
will be caught by tests in the future.
Comment 6 James Legg 2017-07-24 14:20:27 UTC
Unfortunately, I've been unable to reproduce the bug while replaying a trace captured with apitrace (the bug occurs while capturing however). Capturing traces from builds of recent Feral titles available on Steam will be difficult as we've tried to avoid Steam injecting its overlay in the options window when glXSwapBuffer is called, and this also prevents apitrace from capturing those calls (which are important for this bug).

Forcing Mesa to call st_validate_state in prepare_draw in state_tracker/st_draw.c, regardless of st->dirty, works around the bug. I'm still investigating, and trying to make a minimal reproducer.
Comment 7 Marek Olšák 2017-07-24 23:15:12 UTC
Can you try this:

diff --git a/src/mesa/state_tracker/st_manager.c b/src/mesa/state_tracker/st_manager.c
index 834bcc9..ede5439 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -642,6 +642,12 @@ st_context_flush(struct st_context_iface *stctxi, unsigned flags,
 
    if (flags & ST_FLUSH_FRONT)
       st_manager_flush_frontbuffer(st);
+
+   /* Enter st_validate_state in the next draw call to revalidate
+    * the framebuffer.
+    */
+   if (flags & ST_FLUSH_END_OF_FRAME)
+      st->gfx_shaders_may_be_dirty = true;
 }
 
 static boolean
Comment 8 Michel Dänzer 2017-07-25 03:09:06 UTC
Removing myself from the CC list as I receive updates via the mailing list.
Comment 9 James Legg 2017-07-25 08:35:44 UTC
(In reply to Marek Olšák from comment #7)

That works.
Comment 10 Marc Di Luzio 2017-07-25 15:58:10 UTC
(In reply to James Legg from comment #6)
> traces from builds of recent Feral titles available on Steam will be
> difficult as we've tried to avoid Steam injecting its overlay in the options
> window when glXSwapBuffer is called, and this also prevents apitrace from
> capturing those calls (which are important for this bug).

Unknown to James at the time we do have a way of disabling this in live builds.

I'll note it here so that someone else who stumbles on a similar issue can know
how to grab a working trace of our options window.

In ~/.local/share/feral-interactive/{GAMENAME}/preferences there'll be a key
called "AvoidSwapInjectionDuringPGOW" that basically does what it says on the
tin - setting it to 0 will prevent our steam overlay avoidance occurring.

If that key doesn't exist then it's an older game without the swap hack.

I've seen the mesa-dev patch mail, thanks Marek!
Comment 11 Marc Di Luzio 2017-07-28 14:07:37 UTC
Marek pushed the fix in commit 7257c171e9eadc05903140cffa26a253f0d0178a
URL: https://cgit.freedesktop.org/mesa/mesa/commit/?id=7257c171e9eadc05903140cffa26a253f0d0178a

Verified on our end so resolving as fixed.

Cheers all.

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.