Hello,
I've been thinking a lot about VS/GS/HS/DS inputs and outputs lately.
Ideally, I'd like to know the input layout at NIR creation time, so I
can make nir_lower_io() produce nice offsets into the VUE or pushed
registers. One thing that complicates that is when the inputs/outputs
change based on non-orthagonal state.
One example of this is legacy user-clipping: we extend the VS outputs
to contain clip distances when clip planes are enabled, so we can
potentially clip to gl_Position. This could then alter the GS input
layout, which awkwardly depends on the VS output layout.
Since we only support geometry shaders in core profile (and on Gen6+),
it turns out a bunch of this is unnecessary - legacy userclipping
simply doesn't exist. We can drop all GS support for it, and make
the VS only bother in compatibility contexts. (Presumably Paul added
this code in the hopes of doing ARB_geometry_shader4, back in the day.)
After dropping that, I noticed that we never actually extend VS outputs
(in core profile), so we can just use vp->OutputsWritten, rather than
program keys. Since the linker makes inputs/outputs match(*), I think
we can actually use gp->InputsRead, which means that the geometry shader
doesn't have any NOS at all - we don't need to recompile based on earlier
stages. HS and DS similarly have no issues.
(*) I think this is true, even with separate shader objects...but please
correct me if not...I'm not sure if we have tests for SSO VS/GS and
unused varyings...my patches absolutely rely on them being removed.
With that in place, our VUE map handling gets dramatically simpler.
I really like where these patches are going - it's much cleaner and
simpler - but I'm not 100% confident in them. Review would be most
appreciated. These also completely kill any hope of geometry shaders
pre-Gen6, but that seems pretty far-fetched to begin with.
This passes Piglit on all platforms, and I verified that a simple GS
cloth rendering demo still works.
Thanks,
--Ken
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
