Bug 82463

Created attachment 104434 [details]
mipmap_tunnel isotropic case on i965

Created attachment 104435 [details]
texflit isotropic case on i965

Created attachment 104436 [details]
mipmap_tunnel isotropic case on i965 with fix

Created attachment 104437 [details]
texflit isotropic case on i965 with fix

Created attachment 104438 [details]
mipmap_tunnel isotropic case on nvidia

Created attachment 104439 [details]
texflit isotropic case on nvidia

We run all Piglit tests from 16-07-20114 except 'glean' and 'inline-explosion' (18873) on our Haswell configuration. We didn't observe any regressions/improvements/performance degradation with this patch on Piglit.

For reference, the proposed patch was discussed in the mesa-dev mailing list:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/065332.html

(In reply to Iago Toral from comment #8)
> For reference, the proposed patch was discussed in the mesa-dev mailing list:
> http://lists.freedesktop.org/archives/mesa-dev/2014-August/065332.html

The patch was dropped because it regressed a bunch of piglit tests. I have run piglit again with this patch and this still happens. The list of regressed tests is: 

tex-miplevel-selection textureprojgradoffset 1d_projvec4
tex-miplevel-selection textureprojgrad 2d_projvec4
tex-miplevel-selection *gradarb 2d
tex-miplevel-selection textureprojgrad 1d
tex-miplevel-selection texturegradoffset 1d
tex-miplevel-selection textureprojgradoffset 2d
tex-miplevel-selection texturegrad 1d
tex-miplevel-selection textureprojgrad 1d_projvec4
tex-miplevel-selection textureprojgradoffset 1d
tex-miplevel-selection *projgradarb 1d_projvec4
tex-miplevel-selection *projgradarb 1d
tex-miplevel-selection texturegradoffset 1darray
tex-miplevel-selection texturegradoffset 2darray
tex-miplevel-selection *gradarb 1d
tex-miplevel-selection texturegrad 1darray
tex-miplevel-selection *projgradarb 2d
tex-miplevel-selection texturegrad 2d
tex-miplevel-selection textureprojgradoffset 2d_projvec4
tex-miplevel-selection *projgradarb 2d_projvec4
tex-miplevel-selection textureprojgrad 2d
tex-miplevel-selection texturegradoffset 2d
tex-miplevel-selection texturegrad 2darray

In the cases where this fails the reported problem is related with a wrong texture level selection (off by one level in all failed cases):

Failure:
  Expected level: 1
  Observed level: 2
  Fetch level: 0, baselevel: 0, maxlevel: 2, minlod: 0, maxlod: 4, bias: 1, mipfilter: yes

This happens in ~101 out of 2637 test cases in each of the reported tests.

Notice that all the affected tests use gradients and there is this comment in from the HSW specs (as explained also in the bug report):

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

So my guess is that this is only expected to work when the texture gradients meet certain conditions...

The list of regressed tests above is for IVB, for HSW we have these and the shadow versions too.

In IVB I can fix the regressed tests by enabling the texture gradient lowering pass (currently only enabled for shadow samplers), since with that we compute the LOD manually from the gradients. That apparently fixes the problem for HSW too.

I'll test this a bit more and if I don't see other regressions I will send a patch for review to the mailing list.

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.

Created attachment 114245 [details] [review]
Patch 1/2

This patch lowers textureGrad in IvyBridge to compute the LOD manually from the texture gradients for all sampler types. This will fix all tex-miplevel-selection regressions once we enable EWA for isotropic filters.

Created attachment 114246 [details] [review]
Patch 2/2

This enables EWA for isotropic filters in IvyBridge.

Created attachment 114248 [details]
texgrad piglit test rendering result (master)

This shows the result (in master) of the piglit test:

bin/arb_shader_texture_lod-texgrad -auto -fbo

Rendering with texture and textureGrad are the same.

Created attachment 114249 [details]
texgrad piglit test rendering result (with patches)

This shows the result (in master) of the piglit test:

bin/arb_shader_texture_lod-texgrad -auto -fbo

Rendering with texture and textureGrad are not the same. If we remove patch 1/2 so that we don't lower textureGrad to compute LOD manually, then both renderings look like the one on the left, which are different from the renderings we obtain with master.

(In reply to Iago Toral from comment #16)
> Created attachment 114249 [details]
> texgrad piglit test rendering result (with patches)
> 
> This shows the result (in master) of the piglit test:
                            ^^^^^^
                            I meant with master + the 2 patches attached here

> bin/arb_shader_texture_lod-texgrad -auto -fbo
> 
> Rendering with texture and textureGrad are not the same. If we remove patch
> 1/2 so that we don't lower textureGrad to compute LOD manually, then both
> renderings look like the one on the left, which are different from the
> renderings we obtain with master.

-- 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/1451.