Bug 68690

Summary: Dark screen in Europa Universalis IV on Intel, R600g and RadeonSI
Product: Mesa Reporter: Médéric Boquien <mboquien>
Component: glsl-compilerAssignee: Ian Romanick <idr>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium CC: commiethebeastie, excieve, felix.schwarz, j.suarez.agapito, nikoamia, pgriffais
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 77449    
Attachments: The image appears dark, showing the bug
Image showing what it looks like after having applied the workaround suggested by the developer
The image appears dark, showing the bug
Image showing the black lightning
Image showing the correct lightning

Description Médéric Boquien 2013-08-29 03:07:54 UTC
Created attachment 84820 [details]
The image appears dark, showing the bug

Hello,

In Europa Universalis IV, when using an Intel HD 3000 with Mesa 9.1 or 9.2, the screen get very dark. See attached image. This bug does not appear with the radeon driver. We suspect this is an Intel GLSL problem. The code triggering the bug is the following.

float GetShadowScaled( float fScaler, in float4 vBlurTexCoord, in sampler2DShadow ShadowSample )
{
        fScaler = saturate( fScaler );
        float vShadowValue = tex2Dproj( ShadowSample, vBlurTexCoord ).r;

        //Hide shadow after a certain distance
        vShadowValue += (1.0f-vFoWOpacity_Time.x);
        vShadowValue = saturate( vShadowValue );

        return ( 1.0f-fScaler ) + fScaler * vShadowValue;
}

At the suggestion of one of the game developers, replacing the return with "return 1.0f" solves the problem at the expense of some shadows. If it is any useful, the saturate function is defined this way:

float saturate( float x )
{
        return clamp( x, 0.0, 1.0 );
}

It is the first time I report a potential GLSL issue. Please let me know if there is anything else I could provide.

Thanks!

Médéric
Comment 1 Médéric Boquien 2013-08-29 03:09:34 UTC
Created attachment 84821 [details]
Image showing what it looks like after having applied the workaround suggested by the developer
Comment 2 Médéric Boquien 2013-08-29 03:12:36 UTC
Created attachment 84822 [details]
The image appears dark, showing the bug

Somehow the initial image was identified as text/plain.
Comment 3 Médéric Boquien 2013-08-29 04:24:49 UTC
I do not know why I said it works with the radeon driver. I actually do not know yet. I can provide that information in a week. Though it does work with the proprietary nvidia driver.
Comment 4 Ian Romanick 2013-08-29 14:53:27 UTC
Knowing whether or not it works with any other Mesa driver would help narrow down the source of the problem.

Is tex2Dproj an overload function for textureProj2D or shadowProj2D depending on the type of the sampler?
Comment 5 Médéric Boquien 2013-08-29 15:04:39 UTC
Hello,

It appears that tex2Dproj is defined this way:
#define tex2Dproj shadow2DProj

textureProj2D or texture2DProj do not appear to be used anywhere.

Thanks!
Comment 6 Médéric Boquien 2013-09-03 13:45:27 UTC
Hello,

I finally managed to test with the radeon driver. It exhibits the exact same problem as with the intel card, the image being very dark. I hope it helps.
Comment 7 Médéric Boquien 2013-09-05 19:27:21 UTC
Hello,

In case it is useful, here is the apitrace trace from the game start until experiencing the bug. http://medericboquien.eu/eu4.1.trace (400MB)

Thanks!
Comment 8 Artem Hluvchynskyi 2013-09-07 13:36:02 UTC
Just confirming I experience same issue with radeon on mesa 9.2. Provided workaround also helps.
Comment 9 José Suárez 2013-10-29 23:24:51 UTC
Well, I am using radeonsi (2GB Radeon HD 7870, mesa 10.0~git1310251530.980755, llvm 3.4~svn193504) on Kubuntu 13.10 64 bits and I am experiencing the same problem. In my case the image gets correctly lit if I scroll out.

I am attaching two screenshots that depict the bug when zoomed in and no bug when zoomed out a bit more than the first shot.

Please, tell me if I should open a bug report on the radeonsi driver.
Comment 10 José Suárez 2013-10-29 23:25:46 UTC
Created attachment 88324 [details]
Image showing the black lightning
Comment 11 José Suárez 2013-10-29 23:27:20 UTC
Created attachment 88325 [details]
Image showing the correct lightning

Note however, that from a certain zoom level the image changes and thus the reason why once you zoom out more the image shows with the correct lightning.
Comment 12 commiethebeastie 2013-11-02 11:55:27 UTC
This bug also applies to r600g.
Comment 13 commiethebeastie 2013-11-02 11:58:49 UTC
This bug also applies to r600g.
Comment 14 Nikolay Amiantov 2013-12-10 13:16:38 UTC
Confirmed on R600g, same situation as José's.
Comment 15 Felix Schwarz 2014-02-28 10:52:11 UTC
The problem is still present with the current Mesa 10.1rc2 (r600g).
Comment 16 José Suárez 2014-03-03 15:50:55 UTC
It's still there too with git 10.2 (radeonsi).
Comment 17 Pierre-Loup A. Griffais 2014-03-03 20:04:16 UTC
I'm also observing this issue on the Brix Haswell machines with 10.0.1. Ian, do you guys already have access to this title? Please have your staff drop me a line with their Steam account if not, I'd be glad to purchase licenses to help with this.
Comment 18 Chia-I Wu 2014-03-13 14:25:50 UTC
(In reply to comment #0)
[snip]
> float GetShadowScaled( float fScaler, in float4 vBlurTexCoord, in
> sampler2DShadow ShadowSample )
> {
>         fScaler = saturate( fScaler );
>         float vShadowValue = tex2Dproj( ShadowSample, vBlurTexCoord ).r;
> 
>         //Hide shadow after a certain distance
>         vShadowValue += (1.0f-vFoWOpacity_Time.x);
>         vShadowValue = saturate( vShadowValue );
> 
>         return ( 1.0f-fScaler ) + fScaler * vShadowValue;
> }
ShadowSample actually points to a texture of format GL_RGB, and GL_TEXTURE_COMPARE_MODE is GL_NONE.  It results in undefined behavior.

The correct fix is for the game to

  s/sampler2DShadow/sampler2D/
  s/tex2Dproj/texture2DProj/

on this function, and declare tex12 as sampler2D instead of sampler2DShadow in both VS and FS.
Comment 19 Pierre-Loup A. Griffais 2014-03-14 00:56:18 UTC
Médéric, do you already have a line of contact with the developer to relay that information or do you need help from our side?
Comment 20 Felix Schwarz 2014-03-14 07:56:33 UTC
(In reply to comment #19)
> Médéric, do you already have a line of contact with the developer to relay
> that information or do you need help from our side?

A Paradox developer is aware of comment 18 and agreed (on a quick glance) to the proposed solution.
Comment 21 Felix Schwarz 2014-05-29 14:09:48 UTC
fixed by Paradox Interactive with latest update to their game (Europa Universalis IV v1.6). A big thank you to all people involved here.

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.