gallivm: add comment for bogus min/mag filter selection with nearest mip filter

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>
This commit is contained in:
Roland Scheidegger 2013-08-21 20:35:51 +02:00
parent 21d8fa2759
commit 275d2efeed
3 changed files with 10 additions and 2 deletions

View 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;

View 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

View 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