MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.
Apache License 2.0
4.63k
stars
402
forks
source link
fragmentShaderBarycentric reports as true without complete SPIR-V to MSL support #2258
When testing the fragment_shader_barycentric sample from the official Khronos Vulkan Sample repository (https://github.com/KhronosGroup/Vulkan-Samples), I receive the following errors:
[mvk-error] SPIR-V to MSL conversion error: Cannot declare both BaryCoordNV and BaryCoordNoPerspNV in same shader in MSL.
[mvk-error] SPIR-V to MSL conversion error: PerVertexKHR decoration is not supported in MSL.
My device reports fragmentShaderBarycentric = true, and while it allows the sample to startup it eventually fails on the above MSL conversion errors. The spec says the following:
fragmentShaderBarycentric indicates that the implementation supports the BaryCoordKHR and BaryCoordNoPerspKHR SPIR-V fragment shader built-ins and supports the PerVertexKHR SPIR-V decoration on fragment shader input variables.
So my question is why does MoltenVK report fragmentShaderBarycentric = true, when the implementation is incomplete and violates the spec? Perhaps this should instead return false, and let the developer choose to proceed only based on known limitations of this feature on MoltenVK. Or have you taken the opposite approach, i.e. return true but expect the developer to investigate the known limitations on MoltenVK and write code to support only the working cases?
When testing the fragment_shader_barycentric sample from the official Khronos Vulkan Sample repository (https://github.com/KhronosGroup/Vulkan-Samples), I receive the following errors:
[mvk-error] SPIR-V to MSL conversion error: Cannot declare both BaryCoordNV and BaryCoordNoPerspNV in same shader in MSL. [mvk-error] SPIR-V to MSL conversion error: PerVertexKHR decoration is not supported in MSL.
My device reports
fragmentShaderBarycentric = true, and while it allows the sample to startup it eventually fails on the above MSL conversion errors. The spec says the following:fragmentShaderBarycentric indicates that the implementation supports the
BaryCoordKHRandBaryCoordNoPerspKHRSPIR-V fragment shader built-ins and supports thePerVertexKHRSPIR-V decoration on fragment shader input variables.So my question is why does MoltenVK report
fragmentShaderBarycentric = true, when the implementation is incomplete and violates the spec? Perhaps this should instead return false, and let the developer choose to proceed only based on known limitations of this feature on MoltenVK. Or have you taken the opposite approach, i.e. return true but expect the developer to investigate the known limitations on MoltenVK and write code to support only the working cases?