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

[Chris Forbes]

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 <stereotype441 at gmail.com> wrote:
> 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
>
>