gallivm: add comment for bogus min/mag filter selection with nearest mip filter
authorRoland Scheidegger <sroland@vmware.com>
Wed, 21 Aug 2013 18:35:51 +0000 (20:35 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Wed, 21 Aug 2013 20:05:52 +0000 (22:05 +0200)
Detected this hunting some other bug, not sure if it really needs fixing but
it is definitely wrong.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
src/gallium/auxiliary/gallivm/lp_bld_sample.c
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c

index d339abaea04a3191f8ea8c2f80f6dea95d8def85..696855b133588771c74b52edf08a426466ffd600 100644 (file)
@@ -700,6 +700,14 @@ lp_build_lod_selector(struct lp_build_sample_context *bld,
 
             if (mip_filter == PIPE_TEX_MIPFILTER_NONE ||
                 mip_filter == PIPE_TEX_MIPFILTER_NEAREST) {
+               /*
+                * XXX: this is not entirely correct, as out_lod_ipart is used
+                * both for mip level determination as well as mag/min switchover
+                * point (if different min/mag filters are used). In particular,
+                * lod values between [-0.5,0] (rho between [sqrt(2), 1.0]) will
+                * incorrectly use min filter instead of mag (the non-optimized
+                * calculation further down has exactly the same problem).
+                */
                *out_lod_ipart = lp_build_ilog2(levelf_bld, rho);
                *out_lod_fpart = levelf_bld->zero;
                return;
index da416aab87efa7f265c6ad36eff4e7a0bb6f5f83..2573cec2d1bb5873345815fd8c24c00346b11cae 100644 (file)
@@ -1611,7 +1611,7 @@ lp_build_sample_aos(struct lp_build_sample_context *bld,
       LLVMValueRef minify;
 
       /*
-       * XXX this should to all lods into account, if some are min
+       * XXX this should take all lods into account, if some are min
        * some max probably could hack up the coords/weights in the linear
        * path with selects to work for nearest.
        * If that's just two quads sitting next to each other it seems
index 6d12587284435485865ee28253ed6a6632a7a0ea..34ab414733ce39a7b961c3d309ac34779f14d949 100644 (file)
@@ -1636,7 +1636,7 @@ lp_build_sample_general(struct lp_build_sample_context *bld,
       LLVMValueRef minify;
 
       /*
-       * XXX this should to all lods into account, if some are min
+       * XXX this should take all lods into account, if some are min
        * some max probably could hack up the coords/weights in the linear
        * path with selects to work for nearest.
        * If that's just two quads sitting next to each other it seems