vsgtexturearray crashes on MacOS 12.5 about vsgexamples

[robertosfield]

Is this an immediate failure? Does it crash?

I just tried it on my Kubuntu 21.10 AMD5700G system and it runs without any warnings.

[rainergericke]

Yes it flashes the window and crashes. It was functional some weeks ago. The problem is also there on Vulkan 1.3.211. Vulkan 1.3.211 can also be replaced by SwiftShader. With SwiftShader it works normally.

[robertosfield]

On Fri, 29 Jul 2022 at 10:11, Rainer Gericke ***@***.***> wrote: Yes it flashes the window and crashes. It was functional some weeks ago. The problem is also there on Vulkan 1.3.211. Vulkan 1.3.211 can also be replaced by SwiftShader. With SwiftShader it works normally.

Do you have any idea what changed in the last few weeks? It may have worked thanks to slightly different timing rather than anything functionally different in the VSG or Vulkan, in which case it might eventually appear on other platforms too. What is SwiftShader?

…

Message ID: ***@***.***>

[rainergericke]

SwiftShader is CPU based Vulkan implementation, actually on Level 1.3.211. It can be used on Machines with no Vulkan driver for their GPU.
https://swiftshader.googlesource.com/SwiftShader/
I can go back in time and see, if the functionality comes back with older commit states.

[robertosfield]

On Fri, 29 Jul 2022 at 10:19, Rainer Gericke ***@***.***> wrote: SwiftShader is CPU based Vulkan implementation, actually on Level 1.3.211. It can be used on Machines with no Vulkan driver for their GPU. https://swiftshader.googlesource.com/SwiftShader/

Thanks for the link. This might indicate a bug in the Vulkan driver, or just timing differences.

I can go back in time and see, if the functionality comes back with older commit states.

git bisect can be really helpful for this time of work. Running a single frame and capturing the API debug layer output can be helpful when figuring out what has changed to cause problems - so you run with -a before the breaking change, then with -a after the breaking change. A difference between the two runs then might help pinpoint the problematic changes, then you can step back to the associated VSG code.

…

Message ID: ***@***.***>

[rainergericke]

Thank you for the hints. I could not find a working configuration yet. I remember last friday, when Apple published the MacOS update from 12.4 to 12.5. After this update loading a wavefront file with vsgviewer or vsgconv took about 15 times longer than before. During these days there were no commits pushed for vsg & co. Btw as soon the wavefront file is converted to vsgb/t, the loading time is normal again. I read somewhere, the MacOS update made change in the graphics initialization. It could be a MacOS reason for this issue.

[robertosfield]

@rainergericke what is the present status of vsgtexturearray on macOS?

[rainergericke]

It crashes:
vsgtexturearray -d
[mvk-error] VK_ERROR_DEVICE_LOST: MTLCommandBuffer "vkQueueSubmit CommandBuffer on Queue 0-0" execution failed (code 3): Caused GPU Address Fault Error (0000000b:kIOGPUCommandBufferCallbackErrorPageFault)
VUID-vkDestroySemaphore-semaphore-01137(ERROR / SPEC): msgNum: -1588160456 - Validation Error: [ VUID-vkDestroySemaphore-semaphore-01137 ] Object 0: handle = 0x1530f3218, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xa1569838 | Cannot call vkDestroySemaphore on VkSemaphore 0xf9a524000000009e[] that is currently in use by a command buffer. The Vulkan spec states: All submitted batches that refer to semaphore must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.224.1/mac/1.3-extensions/vkspec.html#VUID-vkDestroySemaphore-semaphore-01137)
Objects: 1
[0] 0x1530f3218, type: 3, name: NULL
VUID-vkDestroyFramebuffer-framebuffer-00892(ERROR / SPEC): msgNum: -617577710 - Validation Error: [ VUID-vkDestroyFramebuffer-framebuffer-00892 ] Object 0: handle = 0x1530f3218, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xdb308312 | Cannot call vkDestroyFramebuffer on VkFramebuffer 0xfc68dd000000009f[] that is currently in use by a command buffer. The Vulkan spec states: All submitted commands that refer to framebuffer must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.224.1/mac/1.3-extensions/vkspec.html#VUID-vkDestroyFramebuffer-framebuffer-00892)
Objects: 1
[0] 0x1530f3218, type: 3, name: NULL
libc++abi: terminating with uncaught exception of type vsg::Exception
zsh: abort vsgtexturearray -d

[robertosfield]

Is the failure the mode still the same as you originally reported?

The debug layer reports suggest that it's an issue during clean up on exiting the vsgtexturearray. In theory the VSG ownership hierachy of Vulcan related objects should prevent destruction of the vkDevice while other Vulkan objects still use it - though this scheme does assume the vsg::Device/vkDevice is valid till it's destructed as it would normally be.

[rainergericke]

Yes it is the same failure. Replacing vulkan by SwiftShader (Vulkan Emulation) makes the example work again, like before.

[robertosfield]

On Wed, 12 Oct 2022 at 12:55, Rainer Gericke ***@***.***> wrote: Yes it is the same failure. Replacing vulkan by SwiftShader (Vulkan Emulation) makes the example work again, like before. Can this be chalked up as a driver issue then? Is there anything that we

can do in the VSG or vsgExamples to address the problem?

…

Message ID: ***@***.***>

[rainergericke]

Yes, it might be a driver problem. If the example works on Windows, Linux and on SwiftShader, the vsg code cannot be too bad.

[rainergericke]

Actually this problem is not urgent, because the effect of texture arrays can also be achieved by texture repeating. If you want, just close this issue.

[robertosfield]

I'll close this Issue as the VSG code and shaders all look correct and don't produce any validation errors, the issue looks like it's a driver one. Thanks for the patience with testing.