Summary: | Launch options window renders black in Feral Games in current Mesa trunk | ||
---|---|---|---|
Product: | Mesa | Reporter: | Marc Di Luzio <mdiluzio> |
Component: | Mesa core | Assignee: | 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
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. Created attachment 132819 [details]
attachment-22344-0.html
I'm hosting meetings this week. E-mail responses will be delayed. Regards, Tim
(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? Michel, why do you need apitrace? You can have all games from Feral because you are an AMD employee and long-standing Mesa contributor. (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. 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. 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 Removing myself from the CC list as I receive updates via the mailing list. (In reply to Marek Olšák from comment #7) That works. (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! 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.