[Mesa-dev] [PATCH 21/36] i965: SF: New implementation of get_attr_override using the VUE map.

Eric Anholt eric at anholt.net
Fri Sep 2 13:57:07 PDT 2011


On Fri,  2 Sep 2011 09:07:00 -0700, Paul Berry <stereotype441 at gmail.com> wrote:
> This patch changes get_attr_override() (which computes the
> relationship between vertex shader outputs and fragment shader inputs)
> to use the VUE map.
> ---
>  src/mesa/drivers/dri/i965/brw_state.h     |    3 +-
>  src/mesa/drivers/dri/i965/gen6_sf_state.c |  108 +++++++++++++++++------------
>  src/mesa/drivers/dri/i965/gen7_sf_state.c |   13 +++-
>  3 files changed, 75 insertions(+), 49 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_state.h b/src/mesa/drivers/dri/i965/brw_state.h
> index cede4e5..167134b 100644
> --- a/src/mesa/drivers/dri/i965/brw_state.h
> +++ b/src/mesa/drivers/dri/i965/brw_state.h
> @@ -206,7 +206,8 @@ void upload_default_color(struct brw_context *brw,
>  
>  /* gen6_sf_state.c */
>  uint32_t
> -get_attr_override(struct brw_context *brw, int fs_attr, int two_side_color);
> +get_attr_override(struct brw_vue_map *vue_map, int urb_entry_read_offset,
> +                  int fs_attr);
>  
>  /* gen7_misc_state.c */
>  unsigned int
> diff --git a/src/mesa/drivers/dri/i965/gen6_sf_state.c b/src/mesa/drivers/dri/i965/gen6_sf_state.c
> index 714914a..5e121f7 100644
> --- a/src/mesa/drivers/dri/i965/gen6_sf_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_sf_state.c

> +   if (vs_attr < 0 || vs_attr == VERT_RESULT_HPOS) {
> +      /* These attributes will be overwritten by the fragment shader's
> +       * interpolation code (see emit_interp() in brw_wm_fp.c), so just let
> +       * them reference attribute the first available attribute.
> +       */
> +      return 0;

One too many attributes in that comment.

> +   /* Compute the location of the attribute relative to urb_entry_read_offset.
> +    * Each increment of urb_entry_read_offset represents a 256-bit value, so
> +    * it counts for two 128-bit VUE slots.
> +    */
> +   attr_override = slot - 2*urb_entry_read_offset;

I like spaces between binary operators unless you're really hurting for
space.

> +   assert (attr_override >= 0 && attr_override < 32);
>  
> -   return attr_index;
> +   /* If the VUE slot following this one represents a back-facing color, then
> +    * we need to instruct the SF unit to do back-facing swizzling.
> +    */
> +   if (vue_map->slot_to_vert_result[slot] == VERT_RESULT_COL0 &&
> +       vue_map->slot_to_vert_result[slot+1] == VERT_RESULT_BFC0)
> +      attr_override |= (ATTRIBUTE_SWIZZLE_INPUTATTR_FACING << ATTRIBUTE_SWIZZLE_SHIFT);
> +   else if (vue_map->slot_to_vert_result[slot] == VERT_RESULT_COL1 &&
> +            vue_map->slot_to_vert_result[slot+1] == VERT_RESULT_BFC1)
> +      attr_override |= (ATTRIBUTE_SWIZZLE_INPUTATTR_FACING << ATTRIBUTE_SWIZZLE_SHIFT);
> +
> +   return attr_override;

I think that this is the wrong criteria for backface color swizzle, not
that it's a new bug you're introducing.  We need some tests for this.
From the GL 3.2 compatibility spec, page 75:

    "Additionally, vertex and geometry shaders can operate in two-sided
     color mode. When a vertex or geometry shader is active, front and
     back colors can be computed by the shader and written to the
     gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor and
     gl_BackSecondaryColor outputs. If VERTEX_PROGRAM_TWO_SIDE is
     enabled, the GL chooses between front and back colors, as described
     below. Otherwise, the front color output is always
     selected. Two-sided color mode is enabled and disabled by calling
     Enable or Disable with the symbolic value VERTEX_PROGRAM_TWO_SIDE.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110902/cdf72b6e/attachment.pgp>


More information about the mesa-dev mailing list