From bd34f61a7a84b039b1c9d4aafbdb8f7656c8dd11 Mon Sep 17 00:00:00 2001
From: Brian Paul <brianp@vmware.com>
Date: Mon, 10 May 2010 16:01:09 -0600
Subject: llvmpipe: add, update, rewrap comments

---
 src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c |  3 +++
 src/gallium/drivers/llvmpipe/lp_bld_blend_soa.c | 19 +++++++++++++------
 2 files changed, 16 insertions(+), 6 deletions(-)

(limited to 'src/gallium')

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;
-- 
cgit v1.2.3