For running my app on devices with P3 screens, to take advantage of the P3 colors, which MTLPixelFormat is the proper one to use for my MTKView? My app is for iOS, but it’s nice to be able to debug on the simulator or as a Catalyst app. Right now, I’ve been using MTLPixelFormatBGR10_XR_sRGB and MTLPixelFormatBGRA10_XR_sRGB per the recommendation in WWDC 2016 session 605 for iOS support of P3 color. This appears to work fine on iOS devices, but on my Apple silicon Mac, when running as a Catalyst app, the colors sometimes look lighter than they should, but it doesn’t always happen. When I run in the simulator on this Mac, my app crashes. When I was using an Intel Mac (with an sRGB screen), I was having my app render in sRGB-only with MTLPixelFormat.bgra8Unorm. MTLPixelFormat.bgra8Unorm also works fine on my Apple silicon Mac, but of course, I’m not getting the P3 color space.  For Apple Silicon Macs, as the GPU hardware is more like an iOS device than like an Intel Mac, should the same pixel formats work on an Apple silicon Mac as on iOS devices? Or are the pixel formats that work with Apple Silicon Macs the same as those on Intel Macs?

I posted a question in the playgrounds section of the forums regarding an issue with Metal in Swift playgrounds: Metal playground not setting up MTLLibrary with makeDefaultLibrary(), but I figured someone might better know on a general level whether Metal even works in playgrounds or not. I'm not sure if I'm putting my shader file in the correct location in the playground - I tried putting it in both the sources and resources folders of the playground.

When an object that contains a semaphore gets automatically deallocated by ARC in my app, I get an EXC_BREAKPOINT or an EXC_BAD_INSTRUCTION with the message "BUG IN CLIENT OF LIBDISPATCH: Semaphore object deallocated while in use". The call stack shows libdispatch.dylib`_dispatch_semaphore_dispose.cold.1 as the location of the crash. I noticed that this error doesn't occur when the semaphore's wait/signal calls are balanced such that the semaphore's counter is at the value I initially passed in (see code below). In my actual code (which is in Metal rendering code that's getting called every frame), I don't know what the semaphore's counter is at at any given moment (and because of the abstraction of a semaphore, I shouldn't have to know what the counter is at), so how do I make sure that the object that holds the semaphore (and the semaphore itself) is deallocated properly so I don't get this crash on deallocation?class Test { var semaphore = DispatchSemaphore(value: 3) } var test = Test() // will not crash test.semaphore.wait(timeout: DispatchTime.distantFuture) test.semaphore.signal() test = Test() // will crash test.semaphore.wait(timeout: DispatchTime.distantFuture) test = Test()