Bug 91656

Summary: [APITRACE] [bisected] Pillars of Eternity glitch in maps
Product: Mesa Reporter: christoph.rabel
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium CC: brianp, edmondo.tommasina, farmboy0+freedesktop
Version: git   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description christoph.rabel 2015-08-16 10:06:25 UTC
There is a regression/graphical glitch when playing Pillars of Eternity. When I use the ingame map, it is partly "dark/black".

You can find a screenshot here:
http://images.akamai.steamusercontent.com/ugc/439450977393999113/19DF4F643F0C4BB058665F056DBC4600D669ED7B/

The map looks fine with regular Ubuntu drivers (10.1.3), I checked a couple of days ago with a reinstall (my harddisk broke). After an "upgrade" to oibaf repository, the glitch appeared.

The glitch was not there mid-June with 10.6(?) or so. I used oibaf then too, but didn't play for a month. It was probably introduced about June 15 or later. (Maybe a bit earlier, I don't upgrade the beta drivers every day). It was there when I started playing again July 18th.

My card is a Radeon 4870:

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.0-devel (git-28ed1e0 2015-08-14 trusty-oibaf-ppa)

If you need me to test something or need further information, please feel free to ask. (Enable debug output somehow?) I have browsed PoE logfiles and /var/log, but couldn't find anything that looked even vaguely related. No errors when loading the map or displaying it.

(Btw.: Congrats to Mesa 11!)
Comment 1 Marek Olšák 2015-08-16 11:13:08 UTC
Would you please bisect or create an apitrace that reproduces the issue?
Comment 2 christoph.rabel 2015-08-16 16:39:44 UTC
Hi have create an apitrace, you can find it here:
https://drive.google.com/file/d/0B3-ikYPrROroM3M3SFM4NGd4c0E/view?usp=sharing

I noticed something interesting. The trace slows the rendering of the map down. What I perceived previously as "flickering" became kind of an "animation".

The map is shown an initially nearly "correct". Then it fades and most of it becomes darker and darker till it becomes as in the screenshot. I can create some screenshots, if they are helpful.
Comment 3 Matias Hilden 2015-09-13 11:41:13 UTC
This issue also happens on radeonsi, with Mesa 11.1.0-devel (git-d6fbcf6).

According to POE forums, it used to happen on catalyst too at some point, but it has been fixed since.

My card is R9 280.
Comment 4 Sasha 2015-09-27 07:46:40 UTC
I have same problem.
Radeon HD5670.
Mesa 11.1.0-devel
Comment 5 Daniel Scharrer 2015-09-27 22:03:16 UTC
I can reproduce this on my TAHITI - renders fine with llvmpipe though. Bisected to:

commit c1de7df6d4086070e63369ab0af3950f53a03592
Author: Brian Paul <brianp@vmware.com>
Date:   Mon Jun 22 14:04:09 2015 -0600

    st/mesa: remove unneeded pipe_surface_release() in st_render_texture()
    
    This caused us to always free the pipe_surface for the renderbuffer.
    The subsequent call to st_update_renderbuffer_surface() would typically
    just recreate it.  Remove the call to pipe_surface_release() and let
    st_update_renderbuffer_surface() take care of freeing the old surface
    if it needs to be replaced (because of change to mipmap level, etc).
    
    This can save quite a few calls to pipe_context::create_surface() and
    surface_destroy().
    
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>
    Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Comment 6 Damien Grassart 2015-09-30 13:53:15 UTC
Hi, just wanted to confirm that reverting commit c1de7df6d4086070e63369ab0af3950f53a03592 does indeed fix the issue on my HD7870. Thanks for bisecting Daniel.
Comment 7 farmboy0+freedesktop 2015-10-04 20:21:35 UTC
I have this issue on radeonsi also. Reverting c1de7df6d4086070e63369ab0af3950f53a03592 fixes the problem.
Comment 8 Edmondo Tommasina 2015-10-05 20:15:01 UTC
Thanks Daniel.
Reverting commit c1de7df6d4086070e63369ab0af3950f53a03592 fixes the map issue on my EVERGREEN (HD5850).
Comment 9 Daniel Scharrer 2015-10-06 04:44:33 UTC
This looks like an application bug to me - here's what the game does with the minimap fog of war in the apitrace (right at the start of each frame, so it's easy to find):

1. Uploads the fog of war to GL_ALPHA texture 2487
2. Binds framebuffer 2
3. Attaches texture 6613 as the color0 buffer
4. Clears color to (0, 0, 0, 0)
5. Unbinds framebuffer 2
6. Binds framebuffer 2
7. Attaches texture 6613 as the color0 buffer
8. Binds 6613 as texture0
9. Binds 2487 as texture1
10. Draws a full-screen quad with a shader that boils down to
  a = pow(texture1.a, 8);
  color0 = a * (0, 0, 0, 1) + (1 - a) * texture0;

Reading from and writing to the same texture in this way is undefined without inserting the appropriate memory barriers.
Comment 10 Marek Olšák 2015-10-06 12:19:40 UTC
It should be fine as long as the texture(x,y) maps to the same coordinates in the color buffer. If there is only one draw call, a barrier isn't required.
Comment 11 Daniel Scharrer 2015-10-06 14:45:13 UTC
There is also a glClear though. Currently the texture read ends up with the data before the clear (uninitialized for the first frame, unitialized content with the fog of war blended on top n times for subsequent frames). Are you saying the texture reads should get the color from the clear without any synchronization?
Comment 12 Marek Olšák 2015-10-17 17:29:30 UTC
(In reply to Daniel Scharrer from comment #11)
> There is also a glClear though. Currently the texture read ends up with the
> data before the clear (uninitialized for the first frame, unitialized
> content with the fog of war blended on top n times for subsequent frames).
> Are you saying the texture reads should get the color from the clear without
> any synchronization?

No, glClear+glDraw indeed requires a barrier in between.
Comment 13 Andre Heider 2015-10-30 15:04:43 UTC
So it's a bug in mesa then?

My distro is at 11.0.4 atm, if I'm about to ask for a fix, what's the appropriate measure?
Just revert c1de7df6d4086070e63369ab0af3950f53a03592 for now? Cherry-pick a proper fix?
Comment 14 christoph.rabel 2015-10-30 19:27:31 UTC
This was just posted in PoE forums regarding this issue:

-----
Reported development thread on official forums here - https://forums.obsidian.net/topic/82875-the-map-is-not-displayed-correctly/

Also, please be aware of this thread, which details Mesa rendering issues and a current fix regarding the driver - http://forums.obsidian.net/topic/82667-rendering-issues-on-linux-now-theres-a-work-around/?hl=%2Blinux+%2Bhack
-----

Since somebody already hacked a fix, developers should be able to come up with a nice fix soon.
Comment 15 Daniel Scharrer 2016-03-17 14:40:04 UTC
Looks like this has been fixed in the latest beta for Pillars of Eternity (what will become 3.02) along with the black spots (caused by denormals) in the water shader.
Comment 16 Nicolai Hähnle 2016-03-17 17:12:00 UTC
For what it's worth, a comment in the hack posted on the forum says

"PoE tries to read from and render to a texture at the same time when rendering the minimap. This happens directly after clearing the fbo to (0, 0, 0, 0) so bind a dummy texture with that value instead."

So this was either a PoE bug (so-called "feedback loop") or possibly a driver bug related to clearing a currently bound texture that was fixed recently. In any case, this seems to be fixed now, so closing this report.

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.