Am 14.05.2016 um 14:55 schrieb 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)
That only applies to user clip planes, not shader clip distances. > > Roland, > Our hardware only has 2 vec4 outputs. Each component can be configured > to be "clip distance", "cull distance", or "disabled" independently. > Ok. Roland > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=mWAND3ELitFSIGn3LaQ9eDlEXitrSp5g2LRX0nzGYF8&s=c_Ik7rEVzrYiqaJEZb_A51FunW8lKm-znV3nP6F_Jvc&e= >> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
