Just increase the instance count and multiply that by your vertex count. When it fails, then you know how big the buffer is.

So I did finally get time to write a test case and newLibraryWithData did indeed hotload. In the engine, it looks like the render/compute pipelines were not reset to point to the new MTLFunction. That's why the old shaders were used despite recompiling and replacing them with new MTLFunction objects. The URL load path should still be fixed to test modstamp and/or hash of each shader. And some path to update the shaders on existing render/compute pipelines would be helpful. Maybe this will save others some pain. I also have hotloading in my ktx/ktx2 tool called kram. Shader hotloading should be a pervasive part of all Apple demos, but I never see it used anywhere.

This also produces an "API is not supported" message on A7/A8 hardware. I guess the indirect draw calls were only introduced on the A9 series. So this isn't going to work for our 5S or 6 devices.

Am I misunderstanding this call. I see it used in MoltenVK. Does the drawIndexedPrimitives call only draw one indirect draw call out of the buffer at the offset? Is that why the "count" is missing. So I need to call it multiple times for each of my drawCounts. If so, then I might be able to salvage what I have.

Also when I looked into ICB's, they lock down all sorts of pipeline data and have a raster pipeline state inheritance model that makes them unusable except in that Apple sample code. Here I just want to record draws either on the CPU or GPU, and control the draw count of multiple index buffer ranges. We also target iOS9, but the ICB calls seem to be iOS12/13 level.

ICB's are only available on A9+, so that's why I was adopting the ID and not ICB calls. Our game title supports A7+. And yes, the ICB's have a range so I don't understand why the ID calls don't. And there's no sample code on how to use indirect draw that I've found. This is a simple use case of trying to collect disjoint index buffer offsets/sizes for draws into a series of indirect draw calls. That way it's a single draw call instead of 1000. The materials are all the same for a given range of ID submissions to the buffer. Without a count, one can't even accumulate different materials. Drawing 8 materials with an offset of 0, then 10 with an offset of 8 draws into the same MTLBuffer of size 80 draws, results in drawing 80 and then 72 indirect draws. But I need 8 and then 10.

And here's the D3D12 call that is similar. It has MaxCommandCount void ExecuteIndirect( ID3D12CommandSignature *pCommandSignature, UINT MaxCommandCount, <- ID3D12Resource *pArgumentBuffer, UINT64 ArgumentBufferOffset, ID3D12Resource *pCountBuffer, UINT64 CountBufferOffset );

https://feedbackassistant.apple.com/feedback/9188429

Yes, this makes it hard to visually and performance tune games. Here's the feedback link. https://feedbackassistant.apple.com/feedback/9149476

Our hotloading, for better or worse, builds a metallib per vert/frag file. Then when that file changes or any dependencies, a new metallib is built and we load that one. The problem is that we hand this data off to Metal and it doesn't run it. Previously, I saw this problem even with a single metallib containing all the shaders. The Metal shader cache doesn't test for modification date on the library, or do any hash tests on the shader content. So it sees the same named library, and returns the old version not the new one. So then the old shaders are return over and over again. There is already a Radar on this issue. I'll try to build a sample app that demonstrates this. Not being able to hotload shaders is quite limiting and unique to the Metal api.

This is on macOS Big Sur 11.2.3, but was broken 2 or 3 macOS ago when I first hit this. I think the workaround is to somehow load the library from memory, but I thought that's what newLibraryWithData did.

Edit: That's nil on first load of the shader, ...

https://feedbackassistant.apple.com/form-response/18663156

https://feedbackassistant.apple.com/feedback/9119311

This problem still happens with an iPad Air3 and Xcode 12.4 connected via a physical cable. Can this issue be fixed? There's a long history on Stack Overflow of this bug happening, and not being fixed since Xcode 6. The device loses a connection, and then Xcode reports that the device is locked even when unplugged and plugged back in. The device is unlocked before and after the replug. This happens pretty easily when bumping a cable connected to a usb-c port that then loses the connection, and when the app is relaunched Xcode thinks it's locked. The only workaround is to quit Xcode and restart it, but fixing the bug would avoid this. The only way I've found to fix it and keep Xcode up is to unpair the device and re-trust it again.