[Mesa-dev] [RFC PATCH 02/10] i965/Gen4-5: allocate VUE slots for clipdistance if user clipping is enabled

[Paul Berry]

On 3 August 2013 19:59, Chris Forbes <chrisf at ijw.co.nz> wrote:

> Also adjust the SF URB read offset to account for there being two
> additional slots of stuff it doesn't care about.
>
> Signed-off-by: Chris Forbes <chrisf at ijw.co.nz>
> ---
>  src/mesa/drivers/dri/i965/brw_sf.h | 2 +-
>  src/mesa/drivers/dri/i965/brw_vs.c | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_sf.h
> b/src/mesa/drivers/dri/i965/brw_sf.h
> index 09880fe..eb40551 100644
> --- a/src/mesa/drivers/dri/i965/brw_sf.h
> +++ b/src/mesa/drivers/dri/i965/brw_sf.h
> @@ -105,6 +105,6 @@ void brw_emit_point_setup( struct brw_sf_compile *c,
> bool allocate );
>  void brw_emit_point_sprite_setup( struct brw_sf_compile *c, bool allocate
> );
>  void brw_emit_anyprim_setup( struct brw_sf_compile *c );
>
> -#define BRW_SF_URB_ENTRY_READ_OFFSET 1
> +#define BRW_SF_URB_ENTRY_READ_OFFSET 2
>

I don't think this is going to work, since SF needs to be able to read the
clip distances out of the URB in case they are needed by the FS (GLSL 1.30
allows fragment shaders to read from the gl_ClipDistance array).  I wonder
if this is why you ran into trouble with patch 3?


>
>  #endif
> diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
> b/src/mesa/drivers/dri/i965/brw_vs.c
> index 5b8173d..e6d8c5d 100644
> --- a/src/mesa/drivers/dri/i965/brw_vs.c
> +++ b/src/mesa/drivers/dri/i965/brw_vs.c
> @@ -94,6 +94,8 @@ brw_compute_vue_map(struct brw_context *brw, struct
> brw_vue_map *vue_map,
>         */
>        assign_vue_slot(vue_map, VARYING_SLOT_PSIZ);
>        assign_vue_slot(vue_map, BRW_VARYING_SLOT_NDC);
> +      assign_vue_slot(vue_map, VARYING_SLOT_CLIP_DIST0);
> +      assign_vue_slot(vue_map, VARYING_SLOT_CLIP_DIST1);
>

Technically I don't think this is actually necessary.  All that is needed
is for the clip distance varying slots to be next to each other in the VUE,
since patch 07/10 assumes that all clip distances are contiguous in the
VUE.  And that will happen anyhow, since VARYING_SLOT_CLIP_DIST1 ==
VARYING_SLOT_CLIP_DIST0 + 1.

Having said that, I don't think there's anything wrong with moving the clip
distances to the start of the VUE.  It has the advantage of making Gen4-5
more consistent with Gen6-7, and that's a nice thing.  So if you want to
leave this code in, that's fine with me.

I would recommend, however, placing these two calls to assign_vue_slot()
inside an "if (userclip_active)" conditional (like we do for Gen6-7) so
that we don't have to waste VUE slots in programs that don't use
user-defined clipping.


>
>        assign_vue_slot(vue_map, VARYING_SLOT_POS);
>        break;
>     case 6:
> --
> 1.8.3.4
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130805/48053a92/attachment.html>