MSL: Adjust BuiltInWorkgroupId for vkCmdDispatchBase().
This command allows the caller to set the base value of
`BuiltInWorkgroupId`, and thus of `BuiltInGlobalInvocationId`. Metal
provides no direct support for this... but it does provide a builtin,
`[[grid_origin]]`, normally used to pass the base values for the stage
input region, which we will now abuse to pass the dispatch base and
avoid burning a buffer binding.
`[[grid_origin]]`, as part of Metal's support for compute stage input,
requires MSL 1.2. For 1.0 and 1.1, we're forced to provide a buffer.
(Curiously, this builtin was undocumented until the MSL 2.2 release. Go
figure.)
07bb1a5...
by
Hans-Kristian Arntzen <email address hidden>
Merge pull request #1089 from KhronosGroup/msl-packing-refactor
MSL: Refactor buffer packing logic from ground up.
d90eedd...
by
Hans-Kristian Arntzen <email address hidden>
Fix some typos in comments.
c62503b...
by
Hans-Kristian Arntzen <email address hidden>
Do not attempt to pack types which are already scalar.
4bc8729...
by
Hans-Kristian Arntzen <email address hidden>
HLSL query lod cleanups.
461f150...
by
Hans-Kristian Arntzen <email address hidden>
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.
18bcc9b...
by
Hans-Kristian Arntzen <email address hidden>
Do not disable temporary forwarding when we suppress usage tracking.
This subtle bug removed any expression validation for trivially swizzled
variables. Make usage suppression a more explicit concept rather than
just hacking off forwarded_temporaries.
There is some fallout here with loop generation since our expression
invalidation is currently a bit too naive to handle loops properly.
The forwarding bug masked this problem until now.
If part of the loop condition is also used in the body, we end up
reading an invalid expression, which in turn forces a temporary to be
generated in the condition block, not good. We'll need to be smarter
here ...
8ba0507...
by
Hans-Kristian Arntzen <email address hidden>
Add another test for unpacking without load forwarding.
