I believe Rosenzweig was responsible for the user-space bits; this post is about the kernel driver, which (as I understand it) was done entirely by Asahi Lina.
(Both of them deserve a ton of praise, of course.)
It was passing that test suite when being run as of their XDC talk 10 days ago using only Alyssa's bit. This update shows that when using both bits combined it now passes with the same level of conformance.
At least that's my understanding of it. You're right in that this is about both bits working together, but the person you're replying to is right in the sense that this particular update is showing specifically an update in Lina's bit.
You're literally linking to a youtube video where 10 seconds later Alyssa is saying "this should all be sufficient proof that I'm not Lina"... and Lina engaged in an interactive Q&A while Alyssa stood around demonstrably not the person responding.
IF Lina had to be an extant member of the Asahi Linux project, it is much more likely that she would be Hector (marcan); Lina and marcan had identical dev environments when she first started making videos and Lina’s introduction to the Asahi Linux YouTube community was her “hacking” one of Hector’s streams. (https://m.youtube.com/watch?v=effHrj0qmwk)
Lina was first introduced as an April Fools joke from marcan, but after the positive response from the audience he (or now she?) probably just decided to go why not and stick with the alternate identity. But as you’ve said, it really doesn’t matter.
one "anime" girl, 2 "anime" girls, 10 dev bros, I don't really care at this point. Color me impressed at the skillz required to make this to the point it is in the time it is. Way past anything I might dream about doing myself. So many kudos to any/all involved male/female/other doesn't matter in the slightest for the possibility to use the hardware to whatever I want.
It is impressive. I remember reading something related to new abstractions in chip level. The most of the GPU drivers are actually on some specific chip and it works similarly regardless of the OS. Kernel developers actually develop against this new abtraction layer and not directly against GPU. Does someone has more information about this, or was this nonsense?
It means that the drivers likely have a giant 'firmware' which is really just a closed source driver loaded into the chip, but with a nicer api for the kernel to program against
The dev is Asahi Lina (I presume a pseudonym https://twitter.com/LinaAsahi ) and when she livestreams the coding sessions instead of a video feed there's an avatar (an animated anime girl) and the voice is modulated to fit the part as well
Edit: Look: you can be excited by some tech advance, but no - 2022 remains part of an ongoing global disaster. The above quoted sentence is hardly manageable. The best it deserves is to be read like some twisted humour.
That is obviously terrible, and I have several personal ties to Ukraine and the conflict, but the arc of humanity is currently getting better. Russia’s invasion of its sovereign neighbor is bad, but I wouldn’t call it globally bad, unless this turns into a nuke war.
It already has global effects, plus we’re on the brink of a very serious recession, plus China is not playing ball, plus this whole war is opening pandora’s box that was closed ever since WW2. So no, it takes an incredible amount of techie privilege to ignore it to such extent.
But what I wrote is not "that you should care" - it was that you would better avoid expressions that read naïve and possibly uselessly provocative. When somebody communicates something like "Oh sweet were the times under the iron fist", it better be for a good clear reason.
You should care about your audience - and avoid lacking respect.
It is not a matter of «[going] wrong», it is a matter of "how" "we are going", and where we are, and where we should have been. What is actually happening in chronicles is not an accident.
Eh it's not so bad in the US. Sure the economy isn't doing too good and gas prices are still high, but most people are overall doing alright. If there was a literal disaster, 9mm wouldn't be selling for $0.20
IMO remans move the risk/reward curve pretty substantially,especially from no-name brands and steel is banned anywhere within an hour of me :( Although I suppose in a true disaster people wouldn't be as concerned about following the BLM/Forest Service rules
Apples to apples it looks like new brass ammo is still about 2x what it cost in 2019.
Sure, but listening to even a minute is difficult. I don't know if there's such a thing as an audio version of the uncanny valley, but were such a concept exist this would fall right there for me. I don't have any issue with naturally high pitched voices but I just can't listening to this.
What a bizarre comment. Do you really think Japanese people and anime fans find heavily-roboticized voices peasant to listen to for long periods of time?
It doesn't matter if Asahi Lina is an avatar of Marcan or not and you're free to discourage people from speculating, especially since it does not seem that Asahi Lina wishes to disclose her real identity.
That does not mean that what you've provided is proof, however.
> drawElements (dEQP) is a very robust and comprehensive set of open-source tests for GLES2, GLES3+ and EGL. They provide a huge net of coverage for almost every GL API feature.
So this is some CSS Acid test for OpenGL Embedded Systems (GLES).
Awesome work, glad to see such progress. Why is this person using such a weird voice modulation? Or are they using a text to voice to engine? It makes it difficult to understand.
Well our best emulator writer in decades killed themselves over harassment for being non binary via kiwi farms murderers (not the right word but nor is simply troll) so why risk the attention if you don’t want it?
How far along is running a regular linux desktop os with working ui on an m1? Recently there were articles that Linus had been using an M1 running some version of linux but there were some aspects of the system that weren't working well, believe it was the ui, maybe he was even in text mode.
See https://github.com/AsahiLinux/docs/wiki/Feature-Support . The laptops are very usable as a daily driver on Linux already, but not 100% is supported and depending on your specific requirements some of the missing hardware support might be a deal breaker. You can very much run a normal Linux desktop with a working UI, that's been working for months, it just doesn't have hardware rendering acceleration (but the CPU is fast enough to make this tolerable).
No, aside from anything else the missing GPU driver means that the system is running at ~60% all-core CPU even at idle (rendering a desktop). IIRC, it still lasts around 4 hours. We'll have a better idea of where they're at once the GPU driver lands.
>That whole "optimized for macOS" thing is a myth. Heck, we don't even have CPU deep idle support yet and people are reporting 7-10h of battery runtime on Linux. With software rendering running a composited desktop. No GPU.
Software rendering simply stinks, doubly so if you're running a fancy composited desktop. Regardless of CPU speed or UI fluidity, your CPU and GPU processes are now fighting for the same cycles, bottlenecking one another in the worst way possible.
The M1 has a fairly good GPU, so there's hope that the battery life and overall experience will improve in the future. As of now though, I'd reckon there's dozens of x86 Linux laptops that can outlast the M1 on Linux. Pitting a recent Ryzen laptop versus an Asahi Macbook isn't even a fair fight.
>Software rendering simply stinks, doubly so if you're running a fancy composited desktop. Regardless of CPU speed or UI fluidity, your CPU and GPU processes are now fighting for the same cycles, bottlenecking one another in the worst way possible.
And yet, after first release use, they have reported that this is the smoothest they've seen a Linux desktop ever run. That is, smoother even when compared to intel-Linux on hw GPU acceleration.
I use llvmpipe currently and I can assure you that it is no where near as smooth as a setup with hardware acceleration. The 3900x is probably even faster than the M1 at software rendering and it still isn't fast enough to give a consistent 60fps with the browser using most of the screen (shrinking the browser window makes things much more smooth).
Even extremely fast CPUs suck really bad at pushing pixels compared to even the weakest GPUs. It is very much usable though!
Currently llvmpipe is able to use up to 8 cores at a time but not more, and does use SIMD instructions when available from my understanding. There is another software rendering system in MESA that allegedly uses AVX instructions but I have had a better experience with llvmpipe personally.
I'd hope that an idle desktop redraws ~nothing and so doesn't waste any CPU cycles. And the GPU not being used might even save power. So as long as it's idle it would ideally consume less power, not more.
CPUs use significantly more power to perform the same amount of computation that a GPU does, because they're optimized for different workloads.
GPU input programs can be expensive to switch, because they're expected to change relatively rarely. The vast majority of computations are pure or mostly-pure and are expected to be parallelized as part of the semantics. Memory layouts are generally constrained to make tasks extremely local, with a lot less unpredictable memory access than a CPU needs to deal with (almost no pointer chasing for instance, very little stack access, most access to large arrays by explicit stride). Where there is unpredictable access, the expectation is that there is a ton of batched work of the same job type, so it's okay if memory access is slow since the latency can be hidden by just switching between instances of the job really quickly (much faster than switching between OS threads, which can be totally different programs). Branching is expected to be rare and not required to run efficiently, loops generally assumed to terminate, almost no dynamic allocation, programs are expected to use lower precision operations most of the time, etc. etc.
Being able to assume all these things about the target program allows for a quite different hardware design that's highly optimized for running GPU workloads. The vast majority of GPU silicon is devoted to super wide vector instructions, with large numbers of registers and hardware threads to ensure that they can stay constantly fed. Very little is spent on things like speculation, instruction decoding, branch prediction, massively out of order execution, and all the other goodies we've come to expect from CPUs to make our predominantly single threaded programs faster.
i.e., the reason that GPUs end up being huge power drains isn't because they're energy inefficient (in most cases, anyway)--it's because they can often achieve really high utilization for their target workloads, something that's extremely difficult to achieve on CPUs.
> it's because they can often achieve really high utilization for their target workloads, something that's extremely difficult to achieve on CPUs.
This part here 100x. It's worth noting that the SIMD performance of the M1's GPU at 3w is probably better than the M1's CPU running at 15w. It's simply because the GPU is accelerated for that workload, and a neccessary component of a functioning computer (even on x86).
The particularly damning aspect here is that ARM is truly awful at GPU calculations. x86 is too, but most CPUs ship with hardware extensions that offer redundant hardware acceleration for the CPU. At least x86 can sorta hardware-accelerate a software-rendered desktop. ARM has to emulate GPU instructions using NEON, which yields truly pitiful results. The GPU is a critical piece of the M1 SOC, at least for full-resolution desktop usage.
You're not really responding to my argument? I was talking about an idle desktop where neither CPU nor GPU perform any work since they don't have to redraw anything. With neither performing work pure software-rendering should let the GPU be turned off rather than put into sleep. Granted, those are mobile chips so the power-management probably is good and there isn't much of a difference between off and deep idle.
IIRC, modern graphics APIs pretty much require you to go through the GPU's present queue to update the screen, so the GPU likely has to be involved anyhow whenever a draw happens, whether or not it's actually drawn on the GPU. Given that, I'm not sure how you could turn the GPU off during CPU rendering except in circumstances when you would already have been able to turn it off with GPU rendering. But I am basing this on how APIs like Vulkan and Metal present themselves rather than the actual hardware, so maybe there's some direct CPU-rendering-to-screen API that they just don't expose.
Interesting, didn't realize that. This explains some of the weirder present queue requirements, I guess (it doesn't really act like a regular queue). So maybe you really can power down the GPU. I still doubt it would be lower power overall, since IME my M1 GPU takes very little power when I'm not using it intensively, but it's at least possible.
If ARM had competitive SIMD performance, then we might be seeing an overall reduction in power usage. The base ARM ISA is excruciatingly bad at vectorized computation though, so eventual GPU support seems like a must-have to me.
Obviously the GPU will be better, but at one point I compared the M1 CPU to other ARM GPUs (in laptops at that time) and found it had both better memory bandwidth and compute throughput, which is quite funny.
That could be true many years ago, but not anymore. GPU is way more efficient at putting many bitmaps in the right place in the output. Even your mouse cursor compositing is hardware accelerated these days because that's faster and more efficient. Doing that on the CPU is wasted power.
7-10 hours is good, but that's still around half of what these machines can do on macOS. And it's just common sense that battery life with software rendering won't be as good when hardware acceleration is enabled.
The 4800u was used in performance comparisons when the M1 dropped. For the record, that was an 18-month-old chip fabbed on outdated, 7nm silicon that was shipping in ~$450 laptops at the time. Brilliant little Linux devices, I've been told.
"Optimized for macOS" is definitely not a myth, but the reality is far more complicated than people believe. There's parts of the OS that are definitely incredibly optimized for the hardware they run on. Then there's some random app that has an O(n^3) loop in it. Operating systems are complex.
Where on Earth are you getting that 60% number? It’s absolutely not true. I just looked myself and it’s sitting at the default KDE desktop showing ‘top’ at literally 0.5% CPU usage.
Thanks. My use case is normal linux use, but I need to occasionally run x86 code in a linux vm. So (1) running linux, (2) running a different arch vm, (3) some gui apps.
I have already been reading the state of running x86 vms on macos on an m1, it is slow but my friends claim usable. Add it on an early linux impl on native m1, then x86 vm.
Why am I torturing myself? I want to get back to having a great fanless system like I used to have on a google pixel laptop, where they had underclocked x86 but running without a fan was great.
If you need to run x86 Linux software on Apple Silicon, the better option going forward will be to run an ARM Linux VM and use Apple's Rosetta for Linux to run x86 software on the ARM Linux, rather than having the kernel also running under emulation.
Since Rosetta for Linux was coerced to run on non-Apple ARM Linux systems almost as soon as it shipped in developer preview builds of the upcoming macOS, it would not be surprising if Asahi ends up making use of it outside of a VM context (though that may not comply with the license).
You can run a GUI but it would currently run on the CPU not GPU. Reports are that the UI is quite snappy running on the CPU. The basic Asahi install is Arch with KDE. Linus apparently put Fedora on his travel laptop. What Linus was complaining about is Chrome support, which is coming or maybe is already available - https://twitter.com/asahilinux/status/1507263017146552326?la...
I am using Arch/Asahi Linux on a new MacBook Pro M1 Pro since July as daily driver.
I mainly use IntelliJ IDEA for Java and Scala development in KDE (which is installed by default if you choose the UI install). For IntelliJ you have to download the aarch64 JBR yourself and set it in a config file. However upgcoming version 2022.3 will support aarch64/arm OS out of the box...
So far it works very very good. Rendering is done by the CPU, but the machine is so fast it's not really an issue (at least compared to my old Thinkpad). However can't wait for the GPU driver to arrive, looking at the posted tweet., I guess that should happen within the next few weeks.
For Zoom calls (which I don't have so often) I still have to switch to macOS right now, but AFAIK USB 3 support should work also soon, so I can use my Elgato Facecam soon hopefully.
I can listen music/watch youtube with my Pixel Buds Pro via Bluetooth, no problem.
Suspending/closing the lid doesn't freeze the userspace yet, but this is already fixed and will arive soon: https://twitter.com/marcan42/status/1582363763617181696
In the last 4 months I only heard the fan once or twice, when opening dozens tabs that run aggressive adds (animations), but with the upcoming GPU driver that will not be an issue anymore.
And by "hear" I mean like "what is this quite noice...? or that's the macbook fans..." - when I start my old Thinkpad, it's like a airplane in the runway preparing to start.
Battery life is quite good actually, this week I was taking my Macbook out for lunch and working in a coffee for like 2,5 - 3 hours, doing Java/Scala development (but not much compiling actually, just hacking in the IDE) afterwards I had like 69% left.
Also it barely gets hot - it does a bit sometimes in the ads scenario above, but most of the time it stays cool. It does get a bit hot when charging (which is normal according to other users).
Personally, after a long time Thinkpad and Dell XPS user, I am so happy about my Macbook, which is my first, they will have to try hard to win me back. And I am saying this as non Apple user (never had an iPad, MacBook, iPhone, whatever). Asahi + Macbook Pro is really really great and IMHO, even in it's early stage and IMHO for Linux enthusiastics will be the killer device in the upcoming years.
BTW: I bought the Macbook in April and gave macOS a serious chance (after being a pure Linux user since 15 years). Tried to set it up for my needs... But I gave up in July, I just can't handle it, for me it's like a toy. It's good for people (like my wife) who browse the internet and do some office work, but for software devs that need to get shit done fast and like to have an open system its... kind of crap (just my pesonal opionion).
My experience is almost exactly the same. The M1 Air is my first Apple product. I don't like Mac OS after trying it (too dev unfriendly), but love the hardware. I was only willing to purchase the Air because of Asahi Linux (as a backup to giving Mac OS a shot).
> So in mid-2012 he decided to do something about it. He was working for TI at the time, so PowerVR-based GPUs (as used by TI) were off-limits. He found some hardware that had an Adreno 220 and started to reverse engineer it. He began work on a Gallium driver in November 2012. By early 2013, he had most of the "normal stuff" working. He could run GNOME Shell and some games on the hardware.
So it's been done before, but of course Freedreno's Rob Clark is undoubtedly exceptionally good as well.
You have to wonder if the M1 situation would be different if he had been working for another company... (M1 GPU is PowerVR descendant and there hasn't been a open source driver for that lineage historically)
For me it's a bit surprising that there are not more people working on it, the M1 having been out for 2 years already and this having wider appeal than the Freedreno initial users audience.
But, maybe the 1 person way is better, since the Nouveau history seems to be people coming and going and work progressing in fits and starts: https://lwn.net/Articles/269558/
(Also the nouveau people were first to start, so they cleared way and paid a lot of dues saved by subsequent projects)
In context of GP's question, I think this counts as a "no". Apple added a very small feature to make booting Linux easier, which we can safely assume was put there for the benefit of Asahi. Apple broke Asahi's old method in an update, so provided an alternate stable interface.
The only help is from the bootloader side and by not having Apple actively obscuring things.
Conpared to other reverse engineering projects, the M1 macs are not a moving target and they dont have to encounter new lockdowns every time, unlike other reverse engineering scenarios lile the cracking scene or emulators
It's such a minor contribution that I always get a good laugh watching people praise Apple for this. Microsoft, for all the evil they do, contributes millions of SLOC to open source along with generous funding for various non-selfish projects. Facebook, for all the societal ills they cause, also develops multiple projects in public even when it would make more sense to withhold them. Apple, for all their exploitation of the developer community, flips a switch on the Macbook that enables parity with traditional x86 BIOS functionality, and people start partying in the street crying "this is for us!"
And since then, it's been radio silence from Cupertino HQ. Nobody ever confirmed why they did this. Was it serendipity or loving compassion? Nobody can say for sure, but if it's the latter then Apple seems to be very conservative with their blessings upon the community.
Apple contributes quite a lot to open source (WebKit, llvm, clang in particular but there are other high volume projects), though not so much in the Linux kernel. There are some patches by Apple in Linux though and they've made quite a lot of strides in expediting postbacks internally over the last few years.
I left Apple partly over their poor oss policies, but even I won't sign off on the idea that they don't do any at all.
- WebKit is a co-opted KDE project that was open source before Apple forked it (also LGPL, it would be illegal for Apple to distribute WebKit if it wasn't GPL too)
- LLVM was also open source before Apple bought the core developers
- If Clang wasn't open source then literally nobody would ever use it
There are definitely a few spotty places where Apple tosses up a CUPS patch for Linux or fixes a cross-platform WebKit bug. Relative to the rest of FAANG, though, Apple is unprecedented in their posturing against open source.
I didn't say (or at least didn't mean to imply) that any of those were originated at apple, but that they are high volume ongoing contributions to open source from apple and they could do less on them.
I also don't know why you think apple would particularly care if "no one else used clang." Their goal with developing it was clearly also not exactly altruistic but their contribution of it into open source didn't really benefit them much in the short term in any way that isn't true of other major open source work at other FAANG. Never mind swift, which has basically failed to benefit apple much at all from being open sourced. But if clang were closed lots of people would still use it - everyone developing for macs and iOS. That's probably all that matters to the brass.
In the end I agree that apple is much worse than other FAANG. That is, like I said, part of why I left a pretty nice job there after many years of frustration at the pace of change.
But it's hard to pin down a position on all this that applies to all of apple. Some parts are very friendly (compilers), some parts are obligate mildly friendly (core Darwin/xnu and WebKit), some parts are bristling for change, but while change has been slow contributions have been ramping up as processes change (all of services, the growth area of the company). In the 2 years before I left it went from months to approve a minor patch to OSS to more like a week, with certain internal projects having regular unreviewed postback rights to designated high volume OSS projects and official champions of upstream efforts.
Where there seemed to be zero progress at all was personal projects, where apple has a catch-22 process that never progresses while insisting that you can't do it outside that process (regardless of the legality of that assertion).
1. The XNU kernel isn't novel, and isn't used by anyone other than Apple. Open-sourcing the NT kernel would effectively kill the project, since everyone would port the Win32 bindings to Linux (same thing would happen if Apple open-sourced their userland software)
2. Apple didn't get to choose whether they could make LLVM/Clang open source. They were forced to release it under GPL, and if you actually look at the license for those projects you'll see that Apple's contributions are dual-licensed.
3. What chance would FoundationDB have if it wasn't OSS? Why would Apple maintain a stale, internal fork of Apache Cassandra?
Nether llvm nor clang are GPL, dual licensed or otherwise. They're Apache 2.0[1] (or formerly a quasi-MIT/X11 license[2]), as is swift[3].
The binaries of the compilers they release with the platform are also built with internal forks that have some differences with the public llvm/clang/swift trees and that wouldn't be possible with gpl.
1. NT kernel is neither novel nor used by anyone other than MS. Open sourcing the NT kernel would effectively kill the project as its security issues would be fully exploited with wide range impacts on literally everyone.
2. LLVM/Clang are not GPL licensed, they are apache 2.0 licensed. Open sourcing contribution is just open source contribution, it is not about whether you get to choose the license or not.
3. Well, SQL Server is a pretty good demonstration that proprietary database software can survive for decades.
Or, more accurately, it's historical inertia. Macs are "computers", iPhones and iPads are "devices".
The arguments that Cupertino used to defend against Epic in court were roughly that Macs were inherently less secure than their locked-down devices, and that this was a deliberate security trade-off that they were not willing to allow iOS users to make. In other words, something you carry around in your pocket is such a potent malware and spyware vector that users cannot be trusted to decide for themselves.
I personally think this is a half-truth. If Apple had started with portable devices first and then scaled up to the Mac, rather than them starting with PCs[0], they absolutely would have tried to sell it locked-down. Both the tech and the impetus to lock down the iPhone did not exist when the Mac was first made, and the iPad is evidence of this. While there are legitimate user-interface reasons for iPads not running macOS, there is no argument for why they can't have the same security policy as a Mac[1]. But it was borne from iOS[2] and intended to displace personal computers, and thus inherits all of the iPhone's baggage, including the App Store lockout with no owner override.
Since Macs were always open, Apple's management can't insist on locking the system down without pushback both internal and external. Software developers expect to be able to ship their own software ecosystems and users expect to be able to have full control over their Macs. Locking down the Mac makes it a worse Mac, because the product is defined by it's openness.
[0] The Mac and everything that came before it.
[1] Nor is there an argument for why Apple TV can't have an owner override, either. It's even less capable of spying on you than your Mac!
[2] This is actually backwards; the iPad came first as a tablet tech demo and then it's tech lifted to make the iPod Phone work. But then Apple backported the finished phone OS onto the iPad, which is where all the iPhone-isms come from.
> Locking down the Mac makes it a worse Mac, because the product is defined by it's openness.
s/mac/computer and you're right on the money. All computers are defined by their openness - even Apple products. A basic Turing-capable machine should have the capability to copy arbitrary software to-and-from the memory of the device; iOS doesn't allow this. Now, I've heard every philosophical waxing about "product segmentation" and "muh iPhone security", and all of that is fine. Nobody has to leave the App Store if they don't want to. But Apple's limitation of iPhone capabilities are entirely arbitrary, and there is quite literally nothing that stops them from adding a little toggle-button in iPhone settings that says "Reduced Security Mode" or something. Nothing besides greed.
Apple's ideal of a smartphone is so far-removed from the ideals of general-purpose computing that they need to be litigated into submission, just for common-sense upgrades like a universal charger or upgrading to USB-3.0. They chose this state of affairs for themselves.
Apple generally doesn't get in the way when users want to boot something other than macOS on their Macs, and this has been true for decades. In the late 90s there were distros of Linux for PowerPC Macs (Yellow Dog mainly) and BeOS could run on several models of PPC Macs. And of course, Intel Macs had Boot Camp which originally mainly just a BIOS/CSM compatibility layer that sat on top of Apple's EFI implementation to allow OSes that didn't support EFI or supported it badly (at that point, mainly Windows) to boot on them.
The one hitch in that was the brief period where Macs used a chopped down A-series SoC in place of traditional x86 motherboard components (T1/T2 chips), but they provided Windows drivers for those making the difficulties Linux had with them an issue of drivers rather than inability to boot.
How likely is this to make some kind of stride in the macOS gaming world? Perhaps some kind of "headless" Linux VM that functions similar to parallels or wine that can essentially then run a proton layer to bring macOS up to par with Linux gaming. Can someone with more knowledge than me explain if that is feasible in the coming months/years?
You might see a few games like Diablo 2 or DOOM running, but modern games are almost totally out of the question. The biggest roadblock is getting a complete Vulkan driver, which is at least a few years off. That would allow for DXVK to run, which enables the majority of Proton titles.
And then there's the issue of the stack itself. It's hard enough getting Wine and DXVK to run on hardware designed to run Windows/DirectX respectively, but running it through Rosetta/Box86, on Asahi, using half-finished video drivers, is probably not great for stability. Just my $0.02.
Edit: I thought you were talking about Asahi gaming. The state of Proton on MacOS is hopeless (Valve devs abandoned it after the Catalina announcement), but you can definitely run it in a VM if you're so-inclined. Wouldn't necessarily be any faster than using Windows in a VM, but it's still an option.
I don't think that's at all the goal or even vague direction of the Asahi Linux project. It's to replace macOS, not to run as a VM within it.
It's already possible to do what you want, with Parallels and any modern arm64 Linux distro, as long as the games are compiled for arm64 / you're willing to take the performance hit of emulation.
Not really macos gaming but it could be a bit thing for macbook gaming. My only laptop is a macbook and its powerful enough to run many of the games I play but they only run on windows/linux.
1. A Linux VM which has steam installed on it.
2. A project like virglrenderer[1] for macOS and which processes Vulkan commands from the VM with virtio-gpu and sends data back. (I don't exactly know how it's done.)
This would allow games on the Linux VM's steam run at near-native GPU performance.
On the CPU side, there still a need for instruction emulation like QEMU. Or, Apple posted somewhere that you can run x86_64 Linux binaries inside the VM with the help of Rosetta. or an ARM64 Linux VM with Steam running via FEX-Emu.
I’m afraid most of the Linux classic applications will not be designed with multitouch inputs in mind. It may improve eventually, with newer software being created.
That's an obstruction, but usually someone eventually finds a way around that part. But we never get a usable OS for the hardware even if we can run arbitrary code. We have been able to run linux on older iphones for a while now but I'm not sure it's ever been a useful thing to do.
Also another drive by question, but I was surprised that the Apple TVs have A-series chips. Has anyone worked with Asahi on the A-series? I assume the performance isn’t great but curious about the technical challenges.
The A-series don't support booting from a third party OS, unless someone found a security issue that can be exploited to make it boot something else it won't be possible to run Linux on it.
If you pick up an older device running on an A11 SOC or earlier, they have an unpatchable vulnerability in the bootloader code, so those devices could be repurposed with worrying about a locked bootloader.
I'm not an expert on this, but my understanding is that GPU acceleration in virtual machines uses a "passthrough" method where the graphics calls on the guest system are simply translated to public APIs on the host system, and go through macOS's GPU drivers as usual. VMWare Fusion has had this capability on M1 since about a month or two ago.
This project is designed to provide an open-source replacement for macOS's GPU drivers in order to boot Linux bare-metal, so it solves an entirely different problem. Maybe some of the knowledge will carry over -- especially the userspace side of things Alyssa was working on -- but as far as I know this is not automatically transferrable.
Apple designed a new bootloader that enforces security settings per partition and not per machine, so not only can you run a third party OS, doing so does not degrade the security when you boot the Mac partition.
It really doesn't look like Apple has any intention of locking the Macbooks down. They just don't care all that much about building stuff that's incompatible with other OSs, if someone wants to put the hard work in to making Linux work, there are no unreasonable obstructions.
Yes, it's very un-Apple of them, which some are taking as Apple being accepting and welcoming of other OSes, in particular Linux, on Macbooks. Which is an optimistic take, IMO, even if not unfounded.
It’s not un-Apple of them, people just make up the idea that Macs are going to be locked down next year and have continually made it up for the last 10 years (or more).
Don’t assign to Apple what you can blame to Intel.
I sincerely believe the per-partition security to be an improvement Apple wants, but couldn’t deliver with EFI. It allows developers to have unsigned Beta versions of macOS without degrading security for the other OSes.
The correct straightforward answer is, not yet. (The installer is neither reliable or stable)
This is why everyone else (non-developers) are waiting for a reliable release first rather than trying it out, something goes wrong and another person will find out and say: 'it's not ready for general use.'
Your first sentence is not accurate as, by default, the Asahi installer sets up a separate partition for dual-boot purposes. The Asahi developers have even recommended keeping this configuration in order to receive future firmware updates from Apple.
I remember seeing this wasn't possible because the CPU uses 16KB page tables but GPUs only know how to work with 4KB but I can't find the reference anymore. I don't know if this just requires a change in VBIOS or a whole new GPU but it would mean it's up to nvidia, AMD, or Intel to make a Mac-specific GPU even though no Apple Silicon devices have PCIe slots so it would only be for the small minority of Mac users inside the small minority of eGPU users.
given that thunderbolt 3 is basically PCI,
the only far fetched part would be having to write a 3rd party driver for the card. Given the high end businesses that exist in this world to work with video on the (eg Davinci on the iPad which was recently on the front page), combined with a demand for absolute highest end GPU performance, I think there's a business case for it. I wouldn't hold my breath waiting for it to be open source though.
Considering how little commercial support there is for basic GPU functionality on regular Linux, it's wishful thinking to expect a mysterious stranger to write this code for you. Especially for black-box hardware.
The mysterious strangers I have in mind are Blackmagic Design, who write Davinci Resolve, for both Mac and Linux, and have the economic incentive to. They made $576 million in revenue last year so it's not that far fetched.
* an excellent POC of Rust drivers on Linux
* the dev live-streamed almost every minute of development
* the dev is a virtual anime girl
So far I'm LOVING 2022.