[Bug 91114] ES3-CTS.gtf.GL3Tests.shadow.shadow_execution_vert fails

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jun 29 03:55:28 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=91114

--- Comment #15 from Iago Toral <itoral at igalia.com> ---
(In reply to Tapani Pälli from comment #14)
> (In reply to Iago Toral from comment #13)
> > (In reply to Iago Toral from comment #12)
> > > I don't see anything special in the generated IR. After my patch we change
> > > the way we compute the lod by subtracting 1 unit, but that is expected as
> > > per the commit log. The test itself does not seem to do weird things either
> > > after a quick glance at it.
> > > 
> > > I am wondering if the problem may spawn from rounding issues so that
> > > depending on the specific test we are doing sometimes we fall on the wrong
> > > side of the rounding. While I was working on deqp I noticed that the problem
> > > was that we were computing a wrong value of LOD in all the scenarios and
> > > verified that subtracting 1.0 from the computed LOD fixed the problem, but
> > > as I explain in the commit log, I am not sure why this is needed. That
> > > change seemed consistent with the way in which deqp computed the expected
> > > result for those tests but maybe we do not need to subtract 1.0 to get the
> > > lod we need, maybe the problem that deqp detected was a rounding issue and
> > > by removing 1.0 we just fell on the right side of the rounding for those
> > > tests. I have just checked that for piglit, it is enough if we subtract 0.51.
> > > 
> > > Tapani, could you replace my -1.0 addition by -0.51 and see if that fixes
> > > the CTS test? In parallel, I'll check if this is also enough for dEQP.
> > 
> > dEQP seems to require -1.0 in any case, the tests only pass as long as we
> > subtract in the range [0.96, 1.04]. Still, it is worth knowing if such a
> > change would make the CTS test pass.
> 
> Did not, it seems to pass with -0.01 .. -0.50 but -0.51 makes it fail.

I see, so CTE passes with -0.01..-0.50, piglit with -0.51..-1.49 and dEQP with
-0.96..-1.04.

Seeing the ranges involved it seems as if both dEQP and piglit expect -1.0,
only that piglit seems to be less strict with the requirements to accept the
test as passed.

I am not sure about what to do about this. As things stand now it does not look
like we can have both CTE and deqp/piglit pass for shadow cube samplers, at
least definitely not by adjusting the computation of the lod value like this. 

If the CTE test expectation is correct, then I guess it means that the formulas
we are using still need other tweaks for the case of (shadow) cube samplers or
that we are not configuring the sampler message correctly in all situations.
When the lowering pass kicks in, we use sampler_l_c messages, and there are
some restrictions that need to be considered, and there is one mention specific
to cube samplers: "The ai parameter indicates the array index for a cube
surface" that I am not sure that we are honoring.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150629/26756f30/attachment.html>


More information about the intel-3d-bugs mailing list