Trying to call [MTLDevice newTextureWithDescriptor:iosurface:plane:]
on an Apple Silicon mac, where the descriptor specifies MTLStorageModeShared, I am getting a failed assertion error:
-[MTLDebugDevice newTextureWithDescriptor:iosurface:plane:]:2387: failed assertion `Texture Descriptor Validation
IOSurface textures must use MTLStorageModeManaged
I don't really understand why we have this limitation, MTLStorageModeShared textures are supported on Apple silicon (despite the documentation in https://developer.apple.com/documentation/metal/mtldevice/1433378-newtexturewithdescriptor?language=objc which claims overwise.
Post
Replies
Boosts
Views
Activity
Hi, I have been following the steps presented in
https://developer.apple.com/documentation/coremediaio/creating_a_camera_extension_with_core_media_i_o
to create a core media I/O camera.
However when calling
let activationRequest = OSSystemExtensionRequest.activationRequest(
forExtensionWithIdentifier: identifier, queue: .main
)
activationRequest.delegate = installDelegate
OSSystemExtensionManager.shared.submitRequest(activationRequest)
The delegate's request(_ request: OSSystemExtensionRequest, didFailWithError error: Error) method is being called with error code 9 (OSSystemExtensionError.Code.validationFailed) and the system dialog does not appear.
MTLStorageModeManaged textures requires blit passes to synchronize the CPU and GPU according to the doc here.
Since in Apple Silicon macs, there is just a single unified memory architecture, do we still need to synchronize? does the texture really exist in two copies in the memory? or is it just in order to provide code compatibility with Intel mac? (and the texture are essentially shared texture under the hood?)
I am trying to develop a system extension. During development process I often like to create a version, debug it, fix some issue, and then try a new version.
This is a normal flow for development, but it doesn't seem to work for me when developing a system extension.
It seems like removing a system extension using the systemextensionsctl only registers it for removal after the next restart, which means I need to restart my machine for every code change.
it also seems like calling
OSSystemExtensionRequest.activationRequest(forExtensionWithIdentifier: queue: )
with the new extension version will not replace the running one despite the
_ request: OSSystemExtensionRequest,
actionForReplacingExtension existing: OSSystemExtensionProperties,
withExtension ext: OSSystemExtensionProperties
)
being called on the OSSystemExtensionRequestDelegate
So is there another way to iterate on app extension versions?