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 <srol...@vmware.com> wrote: > Am 13.05.2016 um 23:10 schrieb Dave Airlie: >> From: Dave Airlie <airl...@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 <airl...@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 <srol...@vmware.com> > (But I'd like to hear from other driver's authors.) > > Roland > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
