In my current code most of this has gone away -- I just force VARYING_SLOT_CLIP_DIST* to be valid if we're doing user clipping, and they fall wherever they naturally would in the VUE map.
On Tue, Aug 6, 2013 at 9:19 AM, Paul Berry <stereotype...@gmail.com> wrote: > On 3 August 2013 19:59, Chris Forbes <chr...@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 <chr...@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@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
