[Mesa-dev] TGSI and Tessellation Control Shader outputs
maraeo at gmail.com
Thu Oct 9 07:59:14 PDT 2014
I have been thinking about this more and I actually like the way
OpenGL does it. The indexing with InvocationID can be lowered with a
copy propagation pass for drivers that cannot do it - or they can just
ignore the innermost index and assume it's always equal to
InvocationID. I also prefer having readable shader outputs.
One little ugly thing right now is that patch outputs are
one-dimensional and vertex outputs are 2-dimensional. So you normally
We can either leave it this way and assume that if an output access is
2-dimensional, it's per-vertex, otherwise it's per-patch. Or we can
add another file for per-vertex data. The same applies to shader
inputs and I think we have had this since geometry shaders:
Not to say that indirect addressing into outputs is a mess. For that,
it would be better to have a strict mapping from outputs to semantics,
e.g. OUT0[i] == PATCHi and OUT1[j] == GENERICj. Alternatively, we
can just explicitly use semantic names in the shader code, e.g.:
MOV OUT.GENERIC[ADDR.x], TEMP
But that would be a lot of work and I'd rather not delay upstreaming
tessellation because of this.
On Fri, Aug 29, 2014 at 10:44 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> I've been thinking a bit about how to properly implement TCS outputs
> in TGSI. As a quick reminder, there are per-vertex (i.e. invocation)
> and per-patch outputs in TCS. And while you can only write to the
> current invocation's per-vertex outputs, you can read from any of
> them. (With barrier() used to synchronize invocations.)
> Per-patch outputs map quite nicely onto the existing infrastructure,
> so the rest of the questions will be about per-vertex outputs.
> One can represent per-vertex outputs as 2D output arrays. That means
> support for them needs to be added all over (which I've actually done,
> so I'm not complaining about the extra work but rather asking if it's
> a good idea). And then you might have
> DCL OUT, GENERIC
> MOV ADDR.x, SV /* invocation id */
> MOV OUT[ADDR.x], TEMP /* store value */
> MOV TEMP, OUT /* read output from invocation == 3 */
> The advantage here is that it's all nice and consistent. However the
> disadvantage is that we have to add a totally useless read of the
> invocation id and use it as a relative index for the store. At least
> the nvidia shaders don't even have a way of writing other invocations'
> data even if they wanted to (without resorting to global memory
> accesses). So it's complicating all sorts of logic for apparently no
> real benefit.
> Another approach might be to bypass the invocation id on storing the
> output, but using it on reads. For example code like
> DCL OUT, GENERIC
> MOV OUT, TEMP
> MOV TEMP, OUT
> This avoids having to teach tgsi about 2d outputs (esp reladdr ones).
> This seems a lot simpler, but it ignores the gl_InvocationID indexing
> that happens when writing the output. However I don't think that's so
> bad. It also means that reads and writes are interpreted a little
> differently for OUT's, but that doesn't seem so bad either.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev