On 02/25/2013 11:51 AM, Eric Anholt wrote:
Kenneth Graunke <kenn...@whitecape.org> writes:
GLSL provides gradients for the 'r' coordinate (face ID), while our
hardware apparently ignores them. Sadly, this means that sample_d and
sample_d_c appear to be unsuitable for OpenGL, and need to be lowered.
'r' isn't a face ID in GLSL, though -- it's just the 3rd component of
the vector pointing to texels. Did you mean it's used as face ID in
hardware for sample_d/d_c?
Yes, that's right...I apologize for the poor wording. Here's the
updated commit message:
According to the Ivybridge PRM, Volume 4 Part 1, page 130, in the
section for the sample_d message: "The r coordinate contains the
faceid, and the r gradients are ignored by hardware."
This doesn't match GLSL, which provides gradients for all of the
coordinates. So we would need to do some math to compute the face ID
before using sample_d. We currently don't have any code to do that.
However, we do have a lowering pass that converts textureGrad to
textureLod, which solves this problem. Since textureGrad on three
components is sufficiently obscure, it's not a performance path.
For now, only handle samplerCubeShadow; we need tests for samplerCube
and samplerCubeArray.
Fixes es3conform's shadow_comparison_frag test on Haswell.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenn...@whitecape.org>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
