Bug 82463 - i965: Using EWA algorithm for isotropic case
Summary: i965: Using EWA algorithm for isotropic case
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.2
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-11 11:55 UTC by pavel.e.popov
Modified: 2015-03-12 08:41 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
mipmap_tunnel isotropic case on i965 (202.56 KB, image/png)
2014-08-11 11:56 UTC, pavel.e.popov
Details
texflit isotropic case on i965 (258.55 KB, image/png)
2014-08-11 11:57 UTC, pavel.e.popov
Details
mipmap_tunnel isotropic case on i965 with fix (205.27 KB, image/png)
2014-08-11 11:57 UTC, pavel.e.popov
Details
texflit isotropic case on i965 with fix (219.59 KB, image/png)
2014-08-11 11:58 UTC, pavel.e.popov
Details
mipmap_tunnel isotropic case on nvidia (60.73 KB, image/png)
2014-08-11 11:58 UTC, pavel.e.popov
Details
texflit isotropic case on nvidia (193.13 KB, image/png)
2014-08-11 11:59 UTC, pavel.e.popov
Details
Patch 1/2 (1.77 KB, patch)
2015-03-12 08:31 UTC, Iago Toral
Details | Splinter Review
Patch 2/2 (5.02 KB, patch)
2015-03-12 08:32 UTC, Iago Toral
Details | Splinter Review
texgrad piglit test rendering result (master) (179.14 KB, image/png)
2015-03-12 08:36 UTC, Iago Toral
Details
texgrad piglit test rendering result (with patches) (74.13 KB, image/png)
2015-03-12 08:40 UTC, Iago Toral
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pavel.e.popov 2014-08-11 11:55:06 UTC
Tests "MesaDemos tests/texfilt" and Test "MesaDemos tests/mipmap_tunnel" started to show an expected results (the transition from one mipmap level to another should be nice and regular/circular) for anisotropic case (2x - 16x) after EWA algorithm was enabled in Mesa: 
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f74cf5f80ea6ea16abb38c28c2b4826b8559017b

But for isotropic case (1x) something like a polar rose is still observed. The screenshots are attached below. This is because EWA algorithm was enabled in Mesa only for anisotropic case. 

But EWA algorithm also can be enabled for isotropic case. At least Haswell programming notes (Volume 2d: Command Reference: Structures(Haswell), Page 271) contains the following lines:
"When EWA used for non-anisotropic filtering and the coordinates have zero derivative the computed LOD is 0 instead of -inf."

I enabled EWA algorithm for isotropic case too and expected results were observed for both tests. The screenshots are attached below.

Also I run these tests on Nvidia and observed that they also work as expected. The screenshots are attached below.

Could we use EWA for isotropic case? Or just say that this polar rose is ok for isotropic case and performance is more important for us here.
Comment 1 pavel.e.popov 2014-08-11 11:56:07 UTC
Created attachment 104434 [details]
mipmap_tunnel isotropic case on i965
Comment 2 pavel.e.popov 2014-08-11 11:57:18 UTC
Created attachment 104435 [details]
texflit isotropic case on i965
Comment 3 pavel.e.popov 2014-08-11 11:57:43 UTC
Created attachment 104436 [details]
mipmap_tunnel isotropic case on i965 with fix
Comment 4 pavel.e.popov 2014-08-11 11:58:16 UTC
Created attachment 104437 [details]
texflit isotropic case on i965 with fix
Comment 5 pavel.e.popov 2014-08-11 11:58:48 UTC
Created attachment 104438 [details]
mipmap_tunnel isotropic case on nvidia
Comment 6 pavel.e.popov 2014-08-11 11:59:12 UTC
Created attachment 104439 [details]
texflit isotropic case on nvidia
Comment 7 pavel.e.popov 2014-08-19 07:27:35 UTC
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.
Comment 8 Iago Toral 2015-03-11 09:30:22 UTC
For reference, the proposed patch was discussed in the mesa-dev mailing list:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/065332.html
Comment 9 Iago Toral 2015-03-11 10:23:21 UTC
(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.
Comment 10 Iago Toral 2015-03-11 10:24:31 UTC
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...
Comment 11 Iago Toral 2015-03-11 11:27:51 UTC
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.
Comment 12 Iago Toral 2015-03-12 08:28:43 UTC
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.
Comment 13 Iago Toral 2015-03-12 08:31:35 UTC
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.
Comment 14 Iago Toral 2015-03-12 08:32:45 UTC
Created attachment 114246 [details] [review]
Patch 2/2

This enables EWA for isotropic filters in IvyBridge.
Comment 15 Iago Toral 2015-03-12 08:36:29 UTC
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.
Comment 16 Iago Toral 2015-03-12 08:40:35 UTC
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.
Comment 17 Iago Toral 2015-03-12 08:41:20 UTC
(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.


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.