summaryrefslogtreecommitdiffstats
path: root/src
diff options
context:
space:
mode:
authorBrian Paul <[email protected]>2010-05-10 16:01:09 -0600
committerBrian Paul <[email protected]>2010-05-10 17:04:19 -0600
commitbd34f61a7a84b039b1c9d4aafbdb8f7656c8dd11 (patch)
treecc0cfce7da3dd6cb58db84cc3cf0b562f0b8d72f /src
parente0b5c6f9217e27c4a8f97c08f5bb488312429af8 (diff)
llvmpipe: add, update, rewrap comments
Diffstat (limited to 'src')
-rw-r--r--src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c3
-rw-r--r--src/gallium/drivers/llvmpipe/lp_bld_blend_soa.c19
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 3fa5e51cac5..44c28c1739a 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 b7523eb9c13..d95e6a6b68e 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;