Bug 76618 - [SNB, HSW] Gameplay-football graphics has wrong color (problem with pow)
Summary: [SNB, HSW] Gameplay-football graphics has wrong color (problem with pow)
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Matt Turner
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-26 06:39 UTC by Md Imam Hossain
Modified: 2019-09-25 18:50 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Rendering bug (1.31 MB, text/plain)
2014-03-26 06:39 UTC, Md Imam Hossain
Details
Correct Rendering (rendered with Gallium llvmpipe) (1.09 MB, image/png)
2014-03-26 06:40 UTC, Md Imam Hossain
Details
Incorrect Rendering (rendered with Mesa DRI Intel Sandybridge Mobile) (1.31 MB, image/png)
2014-03-26 06:42 UTC, Md Imam Hossain
Details
Modified Postprocess.frag file (5.60 KB, text/plain)
2014-03-28 14:44 UTC, Samuel Iglesias Gonsálvez
Details
SandyBridge no convolution, original pow() (1.28 MB, image/png)
2014-03-28 14:45 UTC, Samuel Iglesias Gonsálvez
Details
SandyBridge no convolution, my_pow() (1.15 MB, image/png)
2014-03-28 14:45 UTC, Samuel Iglesias Gonsálvez
Details
NVIDIA no convolution, original pow() (1.32 MB, image/png)
2014-03-28 14:46 UTC, Samuel Iglesias Gonsálvez
Details
NVIDIA no convolution, my_pow() (1.31 MB, image/png)
2014-03-28 14:46 UTC, Samuel Iglesias Gonsálvez
Details

Description Md Imam Hossain 2014-03-26 06:39:22 UTC
Created attachment 96398 [details]
Rendering bug

Gameplay Football

http://www.indiedb.com/games/gameplay-football
http://www.properlydecent.com/downloads/

uses GLSL 1.30, has wrong graphincs color with Intel Sandybridge chipset.

game renders fine with Gallium Software renderer when launched with

export LIBGL_ALWAYS_SOFTWARE=1

environment variable from the terminal.


System:

Ubuntu 13.10
linux 3.12.0-031200-generic
Mesa 10.2.0-devel (master branch)
xf86-video-intel 2.99.911
Intel Sandybridge Mobile (device id: 0116)
Intel GMA 4500MHD (device id: 2a42) with export MESA_GLSL_VERSION_OVERRIDE=130
Comment 1 Md Imam Hossain 2014-03-26 06:40:34 UTC
Created attachment 96399 [details]
Correct Rendering (rendered with Gallium llvmpipe)
Comment 2 Md Imam Hossain 2014-03-26 06:42:12 UTC
Created attachment 96400 [details]
Incorrect Rendering (rendered with Mesa DRI Intel Sandybridge Mobile)
Comment 3 Samuel Iglesias Gonsálvez 2014-03-28 14:43:06 UTC
I have tested this bug and reproduced successfully in my Sandybridge laptop with git master Mesa.

Debugging the shaders (which are placed in media/shaders/ folder of the game), I found that the issue is inside postprocess.frag which does these two things among others:

1) It uses a simplification for the convolution which produces errors on the output which could be due to rounding errors. It produces the random pixel noise that can be seen clearly in the pitch and in the shadows.

2) It does a gamma correction which produced the color errors in the bottom half of the screen (which seems to be the part not affected by the fog algorithm).

So I did some changes to postprocess.frag shader to figure out which is the source of the problem:

1) I disabled the convolution by substituting this line:

       vec3 fragColor = base * (1 - SSAO); // SSAO

by this line:
       vec3 fragColor = base;

So the pixel noise disappeared which, at the end, allowed me to focus only in the color issue.

2) I disabled the gamma correction and I saw a good output. As GammaCorrection() is calling to the pow() function, I created my own pow function (called my_pow()) in order to compare both outputs.
I also modified the gamma correction value to be 2.0 to simplify my_pow() function because GammaCorrection() would end up being a simple sqrt(color) when choosing this specific gamma value.

So I compared two different cases:

* No convolution with original GammaCorrection() (pow()), gamma = 2.0.
* No convolution with modified GammaCorrection() (my_pow()), gamma = 2.0.

I found that the second case shows a proper output (attached image) while the first case it is showing the same ugly color output.

Furthermore, I tested on a NVIDIA graphics card with nouveau driver (Mesa 10.1) with the original (untouched) game and the game with both modifications. In all cases the output is fine, indicating that its GLSL's pow() function is well implemented.

I'm going to attach several files:

* Sandybridge output of each test case: no convolution, with original pow() and with my_pow() call in GammaCorrection().
* NVIDIA output of each test case: no convolution. With original pow() and with my_pow() call in GammaCorrection().
* The postprocessing fragment shader file with my modifications if you want to play with it, reproduce the error and understand what it's happening.

In summary, it seems that the error is present in the implementation of the GLSL's pow() function for Intel graphics.

I hope this information could help someone to fix this error. If you need more information or you don't understand something, please tell me so.
Comment 4 Samuel Iglesias Gonsálvez 2014-03-28 14:44:17 UTC
Created attachment 96538 [details]
Modified Postprocess.frag file
Comment 5 Samuel Iglesias Gonsálvez 2014-03-28 14:45:02 UTC
Created attachment 96539 [details]
SandyBridge no convolution, original pow()
Comment 6 Samuel Iglesias Gonsálvez 2014-03-28 14:45:34 UTC
Created attachment 96540 [details]
SandyBridge no convolution, my_pow()
Comment 7 Samuel Iglesias Gonsálvez 2014-03-28 14:46:10 UTC
Created attachment 96541 [details]
NVIDIA no convolution, original pow()
Comment 8 Samuel Iglesias Gonsálvez 2014-03-28 14:46:45 UTC
Created attachment 96542 [details]
NVIDIA no convolution, my_pow()
Comment 9 Md Imam Hossain 2014-04-01 00:42:43 UTC
this bug also affects

Mesa DRI Intel(R) Haswell Desktop
Device id: 0412
Comment 10 GitLab Migration User 2019-09-25 18:50:58 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1425.


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.