Bug 24436

Summary: [swrast] piglit depth-tex-compare fails
Product: Mesa Reporter: Vinson Lee <vlee>
Component: Drivers/DRI/swrastAssignee: Brian Paul <brianp>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: brian.paul, eric, idr, jian.j.zhao
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: depth-tex-compare.png
proposed patch to depth-tex-compare.c

Description Vinson Lee 2009-10-09 18:26:26 UTC
Created attachment 30239 [details]
depth-tex-compare.png

System environment:
-- chipset: GM45
-- system architecture: i686
-- xserver-xorg-video-intel: 2:2.9.0-1ubuntu1
-- xserver-common: 2:1.6.3-1ubuntu7
-- mesa: db828ed7589d0a5687386c4b4268b4e7ff78c866 (master)
-- libdrm: 2.4.15
-- kernel version: 2.6.31-13-generic
-- Linux distribution: Ubuntu 9.10
-- Machine model: Dell Latitude E6400

Run piglit test depth-tex-compare.

$ ./bin/depth-tex-compare 
Probe at (165,250)
  Expected: 1.000000 1.000000 1.000000
  Observed: 1.000000 0.000000 1.000000
 Left to Right: ALPHA, LUMINANCE, INTENSITY
 Top to Bottom: LESS, LEQUAL, GREATER, GEQUAL, ALWAYS, NEVER, NOTEQUAL, EQUAL
Comment 1 Gordon Jin 2009-10-09 18:44:02 UTC
I confirm this failure in Q3 release.
Comment 2 Ian Romanick 2009-11-09 12:32:31 UTC
I get the same behavior on 965 as on Nvidia hardware with their closed-source driver.  I'm inclined to say that 965 is correct but the test and software Mesa are wrong.  It seems odd that the GL_LESS and GL_LEQUAL rows are expected to be the same.  Ditto for GL_GREATER and GL_GEQUAL.

Opinions?
Comment 3 Ian Romanick 2009-11-12 15:22:39 UTC
I have modified the test to expect the results produced on every single piece of hardware I could find.  Software Mesa is the odd man out.
Comment 4 Brian Paul 2009-11-16 09:07:10 UTC
This is pretty hard/impossible to fix.

As the R coordinate is interpolated across the triangles, the interpolation would have to _exactly_ produce R=0.5 for the middle pixel in order to satisfy the <= inequality test.  That's not happening in Mesa.  The closest we get is R=0.52.

It looks the hardware you've tested does produce R=0.5 exactly.

Perhaps Mesa's interpolation or point sampling is off a little bit somewhere, but I'm not inclined to spend a bunch of time on this or changing a bunch of code in order to fix this corner case.

I'd rather fix the piglit test.  We could add a "don't care" probe value to skip these corner cases, and then add a new test with r0=r1=0.5 which should guarantee hitting the R=0.5 case.  I'll take a crack at that.

Comment 5 Brian Paul 2009-11-16 09:30:47 UTC
Created attachment 31233 [details] [review]
proposed patch to depth-tex-compare.c

Here's a patch for depth-tex-compare.c that adds don't-care values for the R=0.5 cases that are hard to exactly hit with Mesa swrast.  It also adds additional tests for the GL_GEQUAL, GL_LEQUAL cases with R=0.5 to make sure we hit those cases in a more reliable manner.
Comment 6 Marek Olšák 2011-03-01 19:14:47 UTC
(In reply to comment #5)
> Created an attachment (id=31233) [details]
> proposed patch to depth-tex-compare.c
> 
> Here's a patch for depth-tex-compare.c that adds don't-care values for the
> R=0.5 cases that are hard to exactly hit with Mesa swrast.  It also adds
> additional tests for the GL_GEQUAL, GL_LEQUAL cases with R=0.5 to make sure we
> hit those cases in a more reliable manner.

The patch no longer applies.

Anyway I think it's useful to make the test less pedantic. A test that *cannot* pass on most drivers is useless.
Comment 7 GitLab Migration User 2019-09-18 18:44:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/293.

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.