Bug 68365 - [SNB Bisected]Piglit spec_ARB_framebuffer_object_fbo-blit-stretch fail
Summary: [SNB Bisected]Piglit spec_ARB_framebuffer_object_fbo-blit-stretch fail
Status: REOPENED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium major
Assignee: Anuj Phogat
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-21 05:59 UTC by lu hua
Modified: 2015-06-16 08:08 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch (1.54 KB, patch)
2014-03-13 09:30 UTC, Samuel Iglesias Gonsálvez
Details | Splinter Review
glthing.txt (1.17 KB, text/plain)
2014-09-11 17:34 UTC, Kaveh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lu hua 2013-08-21 05:59:43 UTC
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
Comment 1 Samuel Iglesias Gonsálvez 2014-03-13 09:30:26 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
Comment 2 lu hua 2014-03-14 03:32:02 UTC
Fixed by the patch.
Comment 3 Neil Roberts 2014-06-20 16:11:11 UTC
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.
Comment 4 lu hua 2014-06-23 05:39:30 UTC
Works well on latest master branch.
Comment 5 Neil Roberts 2014-06-23 13:39:51 UTC
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
Comment 6 lu hua 2014-08-27 05:10:24 UTC
It also happens on Mesa 10.3 branch.
Comment 7 Ian Romanick 2014-09-10 00:02:40 UTC
What is the current status of this?  Has the piglit patch landed?
Comment 8 lu hua 2014-09-10 05:20:36 UTC
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" }
Comment 9 Neil Roberts 2014-09-10 12:35:47 UTC
(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.
Comment 10 Kaveh 2014-09-11 17:34:08 UTC
Created attachment 106151 [details]
glthing.txt
Comment 11 Neil Roberts 2014-09-11 17:57:10 UTC
(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.
Comment 12 Neil Roberts 2014-10-30 17:50:17 UTC
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.
Comment 13 Kaveh 2014-10-30 18:01:54 UTC
Per Neil's argument, I'm lowering the priority of this bug.


bug/show.html.tmpl processed on Mar 30, 2017 at 04:44:21.
(provided by the Example extension).