[Bug 82463] i965: Using EWA algorithm for isotropic case

[bugzilla-daemon at freedesktop.org]

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

--- Comment #12 from Iago Toral <itoral at igalia.com> ---
Ok, so here is what is happening. The following sentence from the Haswell PRM:

"When EWA used for non-anisotropic filtering and the coordinates have zero
derivative the computed LOD is 0 instead of -inf."

means that when we use EWA with isotropic filters the hardware is not computing
the expected LOD for the cases where derivative of the coordinates is 0. This
will lead to the texture not being rendered as expected. This is the reason why
all the tex-miplevel-selection with gradients fail.

We can fix the tests by computing the LOD from the gradients manually. We have
a lowering pass for that that we are currently only using for some shadow
samplers. Enabling this for all sampler types fixes the tests for IvyBridge and
Haswell.

However, that sentence from the PRM has an effect beyond textureGrad and
affects all texture functions. This is revealed once the tex-miplevel-selection
tests are fixed for textureGrad, since at that moment the the following piglit
test will fail:

bin/arb_shader_texture_lod-texgrad -auto -fbo

This test renders the same sample twice, using texture() and using
textureGrad(), and expects the rendering to be almost identical in both cases.
However, after patching textureGrad, this is not happening. This is because the
LOD is being computed manually with textureGrad and by the hardware in
texture(), and thus, the latter is affected by the programming note in the PRM,
leading to a clearly different rendering. If we don't patch textureGrad, then
the test passes because both renderings will have the LOD computed by the
hardware and be subject to the same rules.

I'll attach images that show the differences in rendering.

Fixing this would involve lowering _all_ texture operations so that we compute
the LOD manually. I don't think it is worth it, and I guess it would come with
a performance impact because we would not only be using a heavier algorithm,
but also because we would have to do the LOD computations manually all the
time.

I'll attach patches for IVB, just in case anyone wants to play with this. I can
upload patches for Haswell too if someone is interested.

-- 
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/20150312/634b0b92/attachment.html>