Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

iOS simulator initialization failure due to Invalid Pixel Format #2353

Open
warmenhoven opened this issue Sep 26, 2024 · 6 comments · May be fixed by #2361
Open

iOS simulator initialization failure due to Invalid Pixel Format #2353

warmenhoven opened this issue Sep 26, 2024 · 6 comments · May be fixed by #2361

Comments

@warmenhoven
Copy link
Contributor

As a result of 5afeaa4, the iOS simulator crashes during vkCreateInstance:

-[MTLSimDevice minimumTextureBufferAlignmentForPixelFormat:]:2204: failed assertion `MTLPixelFormatInvalid is not supported on this device.'
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x000000010359cf30 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000103017124 libsystem_pthread.dylib`pthread_kill + 256
    frame #2: 0x000000018016c4ec libsystem_c.dylib`abort + 104
    frame #3: 0x000000018016b934 libsystem_c.dylib`__assert_rtn + 268
    frame #4: 0x000000019e9641b4 Metal`MTLReportFailure.cold.1 + 44
    frame #5: 0x000000019e93fbb4 Metal`MTLReportFailure + 420
    frame #6: 0x0000000226ef899c MTLSimDriver`-[MTLSimDevice minimumTextureBufferAlignmentForPixelFormat:] + 300
  * frame #7: 0x000000012bdc52d4 MoltenVK`MVKPhysicalDevice::initLimits()::$_0::operator()(this=0x0000600000c00188, vk=VK_FORMAT_R4G4B4A4_UNORM_PACK16) const at MVKDevice.mm:2756:29
    frame #8: 0x000000012bdc5238 MoltenVK`decltype(std::declval<MVKPhysicalDevice::initLimits()::$_0&>()(std::declval<VkFormat>())) std::__1::__invoke[abi:de180100]<MVKPhysicalDevice::initLimits()::$_0&, VkFormat>(__f=0x0000600000c00188, __args=0x000000016ce6d174) at invoke.h:344:25
    frame #9: 0x000000012bdc51e0 MoltenVK`bool std::__1::__invoke_void_return_wrapper<bool, false>::__call[abi:de180100]<MVKPhysicalDevice::initLimits()::$_0&, VkFormat>(__args=0x0000600000c00188, __args=0x000000016ce6d174) at invoke.h:411:12
    frame #10: 0x000000012bdc51b0 MoltenVK`std::__1::__function::__alloc_func<MVKPhysicalDevice::initLimits()::$_0, std::__1::allocator<MVKPhysicalDevice::initLimits()::$_0>, bool (VkFormat)>::operator()[abi:de180100](this=0x0000600000c00188, __arg=0x000000016ce6d174) at function.h:169:12
    frame #11: 0x000000012bdc4194 MoltenVK`std::__1::__function::__func<MVKPhysicalDevice::initLimits()::$_0, std::__1::allocator<MVKPhysicalDevice::initLimits()::$_0>, bool (VkFormat)>::operator()(this=0x0000600000c00180, __arg=0x000000016ce6d174) at function.h:311:10
    frame #12: 0x000000012bda5024 MoltenVK`std::__1::__function::__value_func<bool (VkFormat)>::operator()[abi:de180100](this=0x000000016ce6d3c8, __args=0x000000016ce6d174) const at function.h:428:12
    frame #13: 0x000000012bd927a4 MoltenVK`std::__1::function<bool (VkFormat)>::operator()(this= Lambda in File MVKDevice.mm at Line 2750, __arg=VK_FORMAT_R4G4B4A4_UNORM_PACK16) const at function.h:981:10
    frame #14: 0x000000012bd925a0 MoltenVK`MVKPixelFormats::enumerateSupportedFormats(this=0x000000010480a1a8, properties=0x000000016ce6d348, any=true, func= Lambda in File MVKDevice.mm at Line 2750) at MVKPixelFormats.mm:490:10
    frame #15: 0x000000012bdb1530 MoltenVK`MVKPhysicalDevice::initLimits(this=0x0000000104809a00) at MVKDevice.mm:2750:23
    frame #16: 0x000000012bdafeac MoltenVK`MVKPhysicalDevice::MVKPhysicalDevice(this=0x0000000104809a00, mvkInstance=0x000000010507a000, mtlDevice=0x0000000103d72360) at MVKDevice.mm:1916:2
    frame #17: 0x000000012bdb2aec MoltenVK`MVKPhysicalDevice::MVKPhysicalDevice(this=0x0000000104809a00, mvkInstance=0x000000010507a000, mtlDevice=0x0000000103d72360) at MVKDevice.mm:1910:22
    frame #18: 0x000000012bd0a730 MoltenVK`MVKInstance::MVKInstance(this=0x000000010507a000, pCreateInfo=0x000000016ce6d830) at MVKInstance.mm:309:35
    frame #19: 0x000000012bd1bce8 MoltenVK`MVKInstance::MVKInstance(this=0x000000010507a000, pCreateInfo=0x000000016ce6d830) at MVKInstance.mm:279:94
    frame #20: 0x000000012bcecfac MoltenVK`vkCreateInstance(pCreateInfo=0x000000016ce6d830, pAllocator=0x0000000000000000, pInstance=0x000000016ce6d828) at vulkan.mm:210:29
