On 3 August 2013 19:59, Chris Forbes <[email protected]> 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 <[email protected]> > --- > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
