[Mesa-dev] [PATCH 09/11] tgsi: remove culldist semantic.
maraeo at gmail.com
Sat May 14 12:55:29 UTC 2016
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)
Our hardware only has 2 vec4 outputs. Each component can be configured
to be "clip distance", "cull distance", or "disabled" independently.
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] =
>> - "CULLDIST",
>> 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.
>> +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.)
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev