We’re using PVRTC compressed textures pretty widely on iOS. ASTC is on the horizon but while we’re metal-only, we’re still supporting some devices that don’t support ASTC so we’re holding back still.I’ve just noticed that all our supported devices support the ETC2/EAC pixel formats (https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf). I want to check that it’s actual hardware level support of these formats, not driver level decoding to some 16-bit or 32-bit equivalent. The closest I can find to any advice is some (non-apple employee) forum postings advising against ETC2 on iOS, and this quote from the deprecated OpenGLES on iOS guide “OpenGL ES 3.0 also supports the ETC2 and EAC compressed texture formats; however, PVRTC textures are recommended on iOS devices.”.The two situations I’m thinking about using ETC2/EAC are:Non-square compressed textures (PVRTC has to be square still I believe, although I’m having trouble finding any documentation that confirms that’s still the case on metal).We find that the EAC R11 compressed format is a good replacement for R8 in our ES3/Vulkan implementations. It’s half the size of R8 with minimal loss of detail, and PVRTC doesn’t really have an equivalent, so I’m tempted to use that on iOS.Can anyone confirm if there’s actual hardware support?

We've been getting a crash on an app under development which is producing logs with the message: "45001 wakeups over the last 174 seconds (258 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds".We have narrowed down the cause of our crash to some temporary debug code that was firing more-than-usual numbers of analytics events. Our analytics system uses AWS Kinesis Firehose: https://github.com/aws-amplify/aws-sdk-ios/tree/master/AWSKinesisObviously we can fix by disabling the debug code, but we'd like to have a better understanding of the problem so that we can make our code (or the AWS code) more robust. Additionally, we know of at least one end user that has experienced similar issues on a released title and we were unable to help them get our product working on their device - I now suspect their problems may have been related.Basically, I don't know what a wakeup is in this context, so I therefore don't understand how to go about controlling the number that we trigger. It must refer to something other than ordinary multi-threading activity, because 150 thread switches per second is such a low limit that it would effectively prohibit multi-threading (the limit is only 2.5 per frame at 60fps!). I also don't think it can refer to background execution because our app doesn't do any background execution and the crashes are not associated with multitasking at all.Can anyone tell me what a wakeup is in this context? And maybe give me advice to help me find the code that is causing them?