Would you please bisect or create an apitrace that reproduces the issue?

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.

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.

I have same problem.
Radeon HD5670.
Mesa 11.1.0-devel

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>

Hi, just wanted to confirm that reverting commit c1de7df6d4086070e63369ab0af3950f53a03592 does indeed fix the issue on my HD7870. Thanks for bisecting Daniel.

I have this issue on radeonsi also. Reverting c1de7df6d4086070e63369ab0af3950f53a03592 fixes the problem.

Thanks Daniel.
Reverting commit c1de7df6d4086070e63369ab0af3950f53a03592 fixes the map issue on my EVERGREEN (HD5850).

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.

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.

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?

(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.

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?

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.

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.

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.