Am 16.09.2014 18:41, schrieb Ilia Mirkin: > On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin <imir...@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? Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
