[Mesa-dev] [PATCH 26/28] glsl: lower tessellation varyings packed with component layout qualifier

Timothy Arceri timothy.arceri at collabora.com
Fri Feb 26 23:26:14 UTC 2016


On Thu, 2016-02-25 at 18:32 -0800, Kenneth Graunke wrote:
> On Tuesday, December 29, 2015 4:00:26 PM PST Timothy Arceri wrote:
> > For tessellation shaders we cannot just copy everything to the
> > packed
> > varyings like we do in other stages as tessellation uses shared
> > memory for
> > varyings, therefore it is only safe to copy array elements that the
> > shader
> > actually uses.
> 
> Also, you can only copy the exact *components* written by the shader.
> For example, one nasty thing a valid TCS might do is:
> 
>    patch out ivec4 foo;
>    foo[gl_InvocationID] = gl_InvocationID;
> 
> which, given four threads, will write <0, 1, 2, 3> to the
> vector.  But
> if each thread writes the whole vec4 by accident, you may end up with
> garbage in 3/4 of the components.

I had trouble trying to implement the above example on the Nvidia blob,
I only ever seemed to get one component written.

Are you sure thats valid? The spec says:

"Tessellation control shaders will get undefined results if one
invocation reads a per-vertex or per-patch attribute written by another
invocation at any point during the same phase, or if two invocations
attempt to write different values to the same per-patch output in a
single phase."

I've also been under the wrong assumption that different invocations
could overwrite each others per-vertex attributes but looking at the
spec that is not that case.

"Each invocation can read the attributes of any vertex in the input or
output patches, but can only write per-vertex attributes for the
corresponding output patch vertex."

"Tessellation control shaders must use the special variable
gl_InvocationID as the vertex number index when writing to per-vertex
output variables."

So if we really don't have to handle your example then that makes thing
s a bit simpler and I can likely clean this up a bit.



More information about the mesa-dev mailing list