[Mesa-dev] [PATCH 1/1] st/mesa: Set samplers views' first_level.

[Christoph Bumiller]

On 14.01.2011 17:47, Henri Verbeet wrote:
> On 14 January 2011 16:49, Brian Paul <brianp at vmware.com> wrote:
>> This isn't fresh in my head any more, but the code as-is matches the
>> behaviour of NVIDIA's driver (and fixed a mipmap failure in a test
>> somewhere).  The mesa-demos/src/tests/mipmap_limits test is good for testing
>> this.
>>
>> I applied your patch and now mipmap_limits no longer matches NVIDIA.
>>
> Is that on any specific hardware / driver? I'll have a look at that
> demo to see what happens here.
>
As far as I can see, llvmpipe behaves wrong with this patch (you can see
the dominant color be selected from the far point with increased base
level and the near one with increased min lod).

nouveau/nvc0 seems to remain consistent with the binary driver, which is
not very surprising since there are texture/sampler configuration slots
for MIN_LOD, MAX_LOD and BASE_LEVEL which are supposed to be equal to
the GL params.

>> I don't have time right now to dig into this.  Does your patch fix something
>> in particular?
>>
> The specific bug it fixes is image array selection for linear filtered
> textures with Evergreen on r600g. (There's a Wine d3d9 test that ends
> up failing because of this, but it can be reproduced with a trivial GL
> program as well.) When mipmapping is disabled (i.e., with LINEAR or
> NEAREST filtering) min_lod / max_lod should be ignored, and the
> decision of what image to use should be based purely on the texture's
> base level. R600g behaves according to the spec in that regard, but
> because the state tracker currently always gives us 0 for first_level
> this means we always use level 0 for non-mipmapped textures.
>
> For what it's worth, the binary nvidia driver passes that test.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev