Yes, I ended up using the draw stage boundaries around all of our renderPasses, and on iOS I use the stage boundary calls. I thought I was going to have to set draw boundary data on each draw call, but the draw stage boundaries were really just a timestamp to inject into the command stream. The WWDC video was helpful. MTLParallelRenderCommandEncoders weren't supported, but was able to define timers around the sub-encoders on those. It was a ton of code and tricky to support both macOS and iOS, and I had to deal with 3 different encoders, and adjusting the timestamps on macOS Intel. It's done now and working at least for macOS 11+ and iOS 14+. Also should solve M1 timings.

Could stage boundary and depthClamp support (which docs erroneously list as family v4_1 instead of v2_4 in the docs) be put onto the Metal Feature Set docs, so I don't waste time writing workarounds for missing functionality.

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.

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

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.

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