Thanks for your detailed responses.
After reviewing this closely, I realize the issue arises specifically from a compute pipeline implicitly dispatching threadgroups with a dimension of (32,32,1), exceeding the maximum allowed (832 threads per threadgroup) on Vision Pro devices.
Following your suggestions, I've explicitly checked all compute pipelines in my project and verified the maxTotalThreadsPerThreadgroup property. However, I am not using MTLComputePipelineDescriptor; instead, I'm using MTLRenderPipelineDescriptor and MTLTileRenderPipelineDescriptor. I've ensured all my render shaders explicitly define threadgroup dimensions that comply with the maxTotalThreadsPerThreadgroup constraint, adjusting them to (16,16,1) to stay within safe limits.
Despite these adjustments, the problem persists intermittently. Is there any known caching behavior or implicit threadgroup sizing performed by visionOS or Metal that could be causing the default value of (32,32,1) to resurface? Additionally, are there specific considerations or constraints for tile-based shaders or render pipelines in visionOS 26 compared to visionOS 2.0?
Thanks again for your support!
Topic:
Spatial Computing
SubTopic:
ARKit
Tags: