- Delete fat library and framework scripts and templates.
- MoltenVK build package now only includes one XCFramework, and separate platform dylibs.
- Modify fetchDependencies and Makefile targets to not build fat libraries,
and to build simulators separately than platforms instead.
- Script package_moltenvk.sh now copies dylibs for all built platforms.
- Consolidate package_all.sh and delete package_one_os.sh.
- Swap names of copy_lib_to_staging.sh and copy_to_staging.sh scripts.
- Cube demo now uses MoltenVK as XCFramework, and support Simulator builds.
- Hologram demo now uses MoltenVK as dylibs from new packaging location.
- API-Samples demo now uses MoltenVK as XCFramework.
- Update documentation.
Nothing will be drawn in that case. Nothing would've been drawn anyway,
but Metal's validation layer complains if you issue a draw command with
zero vertices or instances.
We unfortunately cannot do anything about indirect draws, since we won't
know how many vertices to draw until execute time.
Prior to this, we were assuming one layer per clear rect. When that
assumption were broken, we wound up smashing the stack. This will be
more important once multiview support lands, since all views must be
cleared by the clear command.
The attachment index in the `VkClearAttachment` struct is an index into
the current subpass attachment array, not the render pass attachment
array; so it's not enough to check `VkClearAttachment` for
`VK_ATTACHMENT_UNUSED`. We also need to check the current subpass.
If no attachments can be cleared, don't encode a command to the Metal
command buffer.
Perhaps I should bring back `recordBeginRenderPass()` and
`recordEndRenderPass()` and keep track of the current subpass; then we
can avoid recording the command entirely if the intersection of the sets
"attachments to clear" and "used attachments" is null.
The current code does not handle multiple subpasses, nor does it handle
secondary command buffers. Handling subpasses was easy enough. The
problem came with secondary command buffers. Tracking them became
extremely complicated, particularly since pipelines may be set either
inside or outside a render pass, and further, a pipeline set in one
buffer might be used in another.
I then realized a simpler and more elegant solution: Metal's deferred
store actions feature. This allows you to defer setting the store action
for a render pass until encoding time. This is exactly what we need,
since we won't know what store action we actually want until we start
encoding draws. This solution should now work with multiple subpasses
and secondary command buffers, with much less code.
Create shader converters as XCFrameworks.
Don't create shader converters as fat libs, dylibs, or regular frameworks.
Rename create_xcframework.sh to create_xcframework_func.sh.
Use separate MoltenVK packaging scripts for one or all OS's.
Add package_one_os.sh.
Remove package_shader_converter_lib.sh.
Remove redundant GLSL shader converter dependencies in MoltenVK packaging targets.
Exclude arm64 architectures on macOS and Simulators.
Exclude arm64e architectures on iOS and tvOS.
Stop building fat libraries for external libraries.
Remove package_ext_libs.sh script.
Don't include Headers in ext lib XCFrameworks because of Xcode12 bug in using them.
It's a hard validation error to do so. We originally had a check for
this, but it was erroneously completely removed in #988, instead of
being limited to `renderTargetArrayLength`.
Fixes#991.
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 eliminates the extra invocations previously needed to read the
varyings from the vertex shader into the tessellation shader. 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, and further reduce underutilization of the GPU's SIMD units.
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, nor do we always have to duplicate
the index buffer to insert gaps. 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.
Since on macOS textures cannot be resident in shared (host-coherent) memory,
they need to be flushed before making the copy, to ensure that the modified
data is transferred.
fetchDependencies support option to skip all library builds.
fetchDependencies avoid sync locks if not building in parallel.
fetchDependencies build glslang headers.
Update ExternalRevisions/README.md glslang build integration section.
Update What's New.
SPIRV-Cross can now AND the `gl_SampleMask` output with an additional
fixed mask, presumably from the pipeline. Use this new functionality to
implement pipeline sample mask handling.
Special thanks to Tomek Pontika and Corentin Wallez of Google for
graciously contributing their implementation to SPIRV-Cross.
Update SPIRV-Cross to pull in the change necessary for this.
This extension provides weaker guarantees than `VK_EXT_robustness2` and
its `robustImageAccess2` feature. Metal easily meets those guarantees,
with no action on our part necessary.