... [ truncated for clarity ] ...
(lldb) print mtlFmt
(MTLPixelFormat) MTLPixelFormatABGR4Unorm
@SRSaunders
Copy link
Contributor

I am experiencing the same error on the iOS Simulator using the current MoltenVK head (MVK 1.2.11):

-[MTLSimDevice minimumTextureBufferAlignmentForPixelFormat:]:2154: failed assertion 'MTLPixelFormatInvalid is not supported on this device.'

@cdavis5e
Copy link
Collaborator

cdavis5e commented Oct 2, 2024

According to OP's backtrace, it's trying to work out the maximum minimum alignment for a texel buffer (i.e. a VkBufferView), but it's getting hung up on VK_FORMAT_R4G4B4A4_UNORM_PACK16. The thing is, if we had really set the corresponding Metal format to MTLPixelFormatInvalid, the callback lambda should've returned before it even got to this point. This most likely means that Metal itself has mapped the pixel format MTLPixelFormatABGR4Unorm on the simulator to MTLPixelFormatInvalid. (For packed formats, Metal uses the opposite order from Vulkan, which can be quite confusing.)

I recall reading somewhere that MTLPixelFormatABGR4Unorm isn't available under the simulator, which I believe is because the caps there are the intersection of Mac2 and one of the Apple families. Why it isn't available even on Apple Silicon, which supports the same caps as iOS, is beyond me.

The solution, then, is to disable this format unconditionally on the simulator, even when the caps say it should be supported. We may have to disable the others before this is all through.

@aitor-lunarg
Copy link
Collaborator

The following CTS test started failing: dEQP-VK.api.buffer_view.access.uniform_texel_buffer.b4g4r4a4_unorm_pack16

I have yet to look at the reason for why it fails since I just run into this failure yesterday, so unsure if it may be related or not. I will eventually get to it this week. I recall there was some kind of limitation on having texel buffers for this format, so that may be the cause. I need to double check once I dig into the CTS failure.

@SRSaunders
Copy link
Contributor

Empirically this is what I had to do in MVKPixelFormats.mm:

#	if MVK_IOS && MVK_OS_SIMULATOR
#		define MTLPixelFormatR8Unorm_sRGB			MTLPixelFormatInvalid
#		define MTLPixelFormatRG8Unorm_sRGB			MTLPixelFormatInvalid
#		define MTLPixelFormatB5G6R5Unorm			MTLPixelFormatInvalid
#		define MTLPixelFormatA1BGR5Unorm			MTLPixelFormatInvalid
#       	define MTLPixelFormatABGR4Unorm         		MTLPixelFormatInvalid
#	endif

With this change I can load MVK 1.2.11 on the iOS Simulator. Not sure if the #ifdef condition is strictly correct, or if it should be nested inside #if MVK_IOS_OR_TVOS, i.e. does the TVOS Simulator also need this change?

@warmenhoven
Copy link
Contributor Author

does the TVOS Simulator also need this change?

Yes it does.

@SRSaunders SRSaunders linked a pull request Oct 2, 2024 that will close this issue
Open
@SRSaunders
Copy link
Contributor

I have added a PR that addresses this issue for my test cases. Perhaps @warmenhoven could test as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Disable unsupported Metal Pixel formats for iOS/tvOS Simulator SRSaunders/MoltenVK
4 participants
@warmenhoven @cdavis5e @SRSaunders @aitor-lunarg