[Mesa-dev] TGSI and Tessellation Control Shader outputs

Marek Olšák maraeo at gmail.com
Tue Sep 16 10:01:28 PDT 2014


On Tue, Sep 16, 2014 at 6:41 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> OK, so just to summarize:
>>>
>>> The approach suggested by Roland is to have the outputs be
>>> one-dimensional and only representing the current invocation's
>>> per-vertex outputs. Each invocation would also get access to other
>>> invocations' per-vertex outputs via a 2d input array.
>>>
>>> So a shader might look something like
>>>
>>> TESSC
>>> DECL IN[][0], POSITION (input patch's per-vertex position)
>>> DECL IN[][1], GENERIC (input patch's per-vertex generic attribute)
>>> DECL IN[][2], TCS_POSITION (output patch's per-vertex position)
>>> DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute)
>>> DECL OUT[0], POSITION
>>> DECL OUT[1], GENERIC
>>> DECL OUT[2], PATCH
>>>
>>> And then anything written to OUT[0] would be aliased via IN[][2].
>>> Roland, does that sound right? This seems kinda nasty that there are
>>> going to be 2 types of position/pointsize/clipdistance inputs -- do
>>> you have a better suggestion for handling that?
>>
>> The output-as-input arrays can be declared as system values (SV), then
>> you don't need to duplicate semantic names.
>
> OK, that sounds reasonable. And what do you guys think about reading
> directly from per-patch outputs? Or should they also be mirrored as
> SV's? We definitely need something since it's shared between
> invocations and synchronizable using barrier.

Alternatively, you can add another TGSI file for these kinds of
variables. I personally don't care much as long as it doesn't get
messy.

I'll probably use on-chip shared memory for the outputs and load/store
instructions for accessing them, so if they are inputs or outputs in
TGSI doesn't make much difference for me.

Marek


More information about the mesa-dev mailing list