Hi! I am currently trying to upload my iOS app to App Store Connect. Unfortunately, code signing fails with the following error: "Code object is not signed at all.", referencing a binary Metallib (created with metal-tt and an mtlp-json script). I am using Xcode's automatically managed signing and the binary metallib is located inside the "Resources" directory of a framework that I am including with "Embed and sign" in the app. Could anyone give some guidance on what I need to change to make code signing work? Thank you.

Follow-up to this post. I decided to start a new post as I no longer consider the problem to be solved and would be thankful for further help. Due to a mistake in the implementation, I previously believed that the issue was completely solved by disabling Metal API Validation. Although it helped a bit, the total additional memory consumption of the app after creating 1860 PSOs from a binary archive (even higher when compiled on device) is still about 180 MB, while the resource size per PSO in the Metal memory panel is about 2 KB. The measurements of the total increase were made in release mode, as shown by the Graphics HUD on iPad and Activity Monitor on Mac. Any help regarding this problem would be greatly appreciated.

Hi! My app requires a large number (>1500) of permutations of a specific shader and therefore has to create many pipeline state objects. With precompiled binary archives, the time to create these objects on app load is not really a problem, however the memory footprint is higher than I would expect. In a frame capture, the allocated size for each pipeline state is stated as 2 KB, but the overall memory consumption of the app increases by almost 200 MB. Am I making a mistake during pipeline state creation? Or is there a technique to reduce the size? On a side note: the PSOs are only used in an indirect command buffer. I assume the answer is no, but is it allowed to deallocate the PSOs after they have been set in a command in the ICB as a workaround?

Hi! I am currently trying to solve an issue with my use of indirect command buffers and would appreciate your help. I have set up a minimal example project that encodes a draw call into the ICB on the CPU and then executes the commands of the ICB as part of the main render command encoder. In the corresponding fragment shader, I am reading a value from a buffer and simply returning it. ICB setup: indirectCommandBuffer = { let descriptor = MTLIndirectCommandBufferDescriptor() descriptor.commandTypes = [.draw] descriptor.inheritBuffers = false descriptor.inheritPipelineState = false descriptor.maxVertexBufferBindCount = 0 descriptor.maxFragmentBufferBindCount = 1 descriptor.maxKernelBufferBindCount = 0 return device.makeIndirectCommandBuffer(descriptor: descriptor, maxCommandCount: 1, options: .storageModeShared)! }() indirectCommandBuffer.reset(0..<1) let command = indirectCommandBuffer.indirectRenderCommandAt(0) command.setFragmentBuffer(colorBuffer, offset: 0, at: 0) command.setRenderPipelineState(mainRenderPipelineState) command.drawPrimitives(.triangle, vertexStart: 0, vertexCount: 6, instanceCount: 1, baseInstance: 0) Fragment shader: fragment half main_fragment(constant float& color [[buffer(0)]]) { return half(color); } Execution: let commandBuffer = commandQueue.makeCommandBuffer()! let mainRenderPassDescriptor = MTLRenderPassDescriptor() mainRenderPassDescriptor.colorAttachments[0].texture = mainTarget mainRenderPassDescriptor.colorAttachments[0].loadAction = .clear mainRenderPassDescriptor.colorAttachments[0].clearColor = MTLClearColor(red: 0, green: 0, blue: 0, alpha: 0) mainRenderPassDescriptor.colorAttachments[0].storeAction = .store let mainRenderCommandEncoder = commandBuffer.makeRenderCommandEncoder(descriptor: mainRenderPassDescriptor)! mainRenderCommandEncoder.useResources([colorBuffer], usage: [.read], stages: [.fragment]) mainRenderCommandEncoder.executeCommandsInBuffer(indirectCommandBuffer, range: 0..<1) mainRenderCommandEncoder.endEncoding() commandBuffer.commit() However, when I run the program with shader validation enabled, I get the following error: Render Encoder "0x600000d1cc60" has missing Fragment Buffer (color) binding at index 0 for RenderPipelineState "Main". Thank you for your help!

Hey! In the last couple of days, I have received multiple crash reports from users during the startup sequence of my app. The underlying issue seems to arise during a call to makeComputePipelineState, which fails with the following error message: Inlining all functions due to use of indirect argument bufferEncountered unlowered function call to air.get_threads_per_simdgroup.i16 Am I right to assume that those are actually two messages that are not necessarily related? I am not quite sure what to make of the second part in particular, so any guidance would be greatly appreciated! The number of crashes has been single-digit so far, but all of them have happened on the same model: the iPad Pro (12.9-inch) (3rd generation). (Not sure if that is of any importance.)

Hi! I am currently finalizing a new app that uses Metal to render a 3D scene and a UIKit overlay to display controls for interacting with objects in the scene. The render loop is driven via a CADisplayLink with its preferredFramesPerSecond set to 60. I have recently noticed an issue where the app reports a steady 60 fps frame rate in the Xcode debug navigator, but still felt sluggish on the device. This feeling was only present on devices with ProMotion and often started after interactions with the UIKit overlay. I started investigating by using Metal System Trace and quickly found an explanation for the sluggish feeling: occasionally, the app would switch from its nominal 16ms-16ms-16ms cadence to 12ms-20ms-12ms, thus still averaging 60 fps, but with inconsistent frame times. Pictures of the timeline can be found here. I have tried setting the CAMetalLayer's presentsWithTransaction to true, waiting for the command buffer to be scheduled and then presenting the drawable, but, unfortunately, the problem persists. If anybody can think of a potential reason / solution for this, I would be very thankful.