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:
parent
21d8fa2759
commit
275d2efeed
|
@ -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;
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue