Seems that p-cores can drop off during thermal constraint. That would make affinity assignments more challenging. We're now setting round-robin 45/41 priority as per the talk, set qos 31 on non-important threads, but have audio threads at super high fifo priority. But we can control where any of this runs consistently, and we have that and priority on all other platforms. We're not even sure if based on these vague numbers that we consistent get p- or e-cores. That makes consistent performance tuning a lot more difficult.

enum MTLSamplerMinMagFilter { MTLSamplerMinMagFilterNearest, MTLSamplerMinMagFilterLinear, MTLSamplerMinMagFilterMin, <- add MTLSamplerMinMagFilterMax, <- add }

Here's the developer doc built from the sources, that mentions iOS 13. https://developer.apple.com/documentation/metal/mtlcompileoptions/3564462-preserveinvariance?language=objc And here's the flag itself. /*!  @property preserveInvariance  @abstract If YES, set the compiler to compile shaders to preserve invariance. The default is false.  */ @property (readwrite, nonatomic) BOOL preserveInvariance API_AVAILABLE(macos(11.0), macCatalyst(14.0), ios(13.0)); @end We ran this on new and old hardware, but our app targets minimum iOS 12 since our minspec is a 5S, and we can't move higher since Apple dropped iOS updates for it in 12. We will also move to reverseZ and infiniteZ, but that's a much bigger code change. This should also improve depth precision, but here it's using the same matrix for both passes, and the depth precision shouldn't matter.

Hmm, I guess option+click does the capture without bringing up the popup. So question answered, but this might help others.

This is still an issue. Can we have a timing system that doesn't go through the slow and unconfigurable os_log? We don't use an unreasonable number of scopes for any of the profilers, but these swamp os_signpost.

Note that most recent Intel gpus removed fp64 support. Maybe Apple won't update their Intel lineup, so you'll be safe.

This is typically code using AVX or AVX2 or fp16 extensions in Rosetta 2. So you'll need an ARM native or version of that x64 code that doesn't use those. Only SSE 4.2 max.

I found the issue. Apparently Apple thought it would be fun on iOS to add and also enable "Private Wi-Fi Address" by default in the Wi-Fi settings . This replaces the DHCP address that our device needs to be on to connect back to macOS which needs to be on the same IP range. Ugh.

Still happening even in Xcode 14.1. The filter isn't a solution to this. The errors displayed even when the build succeeds just cause confusion for the non-engineers trying to build our title.

Think I figured it out. It's because the natural thing to remove a keyboard shortcut is to hit delete, but this instead inserts the delete key as the key equivalent, and then breaks all delete functionality throughout Xcode. And there's no assistance to say how to erase a shortcut (does cmd+delete still work after that?). So now I have to redo all my shortcuts from scratch to get rid of the delete key override. Are there really that many people that need to override the Delete key specifically?

Thanks, I've used Xcode for a long time. So I'm familiar with the breakpoint UI. It's just that they shift as code changes, and then I like to delete them. How do you delete a conflicting Xcode keyboard shortcut? I constantly have this issue. Cmd+\ doesn't work. There are no articles online about it. delete just enters the delete key as the keyboard shortcut. This shouldn't have to be this hard. The keyboard shortcut menu even has a red x, but you click on it and it doesn't delete the conflict.

Thanks that works. I so rarely change these once they are set, and there's no help text. Contrast that with other IDEs that allow chording and this UI is unchanged from Xcode 1.0.

Yes, we've got all that. But what are the correct settings for iOS and macOS. I've listed what I've tried so far above and failures. What have you tried that worked? On SO, someone stated that MTKView can only composite to srgb spaces (limitation of iOS and/or macOS?). We also can't use XR_srgb format except on the new macs, but are doing development on Intel. Why do I need to set a color space at all if I'm already passing linear data in rgba16f. I'm assuming the rest of the UIKit/AppKit composite has some colorspace as well, not just my MTKView. So all those need to be in agreement. So far that agreement seems to be that my content needs to be srgb (or DisplayP3 with similar srgb curve). Rec2020_PQ which is HDR10 gets even more complex with exrmetadata on the CAMetalLayer, but that's all that HDR televisions speak. But that's a lot of per pixel matrix ops, and a different compositing path for srgb8 UI and and rgba16f render. We can create textures that are srgb or linear. The gpu hw will convert the srgb back to linear for us. But I've got linear data in the render texture that doesn't look correct with most of these color spaces. I haven't changed the data. And they are even incorrect in EDR (0 to 1), let alone HDR (<0, >1).

I mean zero of the Metal sample apps even set a colorspace. So what do we reference here? macOS and iOS are supposed to be the ultimate "color managed" platforms, although iOS couldn't afford the pixel ops on the first phones/iPads. Am I tagging my pixels which are linear as srgb, do I need a transfer function to be gamma 1 or gamma 2.2? What is kCGColorSpaceSRGB vs. kCGColorSpaceLinearSRGB. These are both srgb colorimetry, but am I stating that my content has the srgb gamma curve in the former, and is linear in the latter? And how to get the cheapest pass through. I can set my display color space to sRGB (709) or P3, but how do I get the cheapest, fastest, and highest quality pixel output to screen. Before all the color management, on iOS I had to use BGRA8 instead of RGBA8 to avoid a swizzle blit. These are the kind of details that are sorely lacking even in the WWDC presentations. There is also true tone, and the user adjusting the maximum brightness of the display. So those also need to be responded too. And what to do when NSApplicationDidChangeScreenParametersNotification calls and says screen.maximumExtendedDynamicRangeColorComponentValue changed.

Seems that disabling "Settings -> General -> Show Live Issues" gets rid of the stale error reports in the Issue List. We build with makefiles, but can this feature be fixed? It really makes Xcode needlessly difficult to do development.