Bug 28293 - [i915] oglc/pxconv-depth.c and pxtrans-depth.c failed on 945GM
Summary: [i915] oglc/pxconv-depth.c and pxtrans-depth.c failed on 945GM
Status: VERIFIED INVALID
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: git
Hardware: Other Linux (All)
: medium normal
Assignee: Eric Anholt
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-27 23:23 UTC by Shuang He
Modified: 2010-06-07 02:06 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shuang He 2010-05-27 23:23:06 UTC
System Environment:
--------------------------
Libdrm:         (master)fcf3e616eeeb289f96af1436d809f0a1a42bebb7
Mesa:           (master)ba404c8f2a7e7ae25cccb66bdf378b4106d2a4df
Xserver:                (master)531ff40301975519af7b20109c17d296312d3f2b
Xf86_video_intel:              
(master)03bbb4c896ef3cd275312b413a2c85d9f499c032
Kernel:       (for-linus)722154e4cacf015161efe60009ae9be23d492296

Bug detailed description:
-------------------------

oglc/pxconv-depth.c and pxtrans-depth.c failed on 945GM
This bug is for tracking residual issue from bug 23670.
This case once passed with following configuration:
Libdrm     (master)73b59c894380995a2889b98e79acadd2da0bb237
Mesa     (master)165e87c49180380b67b096211b4c5f9670e3020a
Xf86_video_intel     (master)5812531e08147576de776b2dd64e7f94c08eb851
Kernel     (drm-intel-next)dd64c8407d828796f638e40931f707ab96009c6e
Comment 1 Eric Anholt 2010-06-04 12:04:05 UTC
The problem is using a shader to do the depth drawpixels.  The test considers the tolerable error to be (1 / (1 << depthbits) + 1 / (1 << formatbits)).  But when we sample the texture, the value is stored in a shader floating point reg, which only has about 12 bits of precision.

The GL 3.2 compat spec (also 2.1 spec) is saying that we need to have precision to about 1/10^5 unless otherwise specified for an operation (2.1.1 Floating-Point Computation).  I don't see other specification for precision on pixel transfer ops.  Guidance in the ARB_fragment_program spec seems to reinforce the "if it looks good, it is good" rule, though, and deemphasize 1/10^5 specifically.  If we tweak the test's tolerance to also include the 1/10^5 it still fails, but if the tolerance is bumped to include 1/10^3 for our GPU's fragment reg precision, it passes.

My conclusion is that the GL implementation is doing fine, until someone shows real-world rendering where this DrawPixels precision fudging is bad (and given that we have the same precision fudging *everywhere* in our fragment pipeline, this doesn't seem likely).  These two tests should add 1/1000.0 to test->tolerance[0] (and pxstore-depth.c, though it's not a complete solution to that one).
Comment 2 Shuang He 2010-06-07 02:06:41 UTC
So, do you suggest us to give these two test case bigger tollerance to let them pass? by doing this we could track if they're getting worse intead of always showing a failure


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.