Bug detailed description:
It’s not a regression, firstly test ogl-samples.
- build: https://github.com/g-truc/ogl-samples
Output is black, broken line at "horizon", when there should be none. Please see error.png attached.
Created attachment 96096 [details]
render error png for gl-320-fbo-depth-multisample
The test renders a polygon tilted in the Zaxis to a FBO with a multisampled texture attached to its depth component. Then renders to the main framebuffer and uses a shader to map the recorder depth info to the frame buffer with a gray scale (the darker the color the lower the depth value, where black should be the near plane and white the far plane).
This is the fragment shader used by the test to map depth values to colors on
#version 150 core
uniform sampler2DMS Diffuse;
in vec4 gl_FragCoord;
out vec4 Color;
float LinearizeDepth(float Depth)
float n = 0.1; // camera z near
float f = 8.0; // camera z far
return (2.0 * n) / (f + n - Depth * (f - n));
float Depth = texelFetch(Diffuse, ivec2(gl_FragCoord.xy), 0).r;
for(int i = 1; i < 4; ++i)
Depth = min(Depth, texelFetch(Diffuse, ivec2(gl_FragCoord.xy), i).r);
float LinearDepth = LinearizeDepth(Depth);
Color = vec4(LinearDepth, LinearDepth, LinearDepth, 1.0);
Using max() instead of min() to select the depth sample to use for color mapping gives the expected result so I guess what is going on here is that at least one of the depth components for the furthest end of the polygon is 0 (or close to 0), which is bogus.
One more piece of information: besides the black line issue, there seems to be aso a visible loss of precision as we get closer to the far clipping plane (set at 8.0). This is represented in the image by patches of the same horizontal line with colored with different shades of gray which become more prominent the closer we are to the far plane (towards the black line).
This second issue happens when we use the max() function to select the sample to use for coloring too.
The program produces the expected result if run with 'hiz=false'. So, this sounds like a HiZ bug.
I have been taking a look to this one recently. Although I still didn't find the real cause, just wanted to mention that this bug is not present on Broadwell (gen8).
Ok, so after some time checking this, this is what I found.
I was been looking to the public PRM and the code, and I didn't find anything wrong.
So then I moved to see what piglit was reporting on this case. Although all the hiz tests are properly passing on HSW, the test for this case (depth multisample) on tests/spec/arb_texture_multisample is failing. If someone are interested to run it:
./bin/arb_texture_multisample-sample-depth -auto -fbo
Worth to note that is the only test of that spec failing on HSW.
Taking a look to the commit message of that test:
Author: Chris Forbes <firstname.lastname@example.org>
Date: Sat Feb 8 16:06:41 2014 +1300
arb_texture_multisample: add test for sampling from depth
This demonstrates an i965 bug, where hiz resolves for MSAA surfaces
don't work (on BLORP platforms).
Signed-off-by: Chris Forbes <email@example.com>
Reviewed-by: Glenn Kennard <firstname.lastname@example.org>
The commit message seems to suggest that this is a hw limitation. In any case it is not 100% explicit (other option would be that it is mentioning a bug on the driver). Will try to ask on IRC about that.
@aphinheiro: After you signed off, chrisf came around. He said he sent a patch to fix the problem but there were some things which made it stall:
(In reply to Ben Widawsky from comment #7)
> @aphinheiro: After you signed off, chrisf came around. He said he sent a
> patch to fix the problem but there were some things which made it stall:
Thanks for the pointer. That patch fixes this bug.
Just to try to get the review process resumed, I have just made the update suggested by Chad Versace on that thread:
Made a piglit run just in case, and showed no regressions (and obviously, the fix of arb_texture_multisample-sample-depth)
(In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #8)
> (In reply to Ben Widawsky from comment #7)
> > @aphinheiro: After you signed off, chrisf came around. He said he sent a
> > patch to fix the problem but there were some things which made it stall:
> > http://patchwork.freedesktop.org/patch/37037/
> Thanks for the pointer. That patch fixes this bug.
> Just to try to get the review process resumed, I have just made the update
> suggested by Chad Versace on that thread:
> Made a piglit run just in case, and showed no regressions (and obviously,
> the fix of arb_texture_multisample-sample-depth)
That patch got two reviews, so I just pushed it:
That fixes the bug.
Thanks everybody involved here.