I've stepped through to verify that I have MTL::Buffer objects for each index buffer, but when I capture the GPU frame it just reads "indexBuffer: Null" for each draw. Is this just a bug? I'm guessing so as some of the geometry is appearing correctly.

I'm not sure if this is somehow a cadence issue or something. If I attempt to use the stylized M button in Xcode to kick off a GPU capture on iOS it seems to just go on forever capturing command buffers instead of exiting when we swap to the next display surface. We are presenting the current drawable with presentDrawable and invoking nextDrawable on the MetalLayer (but note that we are doing this by extending it to be supported from C++). If I trigger and end the capture myself it works fine, and so that works for now, but I'm curious if I'm doing something wrong that causes it not to recognize the end of frame correctly for the Xcode GUI version.

Not quite understanding these. As far as I can tell the Foundation, QuartzCore and Metal frameworks are included in the link line: -framework Metal -framework QuartzCore -framework Foundation Technically they are in there a few times. Not familiar enough with our project to know why. Getting a ton of undefined symbols. Metal-cpp is a header only library and so doesn't have any additional libraries of it's own right? Undefined symbols for architecture arm64: "MTL::Private::Selector::s_knewTextureViewWithPixelFormat_textureType_levels_slices_swizzle_", referenced from: "MTL::Private::Selector::s_knewTextureWithDescriptor_", referenced from: "NS::Private::Selector::s_kinit", referenced from: "NS::Private::Selector::s_kautorelease", referenced from: This is while compiling for iOS (thus the arm64).

I'm at the point where I seem to be running a very simple render loop (inside of a very complex project) and having fun trying to figure out what isn't actually functioning. It seems like the documentation online might be slightly out of date as when I try to look for a way to do a frame capture I am only presented with "Capture GPU Workload" and a little "M" icon instead of the documented "Capture GPU Frame" and a "camera" icon. My assumption is it was just renamed as it could potentially include other GPU work not directly related to rendering. I've changed my project settings to explicitly capture Metal rather than Automatic, but that didn't really seem to change anything. I've verified the broad strokes of my rendering which roughly matches the Mac example of drawing a simple triangle. The only significant difference is that I immediately reclaim the MTL::CommandBuffer with an autoRelease after the commit. Does that seem fine? When I capture I am told that: "No GPU commands have been captured. At least one command buffer must be created and committed within the boundaries of a GPU Capture." Not sure if there is some sort of implicit frame tracking that I am somehow violating. In terms of the rough order of things being done for the rendering: renderCommandEncoder() setRenderPipelineState() drawIndexedPrimitives() endEncoding() presentDrawable() commit() Oops, almost forgot to mention the reason for my title which is that metal-cpp only seems to come with Mac examples. Are there any iOS examples for metal-cpp?

We are converting some shaders from HLSL to Metal using dxc to compile to spir-v and then spirv-cross to convert to .metal. The output looks pretty reasonable to me although I am still a newbie to .metal. This is all happening on a PC using the Metal tools for Windows. On iOS when I load the first vertex shader it looks reasonable and the input attributes are reflected in both the vertex attributes and also the general attributes. However, when I then attempt to load the fragment shader it finds the function successfully, but both the vertex attributes and stage input attributes are non-existent (obviously expected for the vertex attributes). I've taken a look at the .metal file and it seems to be doing the correct thing. It has multiple inputs to the function, none of which seem to be reflected. We are compiling the functions independently as it would be somewhat non-trivial in our code base to compile them into a single library, but my fear is that somehow it is unhappy about this.

We are trying to develop an offline tool for creating sets of textures on the Mac for iOS, but mirroring our existing stuff for other platforms. One thing we ran into is that our current stuff stores the alignments as part of the texture set data, but it appears like there is not way to, say, ask Metal to give us the texture alignment on a given family of iOS GPU without actually running on that hardware. Does that seem like an accurate assessment? I feel like we will probably need to rejigger our stuff to instead query the alignment after we have created the MTLTextureDescriptor objects (currently it happens in the opposite order). Or maybe it's fairly straight-forward to just understand all of the alignment restrictions that we can expect on iOS to begin with? Since these are offline texture assets they will mostly just be a combination of 2D static textures, although there will probably be some cubemaps and 3D textures.

I was watching the Metal-cpp video which mentions a C++ smart pointer wrapper to handle reference counting in Metal objects. I've been trying to write my own and the realization that this already existed made me want to try it, but it doesn't actually seem to exist. I can't remember if I installed the beta version or not. It wasn't immediately clear to me if I can identify which version of Metal-cpp I am using by looking inside the folders. Should this exist? On a somewhat related note I am having some issues trying to call retain on an MTL::TextureDescriptor object that was originally created with MTL::TextureDescriptor::alloc()->init(). This could just be my own bug, but I was wondering if I am misunderstanding how it works. In this case we have a mid level texture class that may want to recreate itself by altering the TextureDescriptor afterwards, but in some cases that texture was also created by a higher level texture class that also may want to do it's own version of the same thing and so it seemed prudent to just share the same TextureDescriptor object.

Currently trying to figure out why our translated HLSL is failing to be able to create a .metallib. The error is: LLVM ERROR: Error opening 'C:\Program Files\Metal Developer Tools\iOS\bin\..\lib\clang\31001.630\lib\darwin\libmetal_rt_osx.a': no such file or directory! I'm invoking metal and metallib from the ios subfolder of the Windows tools, so my guess is that I also need to invoke metal with the --target argument to inform it that it is in fact an iOS target, but I have no idea where to find what the valid list of these is.