Bug 89018 - Civilization: Beyond Earth terrain section not rendered
Summary: Civilization: Beyond Earth terrain section not rendered
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-07 00:24 UTC by Md Imam Hossain
Modified: 2015-12-22 11:42 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Md Imam Hossain 2015-02-07 00:24:41 UTC
tested this on Intel Haswell HD Graphics 4600 and Intel Bay Trail Graphics,

I have made a video of the problem

https://www.youtube.com/watch?v=2EYiUozgveM

some terrain sections rendered as black regradless of in game graphics settings from low to high

System:

Kubuntu 14.10
Linux kernel 3.16.0-30-generic and 3.18.5-031805-lowlatency
Mesa 10.5.0-devel (git-6094619 2015-01-31 utopic-oibaf-ppa)

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

X.Org X Server 1.16.0
Comment 1 Md Imam Hossain 2015-02-08 11:54:24 UTC
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.
Comment 2 Ian Romanick 2015-02-11 22:17:55 UTC
Is it possible for you to bisect to find where the problem was introduced?
Comment 3 Md Imam Hossain 2015-02-12 01:26:52 UTC
How can I bisect?
Comment 4 Md Imam Hossain 2015-02-12 01:29:23 UTC
or maybe we just close this bug and wait for next stable version which may will fix the problem.
Comment 5 Ian Romanick 2015-02-26 16:04:06 UTC
(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.
Comment 6 Sami Liedes 2015-04-11 22:31:48 UTC
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
Comment 7 Jason Ekstrand 2015-04-11 22:45:12 UTC
(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.
Comment 8 Sami Liedes 2015-04-12 12:14:21 UTC
(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.
Comment 9 Sami Liedes 2015-04-12 21:53:45 UTC
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
Comment 10 Tapani Pälli 2015-04-13 05:37:56 UTC
(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).
Comment 11 Ilia Mirkin 2015-04-13 05:54:10 UTC
(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.
Comment 12 Tapani Pälli 2015-04-13 06:25:38 UTC
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.
Comment 13 Fredrik Höglund 2015-04-13 11:37:03 UTC
(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.
Comment 14 Sami Liedes 2015-04-13 20:20:59 UTC
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
Comment 15 Brian Paul 2015-04-13 20:26:11 UTC
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.
Comment 16 Sami Liedes 2015-04-13 21:32:20 UTC
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
Comment 17 Sami Liedes 2015-06-01 21:50:04 UTC
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).
Comment 18 Sami Liedes 2015-06-06 23:39:17 UTC
I'm not seeing this anymore on mesa/llvm git from today either on Radeon R9 270 or swrast.
Comment 19 Ernst Sjöstrand 2015-06-07 15:27:21 UTC
Terrain works on "minimum" for me with R600 (6850) with latest git, but not on the other settings.
Comment 20 Sami Liedes 2015-06-07 18:04:34 UTC
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...
Comment 21 Sami Liedes 2015-06-08 12:37:07 UTC
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
Comment 22 Jérémy Viès 2015-06-08 13:01:32 UTC
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,
Comment 23 Marek Olšák 2015-06-08 14:39:43 UTC
(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.
Comment 24 Ernst Sjöstrand 2015-12-22 07:27:28 UTC
This is working well for me now all the way up to Ultra on Fiji RadeonSI with latest git + llvm 3.8.
Comment 25 Peter Asplund 2015-12-22 11:42:50 UTC
Same for me on R290


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.