System Environment: -------------------------- Mesa: (master)eaf9affa5ec9c5fd919e4207ab80b4677650ac67 Xserver:(master)xorg-server-1.15.99.901 Xf86_video_intel: Xf86_video_intel:(master)2.99.911 Kernel: (drm-intel-nightly)git-ec45c7 Bug detailed description: ---------------------------- It’s not a regression, firstly test ogl-samples. Pre-conditions: - build: https://github.com/g-truc/ogl-samples Test-case: gl-320-fbo-depth-multisample Expected outcome: ----------------- https://github.com/g-truc/ogl-samples/blob/master/data/templates/reference/gl-320-fbo-depth-multisample.png Actual outcome: ------------------------ 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 the screen: #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)); } void main() { 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: commit ecf0faa4d71c0e117569c6e0edfe57b2f8bbabf7 Author: Chris Forbes <chrisf@ijw.co.nz> 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 <chrisf@ijw.co.nz> Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com> 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: http://patchwork.freedesktop.org/patch/37037/
(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: http://patchwork.freedesktop.org/patch/72826/ 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: > > http://patchwork.freedesktop.org/patch/72826/ > > 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: https://cgit.freedesktop.org/mesa/mesa/commit/?id=43d23e879c797fa9b6cbbae15e101f2a3ee64751 That fixes the bug. Thanks everybody 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.