Linux M1 GPU driver passes 99% of the dEQP-GLES2 compliance tests
twitter.com
twitter.com
* 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.
I think Alyssa Rosenzweig and Asahi Lina both did pretty substantial work on this?
(Both of them deserve a ton of praise, of course.)
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.
Ultimately, though, does it matter at all?
(Kudos from marcan trying as much as possible to keep the illusion /s: https://twitter.com/marcan42/status/1582930401118806016?s=46...)
Is there an archive of this dev work?
Stoical irony.
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.
Life is good and only getting better :- Not sure where this “global disaster”, but then again I’m not a Doomer.
Is it?
If one wants to be optimistic, good; celebratory with awareness, with some maturity, well good then; but "locked in a box", no: this is public.
Which of the several dozen currently ongoing global disasters are you referring to, and, bluntly, why should we care?
Because you are living in it. (At least that.)
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.
Yeah, that's about what I figured it would come down to.
I normatively endorse disrespecting anyone naive, oblivious, or self-absorbed enough to think there's only one currently ongoing global disaster.
Material doesn't really matter if you don't reload and just use it for practice.
Apples to apples it looks like new brass ammo is still about 2x what it cost in 2019.
Who's running this operation.
A random stream: https://www.youtube.com/watch?v=jbVQWo0kh9Q
Who had "skilled Linux kernel vtuber writes reverse engineered drivers for Apple hardware" on their 2022 bingo cards?
> 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).
https://github.com/KhronosGroup/VK-GL-CTS/blob/main/external...
It’s tough out there in the culture wars.
Rest in peace Near you magnificent person.
I agree that it makes the videos hard to watch for me, but it's their choice to use and and my choice if I want to watch.
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.
https://developer.apple.com/documentation/virtualization/run...
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).
And this seems to be able to get it running: https://github.com/diddledani/macOS-Linux-VM-with-Rosetta
I haven't tested this because I'm at work, but I'll verify it when I get home!
>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.
https://twitter.com/marcan42/status/1498923099169132545
Also, from a couple of days ago, they got basic suspend to work.
>WiFi S3 sleep works, which means s2idle suspend works!
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.
https://dougallj.wordpress.com/2022/04/01/converting-integer...
https://dougallj.wordpress.com/2022/05/22/faster-crc32-on-th...
https://lemire.me/blog/2020/12/13/arm-macbook-vs-intel-macbo... (I later optimised the slower benchmark in that post: https://github.com/simdjson/simdjson/pull/1708 )
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.
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.
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.
[0] https://asahilinux.org/2021/08/progress-report-august-2021/#...
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.
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.
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...
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).
The total number of people who will be doing this will number in the hundreds. Not to diminish what an interesting achievement it is.
https://lwn.net/Articles/638908/
> 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)
edit: also nouveau history is somewhat chronicled in the early newsletters starting from the early 2006 days: https://people.freedesktop.org/~mslusarz/nouveau-wiki-dump/N...
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
This seems quite a big deal for Apple - and said as a long time Apple user.
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.
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.
- 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 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).
Yes.
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.
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.
* MS still refuses to open source its windows kernel to the public. Apple has its kernel accessible by the entire world.
* MS still refuses to open source its c++ compiler. Apple has swift built by the open source community and there are llvm/clang.
* MS still refuses to open source its sql server, when Apple has FoundationDB for the world and actively contributing to Apache Cassandra.
We are talking about a company that for many many years called open source a cancer.
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?
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] https://github.com/llvm/llvm-project/blob/main/llvm/LICENSE....
[2] https://github.com/llvm/llvm-project/blob/7555c589af006c9c4d...
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.
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.
Indirectly. Apple made some changes in the past that were likely geared towards helping them. Was on kernel not gpu though I think:
https://twitter.com/marcan42/status/1471799568807636994
Don't think they got active help in the "here's the docs" sense
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.
It doesn't make any strides unfortunately.
> Perhaps some kind of "headless" Linux VM
Linux narrowly supports the Steam Deck's goals. It doesn't make sense to use on a device like a Mac.
> Can someone with more knowledge than me explain if that is feasible in the coming months/years?
An end user is best served by Parallels. Overall, it doesn't make sense to run Windows-only games on a Mac.
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.
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.
If so that seems to be shaping up REALLY well!
https://arstechnica.com/information-technology/2019/09/devel...
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.
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.'
Apple has never locked down Macs.
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.