| Summary: | [SNB Bisected]Piglit spec_ARB_framebuffer_object_fbo-blit-stretch fail | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | lu hua <huax.lu> |
| Component: | Drivers/DRI/i965 | Assignee: | Anuj Phogat <anuj.phogat> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | major | ||
| Priority: | medium | CC: | christophe.prigent, idr, nroberts |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Patch
glthing.txt |
||
|
Description
lu hua
2013-08-21 05:59:43 UTC
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.