Bug 94105 - Rendering artifacts shown on WebGL application "chaos to perfection"
Summary: Rendering artifacts shown on WebGL application "chaos to perfection"
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 11.1
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-12 04:07 UTC by Joon Jung
Modified: 2016-02-13 02:47 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
screenshot of some of the corruption (175.52 KB, image/jpeg)
2016-02-12 16:51 UTC, Ilia Mirkin
Details

Description Joon Jung 2016-02-12 04:07:01 UTC
Rendering corruptions are seen while running http://www.chaostoperfection.com/scenes.html?lang=en .

The corruption can be seen always by:

1. Go to http://www.chaostoperfection.com/scenes.html?lang=en
2. Select "all scenes" on the bottom of the main window
3. Select "The Hall of Mirrors" and various artifacts will be shown.

System environment:
      -- OS: Problems seen on ChromeOS and Ubuntu 14.04
      -- x86-64
      -- mesa: Problems seen on different versions of Mesa up to the latest
         (ex. Mesa 11.2.0-devel (git-d76bd85 2016-01-22 trusty-oibaf-ppa)
          or git://anongit.freedesktop.org/mesa/mesa master branch)
      -- Machine: On different Intel machines including SKL

The problem is happening from the following line in the fragment shader of the app, indicated by ==>:
==========================================================================
#ifdef GL_ES
precision highp float;
#endif
#define MAX_DIR_LIGHTS 0
#define MAX_POINT_LIGHTS 0

uniform mat4 viewMatrix;
uniform vec3 cameraPosition;
uniform float screenWidth;
uniform float screenHeight;
uniform float vingenettingOffset;
uniform float vingenettingDarkening;
uniform float colorOffset;
uniform float colorFactor;
uniform float sampleDistance;
uniform float colorBrightness;
uniform float waveFactor;
uniform vec3 colorA;
uniform sampler2D map;
varying vec2 vUv;
void main() {
vec4 color, org, tmp, add;
float sample_dist, f;
vec2 vin;
vec2 uv = vUv;
add += color = org = texture2D( map, uv );
vin = (uv - vec2(0.5)) * vec2( 1.55 /*vingenettingOffset * 2.0*/);
sample_dist =(dot( vin, vin ) * 2.0);
f = (waveFactor * 100.0 + sample_dist) * sampleDistance * 4.0;
vec2 sampleSize = vec2(  1.0 / screenWidth, 1.0 / screenHeight ) * vec2(f);
add += tmp = texture2D( map, uv + vec2(0.111964, 0.993712) * sampleSize);
if( tmp.g > color.g ) color = tmp;
add += tmp = texture2D( map, uv + vec2(0.846724, 0.532032) * sampleSize);
if( tmp.g > color.g ) color = tmp;
add += tmp = texture2D( map, uv + vec2(0.943883, -0.330279) * sampleSize);
if( tmp.g > color.g ) color = tmp;
add += tmp = texture2D( map, uv + vec2(0.330279, -0.943883) * sampleSize);
if( tmp.g > color.g ) color = tmp;
add += tmp = texture2D( map, uv + vec2(-0.532032, -0.846724) * sampleSize);
if( tmp.g > color.g ) color = tmp;
add += tmp = texture2D( map, uv + vec2(-0.993712, -0.111964) * sampleSize);
if( tmp.g > color.g ) color = tmp;
add += tmp = texture2D( map, uv + vec2(-0.707107, 0.707107) * sampleSize);
if( tmp.g > color.g ) color = tmp;
uv = (uv - vec2(0.5)) * vec2( vingenettingOffset );

==> color = color + (add / vec4(8.0) - color) * (vec4(1.0) - vec4(sample_dist * 0.5));

gl_FragColor = vec4( mix(color.rgb * color.rgb * vec3(colorOffset) + color.rgb, color.ggg * colorFactor - vec3( vingenettingDarkening ), vec3( dot( uv, uv ))), 1.0 );
gl_FragColor = vec4(1.0) - (vec4(1.0) - gl_FragColor) * (vec4(1.0) - gl_FragColor);
}
==============================================================================

Removing the corresponding "color" update clears the corruption. I hope Mesa shader experts can give some light on what could be causing the problem. The corruption is not seen on MS Windows.
Comment 1 Ilia Mirkin 2016-02-12 16:51:18 UTC
Created attachment 121718 [details]
screenshot of some of the corruption

Reproduced on HSW. The corruption is way worse on 11.1.1 than on master, but still present (see lower left corner).

There's a dynamic variability that's difficult to capture in a screenshot, but is clearly wrong too. This also happens on GK208 with nouveau (visually slightly different but still bad).
Comment 2 Neil Roberts 2016-02-12 19:33:00 UTC
I hacked up a little standalone version to make it easier to test:

https://github.com/bpeel/halls
Comment 3 Neil Roberts 2016-02-12 21:37:08 UTC
If I run it on the nvidia closed-source driver then it gives a warning that ‘add’ may be used uninitialised. Looking at it the shader is quite clearly broken so I think this isn't a real bug. If I hack the shader to initialise it to zero then it works. Maybe everything they tested it on just happen to initialise it to something consistent.
Comment 4 Joon Jung 2016-02-13 02:00:18 UTC
Thanks Roberts. Good catch.

I wonder if Mesa can give out some warnings for those uninitialized as well. Certainly there are many apps out there using uninitialized variables.
Comment 5 Kenneth Graunke 2016-02-13 02:47:15 UTC
Yep, that would certainly be nice.  I've filed bug 94129 as a feature request.


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.