The problem does not occure with stable Mesa version 10.3.7 shipped by openSUSE 13.2. So this bug can be marked as regression.

Is it possible for you to bisect to find where the problem was introduced?

How can I bisect?

or maybe we just close this bug and wait for next stable version which may will fix the problem.

(In reply to Md Imam Hossain from comment #3)
> How can I bisect?

Have you build and installed Mesa from source before?  If not, the alternative may be for you to provide an apitrace.

I see this AFAICT exactly same issue with both radeonsi and swrast on recent HEAD of mesa, so this is not Intel-specific. FWIW, I also tried with Mesa 10.3.7 (mentioned by the submitter as working) and still saw the same problem, otherwise I would have bisected.

I also have an apitrace for the issue. I admit I haven't tested it on any proprietary drivers...

https://drive.google.com/file/d/0BwgPzH1WFyIuUEVLQ0NtVGlOSVU/view?usp=sharing

(sorry, around 233 MiB compressed... it also hit an apitrace trimming bug so I could not trim it.)

See around frame 500 for the issue.

I admit I have not tested this trace on any of the proprietary drivers. However I've heard the game renders correctly on those.

This is what frame 500 looks like for me: http://sliedes.kapsi.fi/mesa/civbe/frame500.png

This is what the same map looks like on Windows, and I'd presume it looks close to similar on the proprietary drivers on Linux: http://sliedes.kapsi.fi/mesa/civbe/windows1.jpg

(In reply to Sami Liedes from comment #6)
> I see this AFAICT exactly same issue with both radeonsi and swrast on recent
> HEAD of mesa, so this is not Intel-specific. FWIW, I also tried with Mesa
> 10.3.7 (mentioned by the submitter as working) and still saw the same
> problem, otherwise I would have bisected.
> 
> I also have an apitrace for the issue. I admit I haven't tested it on any
> proprietary drivers...

Running it on proprietary drivers on Linux would probably be useful if you have easy access to it.

> https://drive.google.com/file/d/0BwgPzH1WFyIuUEVLQ0NtVGlOSVU/view?usp=sharing
> 
> (sorry, around 233 MiB compressed... it also hit an apitrace trimming bug so
> I could not trim it.)
> 
> See around frame 500 for the issue.
> 
> I admit I have not tested this trace on any of the proprietary drivers.
> However I've heard the game renders correctly on those.
> 
> This is what frame 500 looks like for me:
> http://sliedes.kapsi.fi/mesa/civbe/frame500.png
> 
> This is what the same map looks like on Windows, and I'd presume it looks
> close to similar on the proprietary drivers on Linux:
> http://sliedes.kapsi.fi/mesa/civbe/windows1.jpg

That certainly helps us see what the bug is.  Unfortunately, it working on Windows isn't any sort of indication that the game is doing things correctly as windows is probably using DX10 or DX11 not opengl.

Thanks for the added info.

(In reply to Jason Ekstrand from comment #7)
> Running it on proprietary drivers on Linux would probably be useful if you
> have easy access to it.

Access, yes, but easy, not sure. I'll try to find a way, perhaps a live system on a USB stick with the proprietary drivers or some such.

I actually tried to install them before adding this info, but gave up when it would have required me to downgrade my kernel, or at least patch the drivers.

Ok, interesting results. I managed to get an apitrace from an fglrx-enabled machine. From it I suspect that what's missing is at least something that CivBE uses to color the terrain. Perhaps that being missing makes it misbehave in other ways, causing the black patches?

The captured trace plays on mesa, but the texture looks different. Still, the black patches themselves are not present when the captured trace is replayed on mesa. Frame 205 on fglrx:

http://sliedes.kapsi.fi/mesa/civbe/CivBE-fglrx-frame-205.png

Same frame, replayed on mesa from the trace captured on fglrx:

http://sliedes.kapsi.fi/mesa/civbe/CivBE-frame-205-cap-fglrx-rep-free.png

You can get the trace (CivBE-fglrx.trace.lz) here:

https://drive.google.com/file/d/0BwgPzH1WFyIuR3pZdXE3SHJRaHc/view?usp=sharing

(In reply to Sami Liedes from comment #9)
> Ok, interesting results. I managed to get an apitrace from an fglrx-enabled
> machine. From it I suspect that what's missing is at least something that
> CivBE uses to color the terrain. Perhaps that being missing makes it
> misbehave in other ways, causing the black patches?
> 
> The captured trace plays on mesa, but the texture looks different. Still,
> the black patches themselves are not present when the captured trace is
> replayed on mesa. Frame 205 on fglrx:
> 
> http://sliedes.kapsi.fi/mesa/civbe/CivBE-fglrx-frame-205.png
> 
> Same frame, replayed on mesa from the trace captured on fglrx:
> 
> http://sliedes.kapsi.fi/mesa/civbe/CivBE-frame-205-cap-fglrx-rep-free.png
> 
> You can get the trace (CivBE-fglrx.trace.lz) here:
> 
> https://drive.google.com/file/d/0BwgPzH1WFyIuR3pZdXE3SHJRaHc/view?usp=sharing

With Intel (Haswelldesktop) the colors are correct in this trace (using Mesa git at commit 50e9fa2).

(In reply to Tapani Pälli from comment #10)
> (In reply to Sami Liedes from comment #9)
> > Ok, interesting results. I managed to get an apitrace from an fglrx-enabled
> > machine. From it I suspect that what's missing is at least something that
> > CivBE uses to color the terrain. Perhaps that being missing makes it
> > misbehave in other ways, causing the black patches?
> > 
> > The captured trace plays on mesa, but the texture looks different. Still,
> > the black patches themselves are not present when the captured trace is
> > replayed on mesa. Frame 205 on fglrx:
> > 
> > http://sliedes.kapsi.fi/mesa/civbe/CivBE-fglrx-frame-205.png
> > 
> > Same frame, replayed on mesa from the trace captured on fglrx:
> > 
> > http://sliedes.kapsi.fi/mesa/civbe/CivBE-frame-205-cap-fglrx-rep-free.png
> > 
> > You can get the trace (CivBE-fglrx.trace.lz) here:
> > 
> > https://drive.google.com/file/d/0BwgPzH1WFyIuR3pZdXE3SHJRaHc/view?usp=sharing
> 
> With Intel (Haswelldesktop) the colors are correct in this trace (using Mesa
> git at commit 50e9fa2).

I get the same bad colors with nouveau (GF108/nvc1). Probably some form of gallium fail... smells like a sRGB issue.

The 'terrain section not rendered' does not feel like regression, I can reproduce them with trace (comment #6) with Mesa 10.3.7 on Haswell.

(In reply to Ilia Mirkin from comment #11)
> (In reply to Tapani Pälli from comment #10)
> > (In reply to Sami Liedes from comment #9)
> > > Ok, interesting results. I managed to get an apitrace from an fglrx-enabled
> > > machine. From it I suspect that what's missing is at least something that
> > > CivBE uses to color the terrain. Perhaps that being missing makes it
> > > misbehave in other ways, causing the black patches?
> > > 
> > > The captured trace plays on mesa, but the texture looks different. Still,
> > > the black patches themselves are not present when the captured trace is
> > > replayed on mesa. Frame 205 on fglrx:
> > > 
> > > http://sliedes.kapsi.fi/mesa/civbe/CivBE-fglrx-frame-205.png
> > > 
> > > Same frame, replayed on mesa from the trace captured on fglrx:
> > > 
> > > http://sliedes.kapsi.fi/mesa/civbe/CivBE-frame-205-cap-fglrx-rep-free.png
> > > 
> > > You can get the trace (CivBE-fglrx.trace.lz) here:
> > > 
> > > https://drive.google.com/file/d/0BwgPzH1WFyIuR3pZdXE3SHJRaHc/view?usp=sharing
> > 
> > With Intel (Haswelldesktop) the colors are correct in this trace (using Mesa
> > git at commit 50e9fa2).
> 
> I get the same bad colors with nouveau (GF108/nvc1). Probably some form of
> gallium fail... smells like a sRGB issue.

The problem is that the green channel is replicated in the blue channel.

I grepped the game executable for any of the 159 extensions which are either available in Mesa but not in fglrx or the other way round, since it's obvious something (maybe the presence or lack of an extension?) makes CivBE behave different on fglrx and mesa.

Not sure how much this helps narrow things down, but here's a list of the "interesting" (different availability on the two drivers) extensions mentioned in the executable. I think next I'm going to try and disable stuff selectively, or perhaps make mesa advertise some extension it doesn't have, to see how that affects the game.

Available in mesa, but not in fglrx:

GLX_EXT_create_context_es2_profile
GL_EXT_stencil_two_side
GL_NV_texture_rectangle

Available in fglrx, but not in mesa:

GLX_EXT_swap_control
GL_ARB_geometry_shader4
GL_ARB_gpu_shader5
GL_ARB_imaging
GL_EXT_bindable_uniform
GL_EXT_geometry_shader4
GL_EXT_gpu_shader4
GL_NV_half_float

If you want to temporarily disable an extension in mesa:

export MESA_EXTENSION_OVERRIDE=-GL_NV_texture_rectangle

for example.  Note the leading "-" which means 'turn off this extension'.

For the firegl driver, you could use apitrace with a gltrace.conf file to selectively disable extensions.

I think this might be related to the color rendering weirdness: On fglrx, CivBE uses the GL_NV_half_float extension, which is not available on Mesa. Looking at interesting words or enums that are present in one of the traces but not the other (after apitrace dump):

* The fglrx dump mentions GL_DEPTH, GL_DEPTH_COMPONENT, GL_DEPTH_COMPONENT16, GL_R16F, GL_RG, GL_RG16F, glColorMaski, while running under mesa does not.

  * I believe the pixel formats here are probably those half floats, and if that's unsupported by mesa, then it's no big wonder the color channels are off?

* The mesa dump mentions nan in glUniform4fv calls. That cannot be good? :P

I noticed that the game works perfectly for me on Intel HD Graphics 5500 on a Debian unstable with mesa from Debian unstable (though I think Xorg from experimental). Loading the same game on Radeon on a different computer shows the black patches.

So, I'm going to try with software rendering on the Intel machine once I find some time to see if there's a difference (since the black patches are visible using swrast on the Radeon machine).

I'm not seeing this anymore on mesa/llvm git from today either on Radeon R9 270 or swrast.

Terrain works on "minimum" for me with R600 (6850) with latest git, but not on the other settings.

Hmm, true, on higher settings the terrain is very dark or black. Might be the same or a different bug.

I wonder how much insight it would provide if I bisected to see what fixed this on minimum settings...

Ok, I bisected this because I was curious. The commit that fixed the black patches on minimum terrain setting was:

commit 2b5355c8ab383d86bb6332dd29c417a6a1bc52bd
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed May 6 23:29:33 2015 -0400

    st/mesa: make sure to create a "clean" bool when doing i2b
    
    i2b has to work for all integers, not just 1. INEG would not necessarily
    result with all bits set, which is something that other operations can
    rely on by e.g. using AND (or INEG for b2i).
    
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>
    Reviewed-by: Roland Scheidegger <sroland@vmware.com>
    Cc: mesa-stable@lists.freedesktop.org

Hi,

I'm not "git aware", so I don't know how to check if this commit (2b5355c8ab383d86bb6332dd29c417a6a1bc52bd) has been done before the mesa-10.6 branch or not.
Can someone check (or even better explain me how to check) ?

Regards,

(In reply to Jérémy Viès from comment #22)
> Hi,
> 
> I'm not "git aware", so I don't know how to check if this commit
> (2b5355c8ab383d86bb6332dd29c417a6a1bc52bd) has been done before the
> mesa-10.6 branch or not.
> Can someone check (or even better explain me how to check) ?
> 
> Regards,

That commit is now part of Mesa 10.6 and 10.5.x.

This is working well for me now all the way up to Ultra on Fiji RadeonSI with latest git + llvm 3.8.

Same for me on R290