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

[Henri Verbeet]

On 15 January 2011 11:56, Christoph Bumiller
<e0425955 at student.tuwien.ac.at> wrote:
> 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.
>>
Looks like mipmap_limits is unaffected by this patch on r600g.

> 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.
>
A quick grep suggests only nvfx, nv50, nvc0, r300 and r600 take
first_level into account at all, and in case of e.g. r300 it looks
like it does so incorrectly, since min_lod / max_lod is applied
regardless of mipmapping being used or not.

For reference, to show the bug the patch fixes, replace
GL_NEAREST_MIPMAP_NEAREST with GL_NEAREST, and GL_LINEAR_MIPMAP_LINEAR
with GL_LINEAR in mipmap_limits.c. The expected behaviour would then
be that only changing BASE_LEVEL has any effect. On r600g the current
behaviour is that neither BASE_LEVEL nor MIN_LOD makes any difference,
but depending on how a specific driver interprets min_lod I could also
imagine both of them making a difference instead.