I added a dummy xcodeproject and add the files to that project and even that doesn't help. I use the syntax highlighting for metal even though I have source hlsl files. These have u/int, float, half elements that are valid MSL types. These should be highlighted but are not. It's like Xcode tries to parse them as MSL, but fails, and then doesn't highlight anything. Syntax highlighting should be simple name lookup and coloring at a basic level. It shouldn't need complex parsing. Also the plugin architecture for the editor seems undocumented, but there are few brave souls that reverse engineered it for lua/typescript. A code editor shouldn't be this hard to use and extend.

Contrast this with VSCode that highlights any .metal or .hlsl file or containing folder dropped onto it. The files are in the project. They are just not a part of the build. The files are a result of what the CLI tools build. Also limiting that console can’t click through to error file/line like every other IDE. The console cannot jump to files or url links.

Nvidia's Tensor float is 1 + 7 + 10. Might be some funky AI float. There's already bfloat.

Clears wipe the whole texture out. They have since DX10, and Metal is no different. You need to draw rectangles to color, depth, or stencil for any kinds of partial clears. The whole point is to do a fast clear of the content where the hw doesn't even touch pixels. If it had to scissor test then that doesn't work.

Also setting C source, C++ source, Metal source, OpenGL Shading Language on the .hlsl makes no difference. I at least get some highlighting on includes that are set to "Default - C header". The .metal file is set to "Default - Metal Shading Language" but doesn't syntax highlight properly as described above.

Fixed the missing drop of folder by adding "public.directory" to the list of UTI array. Still missing glb/gltf UTI in this library. These are older than usd/usb files, so seems like they should be in there.

Also when I specify pasteboardOptions, then folder drops stop working. I need to be able to drop files and folders. Are there any modern samples of using the clipboard? The docs Apple publishes on clipboard handling are from 2010. NSArray<NSString *>* pasteboardTypes = @[   // don't really want generic urls, but need folders to drop   //NSPasteboardTypeURL       // this is preventing folder drops ?   NSPasteboardTypeFileURL ];  // added for drag-drop support   [self registerForDraggedTypes:pasteboardTypes]; // ktx, ktx2, png, and dds for images // zip, metallib // gltf, glb files for models NSArray<NSString*>* utis = @[  [UTType typeWithFilenameExtension: @"png"].identifier,  [UTType typeWithFilenameExtension: @"ktx"].identifier,  [UTType typeWithFilenameExtension: @"ktx2"].identifier,  [UTType typeWithFilenameExtension: @"dds"].identifier,     [UTType typeWithFilenameExtension: @"zip"].identifier,  [UTType typeWithFilenameExtension: @"metallib"].identifier,    #if USE_GLTF  [UTType typeWithFilenameExtension: @"gltf"].identifier,  [UTType typeWithFilenameExtension: @"glb"].identifier  //@"model/gltf+json",  //@"model/gltf+binary" #endif ]; NSDictionary* pasteboardOptions = @{   // This means only these uti can be droped.   NSPasteboardURLReadingContentsConformToTypesKey: utis       // Don't use this it prevents folder urls ?   //, NSPasteboardURLReadingFileURLsOnlyKey: @YES }; - (NSDragOperation)draggingEntered:(id)sender {   if (([sender draggingSourceOperationMask] & NSDragOperationGeneric) ==     NSDragOperationGeneric) {     NSPasteboard* pasteboard = [sender draggingPasteboard];           bool canReadPasteboardObjects =       [pasteboard canReadObjectForClasses:@[ [NSURL class] ]                     options:pasteboardOptions];     // when this fails, toss the pasteboardOptions     // like when I drag folders     if (!canReadPasteboardObjects) {       canReadPasteboardObjects =         [pasteboard canReadObjectForClasses:@[ [NSURL class] ]                     options:@{}];     }     // don't copy dropped item, want to alias large files on disk without that     if (canReadPasteboardObjects) {       return NSDragOperationGeneric;     }   }   // not a drag we can use   return NSDragOperationNone; }

I use BC7 textures fine on Intel and M1 systems. But these are 2018 MBP with AMD and Intel parts. One problem with KTX files is that each mip level has a 4 byte length. This messes up the upload of data, and Metal typically wants 16B alignment of each mip level. Metal validation should flag that. If you are doing a memcpy then that may not be the issue. I was originally trying to mmap uncompressed ktx files when I hit this issue.

Okay, I tracked this down. The project setting for "Precompile prefix header" was being overridden with "No" by both targets. Now the build takes 11s to parse instead of 78s. So precompiled headers are still a huge win.

So I renamed the file to AppPrefix.h, designated that as the both GCC_/CPP_PREFIX_HEADER. Removed all explicit includes of AppPrefix.h in the sources. And that file is getting prepended onto every compile. It's just not being precompiled. I can see the same files parsed over and over. Is it that stl type template headers must be re-parsed regardless of the pch setting? Seems like on arm64 builds all Xcode does is prepend the file to each file, and doesn't bother to do the precompile. Does clang not support pch. I even renamed the file to AppPrefix.pch which still works, but with no precompile.

Also how do CPP_PREFIX_HEADER and GCC_PREFIX_HEADER differ? This is a C++ project, so I tried setting both. But I don't see any output lines with my App.pch file. I even renamed it to AppPrefix.pch, and still don't see that text in the output. Even putting garbage into the .pch file still succeeds on the build. This is latest Xcode on an M1. Is Xcode just ignoring these directives?

Just use the spriv tools to generate your reflection data. It's a shame that Apple's MSL can't output spir-v. So then end up having to write everything in HLSL or GLSL.

I'd recommend using reverseZ and infiniteFar plane. There are plenty of online resources for this.

I don't see anything in the build output that indicates that the pch was compiled and used. And the build timings aren't any faster. -ftime-trace shows the same header file being parsed as used again and again, adding up to a large overall time.

Also the microscopic single color super-thin display of the signposts in Instruments is really not that helpful. This should be displayed as a real flame chart. We'll keep using Perfetto for now.