[Mesa-dev] TGSI and Tessellation Control Shader outputs

[Roland Scheidegger]

Am 16.09.2014 19:40, schrieb Marek Olšák:
> On Tue, Sep 16, 2014 at 7:31 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 16.09.2014 18:41, schrieb Ilia Mirkin:
>>> 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.
>>
>> I guess reading back from outputs is ok then (I probably said something
>> different in the past?), this is usually allowed in tgsi. I guess the
>> difference is that if a driver can't do it you can't just lower it to
>> temp writes + output write later cause it would cause the
>> synchronization to not work (though, you could write any output write
>> deferred to a temp at sync time).
>> My guess is that if you'd write to some output and read back from it,
>> you wouldn't need any sync, but if you'd write to some output and read
>> it back via the input, you'd be required to sync?
> 
> AFAIK, the sync is required if you access outputs that other shaders
> have written. If you only access outputs that the same shader has
> written, there is no sync needed.
> 
> Marek
> 
Well that's for OpenGL because it doesn't have different inputs and
outputs. But we could easily require sync must be done if we allow the
(separate) output to be read accessed. It kinda seems awkward to have an
input which you must sync before accessing it except in case the
dimension index happens to match the current invocation...

Roland