Here's my hack for now. This deletes any existing documents that aren't the current document, but this seems pretty ugly. The docs state the following, but not how to handle once a document URL already has an associated NSDocument. Hence the hack. If you can following any of the flow of commentary in NSDocumentController, then you are wiser than I. /* This will be called for any URLs your application is asked to open. This includes URL types (CFBundleURLTypes) defined in your Info.plist, and Document types (CFBundleDocumentTypes) that have no associated NSDocument class. Document URLs that have an associated NSDocument class will be opened through NSDocumentController. If this is implemented, application:openFiles: and application:openFile: will not be called.  */ (void)application:(NSApplication *)application openURLs:(NSArrayNSURL * *)urls API_AVAILABLE(macos(10.13)); (BOOL)readFromURL:(NSURL *)url ofType:(NSString *)typeName error:(NSError **)outError { ... BOOL isLoaded = [self loadFromURL: url]; if (isLoaded) { NSDocumentController* dc = [NSDocumentController sharedDocumentController];     NSDocument* currentDoc = dc.currentDocument;     NSMutableArray* docsToRemove = [[NSMutableArray alloc] init];     for (NSDocument* doc in dc.documents) {       if (doc != currentDoc)         [docsToRemove addObject: doc];     }           for (NSDocument* doc in docsToRemove) {       [dc removeDocument: doc];     } } return isLoaded }

Hi Quinn, These were the post that said were locked for inactivity or "deemed necessary by a moderator" after 1 month. https://developer.apple.com/forums/thread/676483 https://developer.apple.com/forums/thread/675995

Awesome Quinn. Thanks for looking into it, and I'm glad it was just a bug. The forums are really a great resource.

I've set the UTI types in the Info.plist and followed all the instructions for setting up the template from the Apple documentation. When it works, this is the output. But I don't think these was generated via my plugin, but via a system generator for .ktx. /Users/Foo/tests/mac/Toof-a.ktx 2021-05-28 10:21:46.623 qlmanage[23586:4236472] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x634b, name = 'com.apple.tsm.portname' See /usr/include/servers/bootstrap_defs.h for the error codes. 2021-05-28 10:21:46.629 qlmanage[23586:4236472] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x650f, name = 'com.apple.coredrag' See /usr/include/servers/bootstrap_defs.h for the error codes. * /Users/Foo/tests/mac/Toof-a.ktx produced one thumbnail Done producing thumbnails 2021-05-28 10:21:46.996 qlmanage[23586:4236472] TISFileInterrogator updateSystemInputSources false but old data invalid: currentCacheHeaderPtr nonNULL? 0, ->cacheFormatVersion 0, ->magicCookie 00000000, inputSourceTableCountSys 0 Keyboard Layouts: duplicate keyboard layout identifier -17410. Keyboard Layouts: keyboard layout identifier -17410 has been replaced with -28673. Keyboard Layouts: duplicate keyboard layout identifier -30769. Keyboard Layouts: keyboard layout identifier -30769 has been replaced with -28674. Keyboard Layouts: duplicate keyboard layout identifier -14934. Keyboard Layouts: keyboard layout identifier -14934 has been replaced with -28675. 2021-05-28 10:21:48.296 qlmanage[23586:4236498] Persistent UI failed to open file file:///var/root/Library/Saved%20Application%20State/com.apple.quicklook.qlmanage.savedState/window_2.data: No such file or directory (2)

I see the following messages when I turn on the logging trying qlmanage on a .ktx2 file. qlmanage -t /Users/Foo/tests/Toof-a.ktx2 -x QuicklookSatellite extractOptions:142: *** unknown hint identifier 'kCGImageSourceTypeIdentifierHint:public.ktx2' -- ignoring... Will not generate thumbnail from image because it has an incorrect size: (0.000000, 0.000000) com.apple.quicklook.ThumbnailsAgent CGBitmapContextCreateImage: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable. distnoted register name: com.apple.nsquiet_safe_quit_give_reason object: com.apple.quicklook.qlmanage token: 380000003e pid: 31960

