MVKPipelineLayout set auxiliary buffer MSL index relative to already-calculated
push constant buffer MSL index.
MVKPipeline destructor release auxiliary buffer MTLBuffer instance.
Nudge MVK_VERSION_PATCH.
Set `MTLPixelFormatRG11B10Float` for `VK_FORMAT_B10G11R11_UFLOAT_PACK32`
and `MTLPixelFormatRGB9E5Float` for `VK_FORMAT_E5B9R9G9_UFLOAT_PACK32`.
This should fix the rest of #302.
The swizzles are passed to shaders that need them using an "auxiliary
buffer", for which there must be room in the function argument table.
Code is inserted into the shaders to swizzle reads from sampled
textures--per the Vulkan spec, component mappings must only be applied
to sampled images.
Update SPIRV-Cross to pull in some fixes for handling swizzled image
data. Bump MoltenVK version.
The docs for the `MTLBlitCommandEncoder`'s `copyFromTexture:...` method
state that the source and destination textures must have the same
format.
This was true when it was written in the iOS 8 timeframe for Metal 1.0.
But, I suspect it was changed in Metal 1.1 when support was added for
texture views of differing formats. Like with texture views, the two
formats now need only be compatible. This is the same behavior that
Vulkan prescribes.
Some clients always set blend state for all eight attachments, even if
the attachments are unused. Since the attachments are unused, the
expectation is that the corresponding blend states won't matter. But in
Metal, there's no way to tell if an attachment won't be used. So, if you
enable blending on an unused attachment, its pixel format will be
`MTLPixelFormatInvalid`, which doesn't support blending; Metal will
assert on this.
Use `MTLVertexFormatUInt1010102Normalized`. This is the unsigned
equivalent to the signed `MTLVertexFormatInt1010102Normalized`, which we
already use for `VK_FORMAT_A2B10G10R10_SNORM_PACKED`.
According to the Vulkan spec, linear-tiled images *may* not be supported
unless certain restrictions are satisfied. That means that
implementations may support features--or restrictions--above and beyond
the restrictions given in the Vulkan spec.
Metal places these limitations on linear textures:
* They must be 2D.
* They may only have one mip level.
* They may only have one array layer.
* They may not be multisampled--sample count must be one.
* On macOS, they may not be used as attachments.
* They may not be depth/stencil textures.
* They may not have a compressed format.
Have `vkGetPhysicalDeviceFormatProperties()` and
`vkGetPhysicalDeviceImageFormatProperties()` return results consistent
with these constraints. Also, allow creation of linear textures with
usages other than `VK_IMAGE_USAGE_TRANSFER_{SRC,DST}_BIT`.
Otherwise, if the resource is destroyed first (which it almost always
will be), then when the `VkDeviceMemory` is freed, it will access a
freed resource, at which point it will then proceed to fandango on core.
Update SPIRV-Cross to support dynamic indexing on iOS 10... and to
actually support arrays of input buffers (which should've been present
before I flipped the `shader{Uniform,Storage}BufferArrayDynamicIndexing`
switch).
Bump patch version.
Fixes#96.
Metal currently requires at least one attachment, in order to define the
size of the render target area (and thus, how many times to run the
fragment shader). Vulkan, however, allows specifying no attachments. In
that case, the size of the render target area comes from the extent and
layer count of the framebuffer object. Since Metal doesn't let you (at
least on macOS) define the render target area without an attachment, we
have to supply a dummy attachment that will be discarded once rendering
is complete.
When possible, the render target uses the memoryless storage mode,
falling back to private when that isn't supported. It is marked as
volatile, and its load and store actions are set to "don't care." The
texture is retained for the lifetime of the subpass.
Copying the results could block if the client said to wait. If this
completion handler runs before the one that actually finishes the
queries--and it will if it's scheduled first--it will block
indefinitely, causing a deadlock. Instead, run this on a different
dispatch queue; then the query will be allowed to finish.
Now when we set up the `MTLRenderPassAttachmentDescriptor` for the 3D
texture, we set the `depthPlane` property instead of the `slice`
property. Combined with an appropriate setting for
`renderTargetArrayLength` in the base descriptor, this allows rendering
to a subset of a 3D texture.
These properties were introduced in Metal 2.0 on iOS. (They don't exist
yet on Mac.) Currently, they are only used to constrain the size of the
render target area. Perhaps someday, they may be used to support render
passes with no render target attachments. For now, though, Metal doesn't
support that.
We already support this extension. The enumerant added by this extension
is already mapped to its Metal equivalent. Only advertise the extension
on macOS, though. iOS doesn't support this.
It's not convenient to get the usage out of the `pCreateInfo`, since
it's tucked away in an extension struct. (Unfortunately, I had assumed
we were already doing this...)
We don't really restrict which usages you can request on an image, so
the `VK_IMAGE_CREATE_EXTENDED_USAGE_BIT` doesn't really apply to us.
Since we don't yet support tessellation, we don't support
`VkPipelineTessellationDomainOriginStateCreateInfo`, either. Finally,
as near as I can tell, we don't really do anything with input
attachments, so any `VkRenderPassInputAttachmentAspectCreateInfo` will
be ignored.
I'm not sure if creating image views of compressed images using an
uncompressed format will work. Metal's docs say texture views between
any two color formats of the same size will work, but they also
specifically call out converting between sRGB and non-sRGB compressed
formats, which implies that, say, creating an `RG32Uint` view on a
`BC1_RGBA` texture may not work. Thus, I've logged any uses of the
`VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT`.
We don't actually do anything with the extension struct, but that's OK;
it's just an optimization hint anyway. I'm not sure what we'd do with
this information. It's intended to enable implementations to better
optimize image layouts, but that's under Metal's control in MoltenVK.
