Commit Graph

16 Commits

Author SHA1 Message Date
Yuwen Wu
c8a43876c7
added metal keyworld: "level" (#1501)
* added metal keyworld: "level"

* added more metal keywords

* updated test case.
2020-10-30 08:07:25 +01:00
Chip Davis
3e6010d8c5 MSL: Don't use a bitcast for tessellation levels in tesc shaders.
`half` cannot be bitcasted to `float`, because the two types are not the
same size. Use an expanding cast instead.

We were already doing this for stores to the tessellation levels; why I
didn't also do this for loads is beyond me.
2020-10-14 18:35:59 -05:00
Chip Davis
3347b1076d MSL: Fix handling of matrices and structs in the output control point array.
Prior to this point, we were treating them as flattened, as they are in
old-style tessellation control shaders, and still are for structs in
new-style shaders. This is not true for outputs; output composites are
not flattened at all. This semantic mismatch broke a Vulkan CTS test.
It should now pass.
2020-08-03 17:18:18 -05:00
Chip Davis
688c5fcbda MSL: Add support for processing more than one patch per workgroup.
This should hopefully reduce underutilization of the GPU, especially on
GPUs where the thread execution width is greater than the number of
control points.

This also simplifies initialization by reading the buffer directly
instead of using Metal's vertex-attribute-in-compute support. It turns
out the only way in which shader stages are allowed to differ in their
interfaces is in the number of components per vector; the base type must
be the same. Since we are using the raw buffer instead of attributes, we
can now also emit arrays and matrices directly into the buffer, instead
of flattening them and then unpacking them. Structs are still flattened,
however; this is due to the need to handle vectors with fewer components
than were output, and I think handling this while also directly emitting
structs could get ugly.

Another advantage of this scheme is that the extra invocations needed to
read the attributes when there were more input than output points are
now no more. The number of threads per workgroup is now lcm(SIMD-size,
output control points). This should ensure we always process a whole
number of patches per workgroup.

To avoid complexity handling indices in the tessellation control shader,
I've also changed the way vertex shaders for tessellation are handled.
They are now compute kernels using Metal's support for vertex-style
stage input. This lets us always emit vertices into the buffer in order
of vertex shader execution. Now we no longer have to deal with indexing
in the tessellation control shader. This also fixes a long-standing
issue where if an index were greater than the number of vertices to
draw, the vertex shader would wind up writing outside the buffer, and
the vertex would be lost.

This is a breaking change, and I know SPIRV-Cross has other clients, so
I've hidden this behind an option for now. In the future, I want to
remove this option and make it the default.
2020-07-23 17:59:54 -05:00
Hans-Kristian Arntzen
fa011f8547 MSL: Declare arrays with proper type wrapper.
Need to construct with value type spvUnsafeArray<T, N>({ elem0, elem1 })
to make array initialization work in complex scenarios.
2019-10-26 17:57:34 +02:00
Hans-Kristian Arntzen
e1acbd3dcf MSL: Declare struct type explicitly.
Disambiguates initializer list.
2019-10-26 16:21:46 +02:00
Hans-Kristian Arntzen
27d6d45671 MSL: Rewrite tessellation_access_chain.
To support loading array of array properly in tessellation, we need a
rewrite of how tessellation access chains are handled.

The major change is to remove the implicit unflatten step inside
access_chain which does not take into account the case where you load
directly from a control point array variable.

We defer unflatten step until OpLoad time instead.
This fixes cases where we load array of {array,matrix,struct}.

Removes the hacky path for MSL access chain index workaround.
2019-10-26 16:10:12 +02:00
Hans-Kristian Arntzen
d1479f871a MSL: Do not generate UnsafeArray<> for any array inside buffer objects.
This avoids a lot of huge code changes.
Arrays generally cannot be copied in and out of buffers, at least no
compiler frontend seems to do it.

Also avoids a lot of issues surrounding packed vectors and matrices.
2019-10-24 12:22:30 +02:00
Lukas Hermanns
7ad0a84778 Updates for pull request #1162 2019-09-24 14:35:25 -04:00
Lukas Hermanns
cb3ecb9e1b Updated reference Metal shaders. 2019-09-17 15:11:19 -04:00
Mark Satterthwaite
564cb3c08d Update the Metal shaders to account for changes in the shader compilation. 2019-09-11 15:06:05 -04:00
Thomas Roughton
91b2f34a3d Update tests to account for all non-entry-point functions being inlined 2019-08-30 09:39:06 +12:00
Hans-Kristian Arntzen
461f1506e7 Do not eagerly invalidate all active variables on a branch.
This is not necessary, as we must emit an invalidating store before we
potentially consume an invalid expression. In fact, we're a bit
conservative here in this case for example:

int tmp = variable;
if (...)
{
    variable = 10;
}
else
{
    // Consuming tmp here is fine, but it was
    // invalidated while emitting other branch.
    // Technically, we need to study if there is an invalidating store
    // in the CFG between the loading block and this block, and the other
    // branch will not be a part of that analysis.
    int tmp2 = tmp * tmp;
}

Fixing this case means complex CFG traversal *everywhere*, and it feels like overkill.

Fixing this exposed a bug with access chains, so fix a bug where expression dependencies were not
inherited properly in access chains. Access chains are now considered forwarded if there
is at least one dependency which is also forwarded.
2019-07-24 11:17:30 +02:00
Michael Barriault
d6754c5713 Fix tests for device->constant address space change in MSL tessellation control shader generation. 2019-04-10 18:37:04 +01:00
Chip Davis
a43dcd7b99 MSL: Return early from helper tesc invocations.
Return after loading the input control point array if there are more
input points than output points, and this was one of the helper
invocations spun off to load the input points. I was hesitant to do this
initially, since the MSL spec has this to say about barriers:

> The `threadgroup_barrier` (or `simdgroup_barrier`) function must be
> encountered by all threads in a threadgroup (or SIMD-group) executing
> the kernel.

That is, if any thread executes the barrier, then all threads must
execute it, or the barrier'd invocations will hang. But, the key words
here seem to be "executing the kernel;" inactive invocations, those that
have already returned, need not encounter the barrier to prevent hangs.
Indeed, I've encountered no problems from doing this, at least on my
hardware. This also fixes a few CTS tests that were failing due to
execution ordering; apparently, my assumption that the later, invalid
data written by the helpers would get overwritten was wrong.
2019-02-24 12:17:47 -06:00
Chip Davis
eb89c3a428 MSL: Add support for tessellation control shaders.
These are transpiled to kernel functions that write the output of the
shader to three buffers: one for per-vertex varyings, one for per-patch
varyings, and one for the tessellation levels. This structure is
mandated by the way Metal works, where the tessellation factors are
supplied to the draw method in their own buffer, while the per-patch and
per-vertex varyings are supplied as though they were vertex attributes;
since they have different step rates, they must be in separate buffers.

The kernel is expected to be run in a workgroup whose size is the
greater of the number of input or output control points. It uses Metal's
support for vertex-style stage input to a compute shader to get the
input values; therefore, at least one instance must run per input point.
Meanwhile, Vulkan mandates that it run at least once per output point.
Overrunning the output array is a concern, but any values written should
either be discarded or overwritten by subsequent patches. I'm probably
going to put some slop space in the buffer when I integrate this into
MoltenVK to be on the safe side.
2019-02-07 08:51:22 -06:00