System Environment: -------------------------- Arch: i386 Platform: Sandybridge Libdrm: (master)libdrm-2.4.46-26-g3c967e715528ee52195c178c4d09d03b643f0c06 Mesa: (master)ce87c51e9ad131670fd8e4dcc0d023d0b057612b Xserver: (master)xorg-server-1.14.99.1-178-gfe7463b8ce0de301c2f82b108c93963424f77219 Xf86_video_intel:(master)2.21.14-55-ged40a7c3de3bbb178278c05907e59239712b98b6 Cairo: (master)95f320e3f26b2a1552a53ebad14dd5086ccf0c60 Libva: (staging)d540f278465929f3a31030e3f18fdc95ceecffa5 Libva_intel_driver:(staging)42bb613e72d235bcbe141c906dec9431e4c29661 Kernel: (drm-intel-nightly) 9bec622d78f6289023c9f405cf2eadbd25747792 Bug detailed description: ----------------------------- It fails on sandybridge with mesa master branch, and works well on 9.2 branch. Bisect shows: 079bdba05f870807d3ed77fa3093cdb7727aa2fd is the first bad commit. commit 079bdba05f870807d3ed77fa3093cdb7727aa2fd Author: Anuj Phogat <anuj.phogat@gmail.com> AuthorDate: Wed Jul 17 18:38:50 2013 -0700 Commit: Anuj Phogat <anuj.phogat@gmail.com> CommitDate: Fri Aug 16 09:46:15 2013 -0700 i965/blorp: Add support for single sample scaled blit with bilinear filter Currently single sample scaled blits with GL_LINEAR filter falls back to meta path. Patch removes this limitation in BLORP engine and implements single sample scaled blit with bilinear filter. No piglit, gles3 regressions are observed with this patch on Ivybridge. V2: Use "sample" message to utilize the linear filtering functionality built in to hardware. V3: Define a bool variable (bilinear_filter) to handle the conditions for GL_LINEAR blits. Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Paul Berry <stereotype441@gmail.com> output: 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(36, 34) nearest 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(36, 34) linear 45x79 (30, 44)-(13, 33) => 200x150 (36, 34)-(19, 23) flip_src_x flip_src_y flip_dst_x flip_dst_y nearest 45x79 (30, 44)-(13, 33) => 200x150 (36, 34)-(19, 23) flip_src_x flip_src_y flip_dst_x flip_dst_y linear 45x79 (30, 33)-(13, 44) => 200x150 (19, 34)-(36, 23) flip_src_x flip_dst_y nearest 45x79 (30, 33)-(13, 44) => 200x150 (19, 34)-(36, 23) flip_src_x flip_dst_y linear 45x79 (13, 44)-(30, 33) => 200x150 (36, 23)-(19, 34) flip_src_y flip_dst_x nearest 45x79 (13, 44)-(30, 33) => 200x150 (36, 23)-(19, 34) flip_src_y flip_dst_x linear 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y linear 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y linear 45x79 (13, 33)-(14, 34) => 200x150 (19, 23)-(26, 30) stretch_x stretch_y nearest 45x79 (13, 33)-(14, 34) => 200x150 (19, 23)-(26, 30) stretch_x stretch_y linear 45x79 (13, 33)-(30, 44) => 200x150 (-8, -5)-(9, 6) clamp_dst_x clamp_dst_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (-8, -5)-(9, 6) clamp_dst_x clamp_dst_y linear 45x79 (13, 33)-(30, 44) => 200x150 (192, 145)-(209, 156) clamp_dst_x clamp_dst_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (192, 145)-(209, 156) clamp_dst_x clamp_dst_y linear 45x79 (-8, -5)-(9, 6) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y nearest 45x79 (-8, -5)-(9, 6) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y linear 45x79 (37, 74)-(54, 85) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y nearest 45x79 (37, 74)-(54, 85) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y linear 45x79 (0, 0)-(45, 79) => 200x150 (0, 0)-(200, 150) stretch_x stretch_y nearest 45x79 (0, 0)-(45, 79) => 200x150 (0, 0)-(200, 150) stretch_x stretch_y linear Probe at (97,0) Expected: 0.562500 0.437500 0.000000 Observed: 0.576471 0.423529 0.000000 PIGLIT: {'result': 'fail' } Reproduce steps: ---------------------------- 1. xinit 2. ./bin/fbo-blit-stretch -auto
Created attachment 95701 [details] [review] Patch I can reproduce this issue with my SandyBridge graphics card. I have checked the code path for the glBlitFramebuffer() call until the call to gen6_blorp_exec() on gen6_blorp.cpp. I have not seen any remarkable parameter that could make this test to fail only on SandyBridge but I don't have a lot of experience dealing with i965 driver. So I send this patch that disables this code path and fallbacks to other blit paths only for SNB. Tested this patch on top of: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.2.0-devel (git-952fda4) OpenGL core profile shading language version string: 1.40
Fixed by the patch.
The test is now passing in git master since this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=61e264f4fcdba3623781a0a33942 mesa: Prefer non-swizzled formats for most sized internalformats However it looks that is just because the texture is now created in RGBA format whereas the framebuffer is in BGRA so the blitter path can't be used and it falls back to the meta implementation. This is happening on Haswell too. It might be good to modify the test to blit between two textures so that it will be more likely to have the same format in both framebuffers.
Works well on latest master branch.
I don't think we should close this bug because the underlying problem hasn't been fixed. The commit mentioned in comment 3 just hides the problem and doesn't fix it. I've posted a patch to the piglit mailing list to make the test show the problem again even with that commit here: http://lists.freedesktop.org/archives/piglit/2014-June/011399.html
It also happens on Mesa 10.3 branch.
What is the current status of this? Has the piglit patch landed?
Test on latest master branch: 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(36, 34) nearest 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(36, 34) linear 45x79 (30, 44)-(13, 33) => 200x150 (36, 34)-(19, 23) flip_src_x flip_src_y flip_dst_x flip_dst_y nearest 45x79 (30, 44)-(13, 33) => 200x150 (36, 34)-(19, 23) flip_src_x flip_src_y flip_dst_x flip_dst_y linear 45x79 (30, 33)-(13, 44) => 200x150 (19, 34)-(36, 23) flip_src_x flip_dst_y nearest 45x79 (30, 33)-(13, 44) => 200x150 (19, 34)-(36, 23) flip_src_x flip_dst_y linear 45x79 (13, 44)-(30, 33) => 200x150 (36, 23)-(19, 34) flip_src_y flip_dst_x nearest 45x79 (13, 44)-(30, 33) => 200x150 (36, 23)-(19, 34) flip_src_y flip_dst_x linear 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y linear 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (19, 23)-(87, 67) stretch_x stretch_y linear 45x79 (13, 33)-(14, 34) => 200x150 (19, 23)-(26, 30) stretch_x stretch_y nearest 45x79 (13, 33)-(14, 34) => 200x150 (19, 23)-(26, 30) stretch_x stretch_y linear 45x79 (13, 33)-(30, 44) => 200x150 (-8, -5)-(9, 6) clamp_dst_x clamp_dst_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (-8, -5)-(9, 6) clamp_dst_x clamp_dst_y linear 45x79 (13, 33)-(30, 44) => 200x150 (192, 145)-(209, 156) clamp_dst_x clamp_dst_y nearest 45x79 (13, 33)-(30, 44) => 200x150 (192, 145)-(209, 156) clamp_dst_x clamp_dst_y linear 45x79 (-8, -5)-(9, 6) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y nearest 45x79 (-8, -5)-(9, 6) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y linear 45x79 (37, 74)-(54, 85) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y nearest 45x79 (37, 74)-(54, 85) => 200x150 (19, 23)-(36, 34) clamp_src_x clamp_src_y linear 45x79 (0, 0)-(45, 79) => 200x150 (0, 0)-(200, 150) stretch_x stretch_y nearest 45x79 (0, 0)-(45, 79) => 200x150 (0, 0)-(200, 150) stretch_x stretch_y linear Probe at (97,0) Expected: 0.562500 0.437500 0.000000 Observed: 0.576471 0.423529 0.000000 PIGLIT: {"result": "fail" }
(In reply to comment #7) > What is the current status of this? Has the piglit patch landed? I think it's probably not worth landing the piglit patch because the original test now fails again since this commit in Mesa: http://cgit.freedesktop.org/mesa/mesa/commit/?id=5f11b10f2c6a7dc94b8abdbffb75 It would be good to get confirmation that the problem really is just that the linear filtering on Sandybridge isn't very accurate. If that is the case then I guess we should just increase the tolerance in the piglit test. It might be good to try it with the Windows driver. I don't have a Windows machine handy with Sandybridge but if anyone does I have a simple .exe test case ready here: http://busydoingnothing.co.uk/glthing.zip It is a slightly modified version of the test described here: http://lists.freedesktop.org/archives/mesa-dev/2014-June/062201.html It dumps the output to a file called glthing.txt. If anyone wants to run it and paste the output here that might help.
Created attachment 106151 [details] glthing.txt
(In reply to comment #10) Hrm, that's interesting. On the Windows driver it looks like the results are the same as what Mesa gets with normalized coordinates. Ie, it's still not entirely accurate but it would probably be enough to make the Piglit test pass. That implies we are doing something different which is maybe causing the texture coordinates to be slightly offset or something.
I think we can downgrade the priority of this bug because it's arguably not a regression. The underlying bug is that on Sandybridge linear filtering is slightly less accurate when using non-normalised coordinates instead of normalised coordinates and that has presumably always been the case. The patch that caused the regression just made glBlitFramebuffer use the blorp codepath and the blorp codepath always uses non-normalised coordinates. However you can replicate the actual bug even outside of glBlitFramebuffer just by using a rectangle texture for regular rendering. The difference between filtering with normalised and non-normalised coordinates is only slight so I don't think it will cause any noticeable difference for an application in practice.
Per Neil's argument, I'm lowering the priority of this bug.
Fixed by: commit 1b101ca809debb9b730d99b92e8f0153f08aeb57 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Jun 5 17:34:38 2017 -0700 blorp: Use normalized coordinates on Gen6 Apparently, the sampler has some sort of precision issues for non-normalized texture coordinates with linear filtering. This caused some small precision issues in scaled blits. Work around this by using normalized coordinates. There is some extra work necessary because Gen6 uses TEX (instead of TXF) for some multisample resolve blits. Fixes piglit.spec.arb_framebuffer_object.fbo-blit-stretch on SNB. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68365 Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
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.