On 15 January 2011 11:56, Christoph Bumiller <e0425...@student.tuwien.ac.at> wrote: > On 14.01.2011 17:47, Henri Verbeet wrote: >> On 14 January 2011 16:49, Brian Paul <bri...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
