diff options
author | Brian Paul <brianp@vmware.com> | 2010-05-10 16:01:09 -0600 |
---|---|---|
committer | Brian Paul <brianp@vmware.com> | 2010-05-10 17:04:19 -0600 |
commit | bd34f61a7a84b039b1c9d4aafbdb8f7656c8dd11 (patch) | |
tree | cc0cfce7da3dd6cb58db84cc3cf0b562f0b8d72f /src/gallium/drivers | |
parent | e0b5c6f9217e27c4a8f97c08f5bb488312429af8 (diff) |
llvmpipe: add, update, rewrap comments
Diffstat (limited to 'src/gallium/drivers')
-rw-r--r-- | src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c | 3 | ||||
-rw-r--r-- | src/gallium/drivers/llvmpipe/lp_bld_blend_soa.c | 19 |
2 files changed, 16 insertions, 6 deletions
diff --git a/src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c b/src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c index 3fa5e51cac..44c28c1739 100644 --- a/src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c +++ b/src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c @@ -243,6 +243,9 @@ lp_build_blend_factor(struct lp_build_blend_aos_context *bld, } +/** + * Is (a OP b) == (b OP a)? + */ boolean lp_build_blend_func_commutative(unsigned func) { diff --git a/src/gallium/drivers/llvmpipe/lp_bld_blend_soa.c b/src/gallium/drivers/llvmpipe/lp_bld_blend_soa.c index b7523eb9c1..d95e6a6b68 100644 --- a/src/gallium/drivers/llvmpipe/lp_bld_blend_soa.c +++ b/src/gallium/drivers/llvmpipe/lp_bld_blend_soa.c @@ -33,8 +33,8 @@ * Blending in SoA is much faster than AoS, especially when separate rgb/alpha * factors/functions are used, since no channel masking/shuffling is necessary * and we can achieve the full throughput of the SIMD operations. Furthermore - * the fragment shader output is also in SoA, so it fits nicely with the rest of - * the fragment pipeline. + * the fragment shader output is also in SoA, so it fits nicely with the rest + * of the fragment pipeline. * * The drawback is that to be displayed the color buffer needs to be in AoS * layout, so we need to tile/untile the color buffer before/after rendering. @@ -77,7 +77,7 @@ /** - * We may the same values several times, so we keep them here to avoid + * We may use the same values several times, so we keep them here to avoid * recomputing them. Also reusing the values allows us to do simplifications * that LLVM optimization passes wouldn't normally be able to do. */ @@ -98,16 +98,22 @@ struct lp_build_blend_soa_context /** * We store all factors in a table in order to eliminate redundant * multiplications later. + * Indexes are: factor[src,dst][color,term][r,g,b,a] */ LLVMValueRef factor[2][2][4]; /** * Table with all terms. + * Indexes are: term[src,dst][r,g,b,a] */ LLVMValueRef term[2][4]; }; +/** + * Build a single SOA blend factor for a color channel. + * \param i the color channel in [0,3] + */ static LLVMValueRef lp_build_blend_soa_factor(struct lp_build_blend_soa_context *bld, unsigned factor, unsigned i) @@ -218,6 +224,7 @@ lp_build_blend_soa(LLVMBuilderRef builder, } for (i = 0; i < 4; ++i) { + /* only compute blending for the color channels enabled for writing */ if (blend->rt[0].colormask & (1 << i)) { if (blend->logicop_enable) { if(!type.floating) { @@ -269,9 +276,9 @@ lp_build_blend_soa(LLVMBuilderRef builder, /* XXX special case these combos to work around an apparent * bug in LLVM. * This hack disables the check for multiplication by zero - * in lp_bld_mul(). When we optimize away the multiplication, - * something goes wrong during code generation and we segfault - * at runtime. + * in lp_bld_mul(). When we optimize away the + * multiplication, something goes wrong during code + * generation and we segfault at runtime. */ LLVMValueRef zeroSave = bld.base.zero; bld.base.zero = NULL; |