i'm using it as a daily driver for a couple months easily, but my daily driving happens to not require the not-quite-perfect device drivers. i shutdown for sleep, for instance, which works just fine, since boot and login is super fast and restores everything.
Question for those in the know: are there any substantial changes from M1 to M2? I'm sure lots of tuning took place, but is there any major component that was completely overhauled?
Another question for those in the know: there are what seem to be tons of weird GPU problems on macOS under M1— weird cursor tails, choppy scrolling, and very occasional panics that derive from GPU drivers. Are there any workarounds for unstable GPU behavior that were discovered during the RE & driver implementation?
Edit: I've directly observed these on my machine, and it doesn't look to be an isolated incident. There is a video in [2] below.
The biggest change, IIRC, is that the M1 was based on the A12(?) but the M2 was based on the A14(?). So the CPU/GPU design was newer. They tweaked and improved other modules like the neural engine too.
So it wasn’t just clock speed, but to most end users it was just somewhat faster and more mature.
I've been reading bits and pieces from the people doing Linux for Apple SoCs for a while and it sounds like the evolution has been mostly incremental going way back (like A7 era).
Some ppl have been saying reason macs doesn't support 4k 120hz using thunderbolt to hdmi 2.1 cables is a software limitation, I wonder if linux on macbook solves that
Most often it's a hardware limitation because the cables/adapters use the MCDP2900 converter chip inside, even when they advertise HDMI2.1 support. That's the same chip inside the built-in HDMI port of the new MacBook Pro and its datasheet [0] says it only supports up to 60hz
That chip is also the reason for a lot of support emails I'm getting on Lunar (https://lunar.fyi/) because it seems to break DDC/CI and hardware brightness control stops working through cables and ports that use it.
M1RACLES was a security flaw that was hyped as a joke, because it was such a weak bug, and yet it was hyped to oblivion. It totally does not deserve even a mention on the M1 Wikipedia page.
The flaw means that two malicious processes, already on the system, can potentially communicate without the OS being aware. Even though they already could through pipes, desktop icons, files, inter-process communication, screen grabbing each other, over the network, from a remote website, take your pick. Now, what are the odds of two malicious processes, being on a system, with a pre-agreed protocol for communication, going to need a weird processor bug to communicate over for? Absolutely nothing. It's not supposed to happen - but it's basically useless when you are twice-pwned already.
The other flaw that was found was that Pointer Authentication (PAC) could be defeated on the M1 with the PACMAN attack. However, PAC was actually an ARM standard added in ARMv8.4 that affects all ARMv8.4 implementers - the M1 just happens to be the most notable chip with that ARM version. Versions before ARMv8.4 didn't have PAC at all - so, even with that defeated, you aren't worse off than you were before ARMv8.4, so it's just a "sad, we tried, but oh well" thing from ARM's perspective.
umanwizard|3 years ago
Anyone have an idea how soon we should expect GPU support to be in mainline?
jjtheblunt|3 years ago
CameronNemo|3 years ago
dottedmag|3 years ago
GPU and display controller were initially expected to have large amount of changes, but this turned out not to be the case.
Amount of changes between M1->M1Pro/Max/Ultra and M1Pro/Max/Ultra->M2 is similar.
ultrarunner|3 years ago
Edit: I've directly observed these on my machine, and it doesn't look to be an isolated incident. There is a video in [2] below.
[0] https://discussions.apple.com/thread/253679057
[1] https://discussions.apple.com/thread/252777347
[2] https://www.reddit.com/r/apple/comments/u486mi/macbook_pro_1...
[3] https://www.reddit.com/r/mac/comments/oldbb9/mba_m1_cursor_g...
[4] https://www.reddit.com/r/applehelp/comments/kfkuqi/is_there_...
[5] https://www.reddit.com/r/mac/comments/r037h2/is_this_amount_...
[6] https://forums.macrumors.com/threads/mac-mini-m1-mouse-curso...
MBCook|3 years ago
The biggest change, IIRC, is that the M1 was based on the A12(?) but the M2 was based on the A14(?). So the CPU/GPU design was newer. They tweaked and improved other modules like the neural engine too.
So it wasn’t just clock speed, but to most end users it was just somewhat faster and more mature.
Nothing special/amazing/transformative.
hedgehog|3 years ago
2OEH8eoCRo0|3 years ago
vletal|3 years ago
yes_but_no|3 years ago
alin23|3 years ago
That chip is also the reason for a lot of support emails I'm getting on Lunar (https://lunar.fyi/) because it seems to break DDC/CI and hardware brightness control stops working through cables and ports that use it.
[0] https://media.digikey.com/pdf/Data%20Sheets/MegaChips%20PDFs...
sofixa|3 years ago
moondev|3 years ago
my123|3 years ago
unknown|3 years ago
[deleted]
bogwog|3 years ago
unknown|3 years ago
[deleted]
unknown|3 years ago
[deleted]
sedeki|3 years ago
gjsman-1000|3 years ago
The flaw means that two malicious processes, already on the system, can potentially communicate without the OS being aware. Even though they already could through pipes, desktop icons, files, inter-process communication, screen grabbing each other, over the network, from a remote website, take your pick. Now, what are the odds of two malicious processes, being on a system, with a pre-agreed protocol for communication, going to need a weird processor bug to communicate over for? Absolutely nothing. It's not supposed to happen - but it's basically useless when you are twice-pwned already.
The other flaw that was found was that Pointer Authentication (PAC) could be defeated on the M1 with the PACMAN attack. However, PAC was actually an ARM standard added in ARMv8.4 that affects all ARMv8.4 implementers - the M1 just happens to be the most notable chip with that ARM version. Versions before ARMv8.4 didn't have PAC at all - so, even with that defeated, you aren't worse off than you were before ARMv8.4, so it's just a "sad, we tried, but oh well" thing from ARM's perspective.
unknown|3 years ago
[deleted]