Posts

Post not yet marked as solved
1 Replies
588 Views
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?
Posted Last updated
.
Post marked as solved
7 Replies
5.3k Views
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.
Posted Last updated
.
Post marked as solved
3 Replies
3.6k Views
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()
Posted Last updated
.
Post not yet marked as solved
0 Replies
1.2k Views
For the color values I'm passing to my Metal shaders, I'm wanting to have them in P3 since the content of my MTKView is something that makes sense to have in P3. My question is that because these values are stored in extended sRGB (as recommended in WWDC 2016 605 What's New In Metal Part 2), what's the range (below 0.0 and above 1.0) that these values can fall in? Does it vary based on the color channel since the red and green channels are more affected by P3's wider space? Does it vary depending on whether the MTKView's colorPixelFormat is MTLPixelFormat.bgra10_xr or MTLPixelFormat.bgra10_xr_srgb, since the second one is doing gamma correction?Also, how does this affect getting to a UIColor equivalent to the value (and vice versa)? I'm having to convert between UIColor and a Metal-readable form (a float4) because the colors appearing in the MTKView are user-selected, thereby involving UIKit controls that need the color as a UIColor value.
Posted Last updated
.