gallivm: fix bogus argument order to lp_build_sample_mipmap function
authorRoland Scheidegger <sroland@vmware.com>
Thu, 21 Apr 2016 00:52:35 +0000 (02:52 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Thu, 21 Apr 2016 21:57:24 +0000 (23:57 +0200)
Screwed up since 0753b135f6e83b171d8a1b08aea967374f3542bc.

(Only an issue with different min/mag filters, and then only in some cases,
which is probably why it went unnoticed for quite a while.
The effect should have simply been nearest mip filter instead of linear, iff
min was nearest, mag was linear, and all pixels hit the mignifying path.)

Fixes a bunch of dEQP failures.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c

index 83db0edc82f2081c8776e3ca7879f4f5e03c1fd4..1727105e4f41a7feecf5d511a3ae78c77fcc95bc 100644 (file)
@@ -2256,8 +2256,8 @@ lp_build_sample_general(struct lp_build_sample_context *bld,
              * All pixels require just nearest filtering, which is way
              * cheaper than linear, hence do a separate path for that.
              */
-            lp_build_sample_mipmap(bld, PIPE_TEX_FILTER_NEAREST, FALSE,
-                                   mip_filter_for_nearest,
+            lp_build_sample_mipmap(bld, PIPE_TEX_FILTER_NEAREST,
+                                   mip_filter_for_nearest, FALSE,
                                    coords, offsets,
                                    ilevel0, ilevel1, lod_fpart,
                                    texels);