I can see the appex listed in the "Extensions" and it's enabled. And it's sandboxes=d, and the app the appex is inside is sandboxed. I have built versions of the app and plugin in various parts of my drive, but can't QL handle that? Why is it getting confused as to which one to run. I have the one I want QL (and qlmanage) to run in the Applications folder. Then qlmanage just sits there running, and doesn't ever finish. I can quit or kill the app. Sometimes when it does finish, it just says "no thumbnail created". [d ] [u com.foo.app.thumbnailer] [()] detected another plugin with a newer modification date: [u 22C44ECE-8E9A-4D9D-A303-XXXXXXX] [()] [d ] [u com.foo.app.thumbnailer] [()] rejecting; another plugin has precedent: [u 22C44ECE-8E9A-4D9D-A303-XXXXXXXX] [()] Ultimately qlmanage is just sitting there, with the only relevant last message being this timeout. qlmanage: LSExceptions shared instance invalidated for timeout.

I also need an assert. The MBP 16" is generating valid uv, with 0 length derivatives and that causes problems. Being able to assert on this condition would help. Drew's recommendation just seems to result in a compilation failure on macOS Big Sur.

Yes, the problem is that CLAMP_TO_ZERO on a fully opaque 4x4 pixel texture brings down those outer pixels to transparent. So if you were drawing a quad or particles and expected the texture to fill to the edge, then that won't happen. The bilinear filter will pull in those pixels leading to a 3x3 pixel area and a half pixel transparent border around the quad. When magnified this ramp is even more obvious and the black tinting of even premul color looks bad. Switching back to CLAMP_TO_EDGE fixes the issue, but now get stretching of pixels if you try to draw uv outside the [0,1] range.

You could indirectly access the occlusion result in another buffer for each instance/model off an id. It's also a bit tough since visibility writes 8-bytes, but many of the length fields such as those in the indirect draws are 4 bytes. What I really want is a way to only write 0 if occluded, and not write 1 on a boolean query if visible.

So there is no way to emulate multi-draw indirect count There is. But you have to call drawPrimitive or drawIndexedPrimitive multiple times, each one indexing into the next indirect draw in the buffer. I don't know why Metal left the drawCount out of the api, but the current implementation has a drawLimit of 1. Nice thing is indirect draw works back to iPhone 5S. You can even do GPU buffers with compute, and then indirect draw them. But you have to call draw 10 times, even if compute culls and produces 5 results, so make sure to set numInstances to 0 on the remaining draws. Or if you can wait a frame, then you could return a count to the cpu.

Apple keeps shipping products like the new AppleTV with an A12 chips, so if that's in your market then you'll need a fallback. They are Tier1 devices that cannot index into or have pointers to Argument Buffers which is a key part of gpu-driven pipeline and ray-tracing. Fortunately M1 and A14 are replacing these old chips on macOS.

If you're dealing with GPU textures, then you need to copy them to a staging texture or buffer using the blit encoder. Then the bytes are available on the CPU. But the gpu is 1-3 frames ahead of the CPU. So you can't expect to read it back immediately.

There's still the issue on iOS of where we can reload a new metallib from in development builds for the hotload. I'm assuming we have some access to a Downloads or public folder where the metallib can be copied into.

This is happening in Apple's own terrain sample code on macOS on the latest 16" Intel MBP with AMD 5500m. The Metal texture loader somehow loads an L16 png into an RG16Unorm texture since it provides no control over the MTLPixelFormat. Then when you click to modify the terrain with the mouse, the app crashes in the validation. The textures say they support All, function texture read-write is true, and readWriteTexture support is Tier2. If Apple can't write a correct example that works, then we probably can't either. MTLTextureDescriptor *texDesc =       [MTLTextureDescriptor texture2DDescriptorWithPixelFormat:         MTLPixelFormatRG16Unorm         //MTLPixelFormatR16Unorm <- should be this                                 width:heightMapWidth                                height:heightMapHeight                               mipmapped:NO];      2021-08-18 22:43:41.385581-0700 DynamicTerrainWithArgumentBuffers[46069:3553941] sample running on: AMD Radeon Pro 5500M validateComputeFunctionArguments:854: failed assertion `Compute Function(TerrainKnl_UpdateHeightmap): Shader uses texture(heightMap[0]) as read-write, but hardware does not support read-write texture of this pixel format.' validateComputeFunctionArguments:854: failed assertion `Compute Function(TerrainKnl_UpdateHeightmap): Shader uses texture(heightMap[0]) as read-write, but hardware does not support read-write texture of this pixel format.'

Seems to be a bad bug in the Metal validation layer. It flags this texture RG16Unorm as unsupported, but it is supported. Turning off Metal validation for me fixes that sample app.