Formats that are guaranteed to be supported are seemingly not supported
HalfVoxel opened this issue · comments
Hi
First I have to say: awesome work on this library!
I was running into an issue running the teapot example on mac (10.11.6) using MoltenVK with the GTX 970 graphics card.
According to the documentation
For depth images, only D16Unorm is guaranteed to be supported. For depth-stencil images, it is guaranteed that either D24Unorm_S8Uint or D32Sfloat_S8Uint are supported.
However the teapot program crashes with the error FormatNotSupported. Looking at the code I see that D16Unorm is used in several places for the depth buffer. Changing this to D32Sfloat makes everything work well, but I was curious if someone knows what this inconsistency stems from. Is this my graphics card actually not supporting that format (which seems odd, given that gtx 970 is a pretty good graphics card, I haven't actually been able to find any info about this. The OpenGL extension viewer lists the 16 bpp depth buffer mode as being supported though, which may or may not be identical, I don't really know). Or is it some bug in Vulkano? Or is it something in MoltenVK perhaps?
D16Unorm is only guaranteed when is VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT enabled. https://vulkan.lunarg.com/doc/view/1.0.30.0/linux/vkspec.chunked/ch31s03.html
Either vulkano isnt checking if the required feature is enabled before using depth stencils or the moltenVK isnt compliant to the spec. I think vulkano being at fault is definitely the most likely, cant look into it right now though.
It seems D16Unorm requires macOS 10.12, because MTLPixelFormatDepth16Unorm was added in 10.12:
https://github.com/KhronosGroup/MoltenVK/blob/2444dfee3728bdc4eda566084c6069a98c8f42c7/MoltenVK/MoltenVK/Vulkan/mvk_datatypes.mm#L355
Ah. Nice catch @galad87. Seems like that must be the reason.
Would it be reasonable if I made a pull request to the examples so that they try to find the best supported format to use (≈10 lines of code or something like that) ? Or do you prefer to keep them as simple as possible?
I'm not letting platform specific hacks into the examples.
Hack is a strong word for this case, because we are just being more careful then we need to be, but its still debt I don't want to accumulate.