Bug 43520 - CoreBreach: Static lighting broken in Mesa 7.11
Summary: CoreBreach: Static lighting broken in Mesa 7.11
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 7.11
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2011-12-04 11:56 UTC by Sven Arvidsson
Modified: 2013-02-17 17:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Screenshot of bug (105.38 KB, image/jpeg)
2011-12-04 11:56 UTC, Sven Arvidsson

Description Sven Arvidsson 2011-12-04 11:56:19 UTC
Created attachment 54112 [details]
Screenshot of bug

Static lightning is broken in the game CoreBreach. This happens with all the drivers I have tried, so it's probably a general Mesa problem.

This is not a problem on git master. I bisected to find the commit which fixed this problem, hoping it could be cherry picked for the next stable release:

commit 719909698c67c287a393d2380278e7b7495ae018
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Tue Oct 18 16:01:49 2011 -0700

    mesa: Rewrite the way uniforms are tracked and handled
Considering the size of the change it seems unlikely to be suitable for this. Maybe someone could have a look at this and see if a smaller fix is possible for 7.11?

CoreBreach is so far only available as beta for Linux:
Comment 1 corecode 2011-12-06 12:05:39 UTC
hello, i'm the developer of the game in question.

i've had a look at this problem to see if there is an easy workaround - however even simplifying the shader in question very much the problem persists and indeed is quite weird.

the problem occurs in the shader "phong_shadow.frag" with the codepath
#define SHADOW 1
and without LIGHT being defined.

the shader is long, i've made a simple version that still exhibits a problem on MESA:

uniform vec4    color;
uniform sampler2D texUnit;
varying vec2 texcoord;
varying vec3 position;
#ifdef SHADOW
uniform sampler2DShadow shadowMap[1];
varying vec4 shadowTexCoord[1];

float lookup(vec2 xy)
	return shadow2DProj(shadowMap[0], shadowTexCoord[0]).x ;
void main (void)
    vec4 tmp	 = texture2D(texUnit, texcoord);
#ifdef SHADOW
	float s = lookup(vec2(0.0,0.0));
	gl_FragColor = vec4(tmp.r,  tmp.g,   tmp.b, s); 
	gl_FragColor.a = 1.0; // gl_FragColor should be (tmp.rgb, 1.0), but its BLACK. when changing s to 1.0, the problem is gone.
	gl_FragColor = tmp;


this doesn't render the same thing as the normal shader, but still exhibits the basic problem.
in the SHADOW case we should be writing out the same thing to the color as in the other case, just the contents of the texture lookup. however, just the fact that the shadow texture lookup is performed and used (written to glFragColor.a, but overwritten just one line later) makes everything go nuts and the result is just BLACK for the parts of the geometry where SHADOW is defined.

the weird thing is that although the more complicated "dynamic" lighting shader (also phong_shadow.frag in the game, but with LIGHT defined to 1) also performs the shadow lookup, it isn't completely broken - and thats although the shader is a more complicated superset of the static lighting shader ... just weird.

there are 3 other problems with the game on MESA/ATI:
• with the normal (dynamic lighting) shader, the shadows don't show up, so there seems to be a general problem with shadow-maps that either manifests itself as the shadows just not showing up (dynamic light) or making everything black (static light)
• i can't seem to be able to create a context with FSAA enabled, the game automatically falls down to no-FSAA
• the "videowalls" are grey instead of containing a colorful animation. something in mesa seems to break the shader "plasma.frag"
Comment 2 corecode 2011-12-06 12:10:50 UTC
sorry not sure about the videowall (plasma.frag) thing anymore, there seems to be one "disabled" videowall in this racetrack ;-)
Comment 3 Ian Romanick 2013-01-30 01:38:47 UTC
So... this bug occurred on Mesa 7.11, but it does not occur on later versions?
Comment 4 Sven Arvidsson 2013-02-17 17:36:03 UTC
(In reply to comment #3)
> So... this bug occurred on Mesa 7.11, but it does not occur on later
> versions?

Correct, I doubt anyone has plans for more updates for 7.11 so let's just close this.

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.