[Mesa-dev] [PATCH 09/11] tgsi: remove culldist semantic.

[Marek Olšák]

Dave,
It should be noted that clip distances can be disabled by
pipe_rasterizer_state::clip_plane_enable, but cull distances can't.
(same as GL)

Roland,
Our hardware only has 2 vec4 outputs. Each component can be configured
to be "clip distance", "cull distance", or "disabled" independently.

Marek


On Sat, May 14, 2016 at 12:43 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 13.05.2016 um 23:10 schrieb Dave Airlie:
>> From: Dave Airlie <airlied at redhat.com>
>>
>> This isn't used anymore in the tree, culldist's
>> are part of the clipdist semantic, we could in theory
>> rename it, but I'm not sure there is much point, and
>> I'd have to be careful with virgl.
>>
>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>> ---
>>  src/gallium/auxiliary/tgsi/tgsi_strings.c  |  1 -
>>  src/gallium/docs/source/tgsi.rst           | 22 ++++++++++++++++++----
>>  src/gallium/include/pipe/p_shader_tokens.h |  1 -
>>  3 files changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> index 306ab4f..c13f7ea 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> @@ -85,7 +85,6 @@ const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT] =
>>     "PCOORD",
>>     "VIEWPORT_INDEX",
>>     "LAYER",
>> -   "CULLDIST",
>>     "SAMPLEID",
>>     "SAMPLEPOS",
>>     "SAMPLEMASK",
>> diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
>> index 4315707..ab12490 100644
>> --- a/src/gallium/docs/source/tgsi.rst
>> +++ b/src/gallium/docs/source/tgsi.rst
>> @@ -2876,18 +2876,32 @@ annotated with those semantics.
>>  TGSI_SEMANTIC_CLIPDIST
>>  """"""""""""""""""""""
>>
>> +Note this covers clipping and culling distances.
>> +
>>  When components of vertex elements are identified this way, these
>>  values are each assumed to be a float32 signed distance to a plane.
>> +
>> +For clip distances:
>>  Primitive setup only invokes rasterization on pixels for which
>> -the interpolated plane distances are >= 0. Multiple clip planes
>> -can be implemented simultaneously, by annotating multiple
>> -components of one or more vertex elements with the above specified
>> -semantic. The limits on both clip and cull distances are bound
>> +the interpolated plane distances are >= 0.
>> +
>> +For cull distances:
>> +Primitives will be completely discarded if the plane distance
>> +for all of the vertices in the primitive are < 0.
>> +If a vertex has a cull distance of NaN, that vertex counts as "out"
>> +(as if its < 0);
>> +
>> +Multiple clip/cull planes can be implemented simultaneously, by
>> +annotating multiple components of one or more vertex elements with
>> +the above specified semantic.
>> +The limits on both clip and cull distances are bound
>>  by the PIPE_MAX_CLIP_OR_CULL_DISTANCE_COUNT define which defines
>>  the maximum number of components that can be used to hold the
>>  distances and by the PIPE_MAX_CLIP_OR_CULL_DISTANCE_ELEMENT_COUNT
>>  which specifies the maximum number of registers which can be
>>  annotated with those semantics.
>> +The properties NUM_CLIPDIST_ENABLED and NUM_CULLDIST_ENABLED
>> +are used to divide up the 2 x vec4 space between clipping and culling.
> This should really say how it's determined which one is which (so clip
> dists come first).
>
>
> You should remove the TGSI_SEMANTIC_CULLDIST section.
>
> For patch 10, shouldn't this work with softpipe too?
>
> Honestly, I'm not a big fan of packed clip and cull dists in the same
> regs (it's still not the same as what d3d10 does in any case), my
> opinion is since we generally don't allow different semantics within the
> same reg, I see no good reason why we allow it here (and clip dists and
> cull dists, albeit somewhat similar, are still different). So, if some
> drivers wanted it in different regs and some in the same regs, I'd
> prefer it to be different regs in the interface, with drivers having to
> merge it when required, just because it looks cleaner. But if really all
> hw wants it like that, 6,8-11 are
> Reviewed-by: Roland Scheidegger <sroland at vmware.com>
> (But I'd like to hear from other driver's authors.)
>
> Roland
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev