Using MVKImage's getLayerCount() to initialize layerCount of an MVKImageView's subresourceRange breaks down for 3D images with 3D image views.

[hideyhole]

MVKImage's getLayerCount() function effectively treats a 3D texture as a 2D texture array and returns a count > 1 for such textures. This is useful in certain scenarios, such as calculating the total size occupied by a buffer that would hold the raw bytes of a 3D texture (such as in MVKImage's constructor) or an offset into such a buffer (such as in MVKImage::initSubresourceLayout()).

During construction of an MVKImageView, the layerCount member of its subresourceRange object is initialized in part using a call to this function, if the subresourceRange.layerCount of the incoming VkImageViewCreateInfo is VK_REMAINING_ARRAY_LAYERS. This breaks down for 3D images with 3D image views because the layerCount will be > 1 for such image views, which is invalid, and causes an assertion failure in the call to MTLTexture's newTextureViewWithPixelFormat in MVKImageView::newMTLTexture().

The same should be true for MVKImage::applyImageMemoryBarrier, if the vkCmdPipelineBarrier that triggers it is passed a VkImageMemoryBarrier that has VK_REMAINING_ARRAY_LAYERS for its subresourceRange.levelCount. I believe that would cause a validation failure in BlitCommandEncoder's synchronizeTexture.

[billhollings]

@hideyhole This is now fixed in PR #127. Please retest and close this issue.