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