Cool, and just like that we lost a few more hundred Euros of worktime due to Apple induced issues, while the iToys company reports record earnings for last quarter. Seems like the worse of a job they do wrt. software and hardware quality, design and treatment of developers and pro customers, the more they get rewarded by consumers buying their toys like crazy.
I don’t think disabling that workaround will ever be possible on M1. For M1 and presumably future Apple machines with Apple proprietary gpu’s, the Apple proprietary OpenGL driver is not a real native OpenGL driver anymore, but an OpenGL-on-Metal emulator, which translates all OpenGL calls into calls for Apples proprietary Metal graphics api (Hence the word “Metal” in PTB’s renderer information). Apple Metal can only display rendered content onscreen by rendering into a CoreAnimation CAMetalLayer, attached to a layer backed NSWindow/NSView. It can’t use the low-level CGL OpenGL fullscreen display api’s we’d normally use (CGLSetFullScreenOnDisplay etc.), because it is not an OpenGL renderer. So all our current tricks for proper timing are dead. But even if that would work by miracle (= Apple deciding to completely redesign/rewrite their OpenGL drivers for M1 from scratch – pretty unlikely), your debug output indicated that various other critically required pieces needed for the timing hacks also got broken by Apple for the M1. And proper timing through the workaround which uses NSWindow/NSView/NSOpenGL got broken by Apple since many years, probably with the breakage already starting around 2012 for macOS 10.7 on NVidia, although it got much worse around 10.11 or 10.12, affecting NVidia and many AMD’s and completely kicked the bucket with 10.14, killing timing all gpu’s supported by macOS. The current pile of hacks on top of hacks on top of hacks to make things work in many cases (but by far not all of them) on macOS 10 took close to 500 hours to figure out, with many false starts over the years, most of the time (except for 100 hours) being unpaid by the community, as usual. So this is all dead now with macOS 11 and the M1 gpu’s, with little chance of resurrection ever.
What we do have since the latest PTB beta release is a Vulkan based prototype implementation to explore the viability of using Metal as a display backend via the open-source Khronos MoltenVK Vulkan-on-Metal graphics driver. Ie. render and post-process visual stimuli as usual via Apples proprietary OpenGL implementation → submit final stimulus image to Vulkan for display by using our relatively new PsychVulkan driver → MoltenVK driver translates Vulkan → Metal for display via Metal, Apples proprietary Metal displays the image.
According to Apple propaganda, Metal is the greatest invention since sliced bread and the one true way to do graphics on macOS. According to my results after just spending 174 utterly depressing hours of work, trying to get Metal to behave even half-way reasonable wrt. presentation timing and timestamping, my assessment so far is that this is even a bigger dumpster fire than Apples OpenGL implementation when it comes to stimulus timing and timestamping. A lot of time was spent making sure the failures i see are not caused by any bugs or limitations in PTB, or the open-source MoltenVK Vulkan-to-Metal driver, or of the general approach which works nicely on both Linux and Windows-10, so these are again macOS bugs and problems courtesy of Apple, only fixable by Apple, with no known workarounds. My tests are limited to a MacBookPro 2017 running macOS 10.15.7 with both AMD and Intel graphics so far. Who knows, maybe macOS 11 on M1 is less broken in that area than macOS 10 – although that would be the first time anything would be better on the dumpster fire that Big Sur seems to be, even compared to the temple of sadness that was recent macOS 10?
But for Apple M1 and its successors, i assume it will be either this Vulkan/Metal approach, or nothing, if timing matters at all. There are no more tricks or workarounds left from my side and Apple pretty much closed any opportunities for developing new workarounds in the future, given their proprietary gpu, and the way the locked down macOS 11 M1, and given they announced already their intention to lock it down even more in future hardware and OS versions.
This new experimental code is essentially unsupported by myself in case of problems. It has various known limitations, e.g., it only supports most basic use of Screen('Flip', window, when), not any more advanced PTB mechanisms like async flips, frame-sequential stereo, non-vsynced updates etc. Any future improvements to it will have to be paid by contracting us. Guidance wrt. use of the current implementation will also require priority support, so my time is paid for and the costs of failure on other machine + OS versions are not on our side. Some demos are Vulkan enabled for testing if an optional flag is specified, e.g., PerceptualVBLSyncTest and VBLSyncTest for basic timing checks. SimpleHDRDemo is another one.
-mario