10 ms·

Asahi Linux: July 2022 Release and Progress Report

201 points by pantalaimon 4y ago

alberth 4y ago
Has anyone ran a web server on M1/Linux? Thoughts, comments, observations?
- RMPR 4y ago
  https://news.ycombinator.com/item?id=32140475 https://news.ycombinator.com/item?id=32140475
wdb 4y ago
Amazing work. I should check their website if it supports dual boot. I can't wait to try it out once a nice new Mac Mini is getting released :)
- themadturk 4y ago
  Definitely supports dual boot...it's baked into Apple's bootloader, so it's pretty much the only way it works.
pmarreck 4y ago
Tremendous progress. Hope to see some fun GPU support next year sometime!
yewenjie 4y ago
I am curious, is there anybody using Asahi Linux as their daily driver?
- e40 4y ago
  Not a daily driver but a server for porting work to Linux ARM. We had trouble finding a cheap ARMv8.1+ server, and the M1 really fit our needs. We're doing builds in a docker of Amazon Linux 2 ARM since the main use case for our software is running on AWS Graviton 2/3 instances.
pieter_mj 4y ago
Best bet for linux on the desktop, limit it to Apple hardware.
hendersoon 4y ago
Wow, they got the GPU working! Does this imply we can anticipate GPU virtualization in MacOS VMs (not running on a MacOS host) at some point?
petercooper 4y ago
Asahi Lina's livestreams (mentioned in the post) are very interesting and well worth a look, by the way. Clearly a very talented developer, but with a cool aesthetic and approach too.
- oynqr 4y ago
  Is anyone convinced it's not just marcan?
  - pseudo0 4y ago
    I'm sure they just coincidentally have the same machine name, and both happen to have /home/marcan directories.
paulmd 4y ago
> Unfortunately, it seems a subset of monitors have a strangely broken behavior where, when waking up from standby, they will virtually disconnect their inputs a few seconds later, then connect them again. I'd be curious to know whether disabling "EUP Compliance"/"EUP Deep Sleep" mode resolves this issue. The long and short of it is that the EU passed some idle power requirements that monitor companies found difficult (or expensive?) to implement and it's caused basically a decade of weird bugs in PCs, docks, and other hardware. To hit the power target they put the monitor into a really really deep sleep state and some of the implementations don't always wake up properly, or do weird things as they wake back up and restart. (this occurs even on some premium monitors and brands... my Dell P2715Q is a very high-end monitor for its day and it has bad issues with freezing after wakeup!) This is the source of the classic "my monitor sometimes won't wake up after my PC goes to sleep, until I cycle the power to the monitor" and "all my desktop icons reshuffle themselves after sleep" and I suspect also the root cause of many "displayport issues" with thunderbolt docks. I think EUP power draw is also why many monitors "disconnect themselves" when idle... from the perspective of the PC it's in a deep enough state it's not even responding. This is legal behavior according to the spec, it's not incorrect to do so, but it's not required, and it confuses the PC which obviously now thinks the monitor is disconnected. I don't have any fine-grain knowledge of exactly what they are doing when they wake up but... rebooting the monitor as a method to wake it up from a deep-sleep state wouldn't surprise me all that much. It would explain the "desktop icons shuffling themselves" failure mode, windows sees a disconnected monitor (even for a second) and goes to the fallback virtual monitor (640x480 res), that's the classic behavior for a disconnected monitor, and rebooting explains why it would disconnect. Apologies to the planet, I wish it wasn't implemented so poorly, but, turning off EUP Deep Sleep is pretty much the first thing you should do when you buy a monitor.
ZiiS 4y ago
Love to know the progress on Macbook external displays (i.e. Thunderbolt). This is what is blocking my daily driving.
schaefer 4y ago
Okay, I don't have a mac. But the discussion of Apple's design for the trackpad and keyboard is fascinating. Running the touchpad and keyboard through an embedded M3 microcontroller that's wired to the rest of the system over the SPI bus rather than USB for both lower latency and higher power efficiency.
- p_l 4y ago
  It's somewhat common approach (I think USB was only done in Macs, in fact). HID over I2C/SPI is somewhat common solution, taking over from PS/2, and of course you need an MCU for the matrix scanner and the touchpad anyway.
  - pantalaimon 4y ago
    I'm a bit surprised they have two MCUs though (BCM5976 and STM32)
    - p_l 4y ago
      the BCM5976 is dedicated touchscreen ASIC that Broadcom makes for Apple for their iPhone and iPad devices, there's probably MCU (or four, this is broadcom we're talking about) inside, but that's probably because it's simpler to implement this way.
      - magicalhippo 4y ago
        Reminded me of the Raspberry Pi Pico W[1], where they paired a dual-core ARM Cortex M0+ MCU with a wifi chip that has both a Cortex M3 core and a Cortex M4 core[2]. The Arduino Unos being paired with an ESP-01 module is similar. Tons of other examples out there as well of course. Not sure if there's a similar "power inversion" at play here, just find it funny when it shows up. [1]: https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-platform/ https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-... [2]: https://www.infineon.com/cms/en/product/wireless-connectivity/airoc-wi-fi-plus-bluetooth-combos/cyw43439/ https://www.infineon.com/cms/en/product/wireless-connectivit... (see block diagram)
vladdoster 4y ago
Cool to see this project is still alive. I made a small contribution[0] almost 1.5 years ago when this project debuted. Best of luck with future endeavors. [0]:https://github.com/AsahiLinux/AsahiLinux.github.io/pull/4 https://github.com/AsahiLinux/AsahiLinux.github.io/pull/4
- coldtea 4y ago
  >Cool to see this project is still alive Just "still alive"? They delivered solid results very fast, and never lost steam...
  - vladdoster 4y ago
    Not sure how else I'd describe it. It's either dead or alive.
    - dev_tty01 4y ago
      You could have said "still thriving" or something similar. "Still alive" has connotations of barely surviving. This team has been doing incredible work incredibly quickly from the beginning.
    - endorphine 4y ago
      Or alive and kicking.
czzr 4y ago
I’m not even planning to run Linux on an Mx machine and these updates are fascinating - kudos to whoever writes them, great job!
sidkshatriya 4y ago
This is a great project. Can Apple be incentivized somehow to help the Asahi Linux folks? It is not possible to simply reverse engineer everything nowadays -- it could take years to build a polished system and in the meanwhile there will always be new hardware from Apple. It's a never ending game of "catch up". Are there some scenarios where Apple might want to allow "proper" Linux on Mx to happen ? The fact that Apple has not totally locked down these machines is tremendously heartening. Could it be in Apple's interest to somehow help the Asahi guys move faster -- release hardware specifications in the open etc.? I think that if Apple hardware releases Mx hardware specs, a high quality linux implementation can then take shape on the Mx. This will create some competition with the Apple software folks. People will benchmarks software running on Mx Linux vs Mx MacOS. This could create some healthy competition. Just like the arrival of llvm helped gcc improve its game, a well functioning software stack on Mx Linux can create some healthy competition for the Apple software team. Their software is quite decent already -- it can achieve greater heights with some competition !
- xanaxagoras 4y ago
  > This is a great project. Can Apple be incentivized somehow to help the Asahi Linux folks? > It is not possible to simply reverse engineer everything nowadays -- it could take years to build a polished system and in the meanwhile there will always be new hardware from Apple. It's a never ending game of "catch up". I would think it's very much in their favor to help. If it takes years to build a polished release, a lot of people will value years old apple hardware over whatever more recently released. Cut that down to months and they just added a new (albeit smaller) segment chomping at the bit for their latest hardware.
- fweimer 4y ago
  It's very difficult to do more to help Asahi Linux. If they upstreamed things properly into Linux (which is arguably the most cost-effective way to support hardware on a broad scale), Mesa, QEMU and related projects, Asahi Linux as a separate project would turn obsolete fairly quickly.
  - humanwhosits 4y ago
foxhill 4y ago
this is something that has always puzzled me about bluetooth, which this article has reminded me of: why are there no bluetooth controllers that operate over pcie? well, with the now notable exception of these macs, apparently. i’d looked for them in the past, but could never find one. i always thought i’d just never looked in the right places, or there were a few obscure vendors for them. but the fact that bluetooth over pcie is not supported in linux yet indicates there might not be any out in the wild at all! very strange.
- kitsunesoba 4y ago
  Running Bluetooth over USB has always struck me as a bit of an odd choice. With USB having to run through the CPU, doesn’t that make things like Bluetooth audio more susceptible to load-induced dropouts? Would make more sense from my layman perspective to have it handled by a CPU-independent controller over PCI-E?
  - AshamedCaptain 4y ago
    No CPU has any problem running audio through basically any interface anymore ever since the Windows 9x days; compressing audio will actually use significantly more CPU than transferring it. If your platform is so constrained the CPU can't send audio inline over USB, then it most definitely won't be able to compress it anyway. For such a scenario, there are Bluetooth controllers that send audio data out-of-band (e.g. through a I2S link), and may even perform the compression in hardware. But this is hardware that is significantly limited, not a PC.
- pmorici 4y ago
  Probably because Bluetooth has always been relatively slow while also being meant for battery operated devices. PCIe’s bandwidth is way overkill and the nature of pcie makes it more complex to implement while also taking more power than simpler low power alternatives.
- AshamedCaptain 4y ago
  What would be the benefit of that? Even the few PCI express add-on bluetooth cards that are "PCI only" have a small USB controller builtin. So the host OS sees a USB addon card with a Bluetooth device hanging from it. There's zero drivers needed since both the USB controller and the Bluetooth USB device is standarized. If you now decide to remove the USB controller, all you're doing is suddenly making an incompatible interface that now requires drivers for questionable benefits. I will vote to keep the standard any other day. That said, most PCI addon cards just ditch the onboard USB controller and force you to connect the USB bluetooth device to the USB controller on the motherboard, though. And THEN they require drivers anyway because volatile firmware or whatever.
butokai 4y ago
I am astonished by the progresses made by the Asahi folks. In particular, having been a Linux user for the past 15 years or so, I can't wrap my head around the fact that a single developer can get such impressive results in reverse engineering a device --- be it storage, Bluetooth, and now even the GPU! How can this be so different from the situation with, say, the nvidia drivers, or even many wi-fi drivers, where it took years of effort from the community before reaching fully working drivers?
- tambourine_man 4y ago
  Same. GPU in particular, seems like magic to a layman’s eye like mine. Bluetooth and WiFi reverse engineering is something I can conceptually grasp from afar, especially because they should be relatively similar across architectures. They are well defined protocols, you send and receive packages. OK. But GPUs are such complicated beasts, each on it’s own snowflakey way, I don’t even understand how the work on a deep level, let alone imagine how reverse engineering would begin. Memory access and sharing with the CPU, shaders, a massively parallel computing model. Crazy stuff. Oh, and you also get to draw lots of triangles really fast while you’re at it.
- rvz 4y ago
  > How can this be so different from the situation with, say, the nvidia drivers, or even many wi-fi drivers, where it took years of effort from the community before reaching fully working drivers? Support for Apple Silicon has much less device combinations to deal with unlike what you see with other devices. There is only one type and fixed set of GPU, storage, wifi, bluetooth drivers to support vs the hundreds of hundreds of GPU variants, with the infinite combinations of other devices found on PCs. Also the so-called 'open-sourcing' of the Nvidia drivers which got the Linux fans too excited, only to be disappointed to realise that Nvidia was not only still working against them, but the news of this announcement turned out to be a red herring. Pushing GPU FFI wrapper code to binary blobs is still not 'open-source'.
- Topgamer7 4y ago
  Marcan is quite the talented reverse engineer and low level engineer. From watching him on YouTube, and a small bit of research into his past (Wii/PS3 pwning), he figures out ways to creatively solve problems, and provide himself with fast feedback on the tough problems he works on. M1n1 is case and point.
nudpiedo 4y ago
for me the astonishing part is not only the development speed, but also the eGPU support on Linux. That's something which just doesn't work on Mac OS and won't unless Apple decides to support third party hardware which isn't going to happen any time soon. I hope over the next months there is a way to access eGPUs without giving up the macos installation, even if it is over some Asahi VM with direct access to the hardware somehow.
- gjsman-1000 4y ago
  Asahi Linux has said that the M1 is plagued by the same ARM bug as the Raspberry Pi 4, and so eGPUs will never be supported with the Linux driver. It can, theoretically, be enabled, but be prepared to give up a lot of hardware security and also expect every app you want to use to need a patch because it breaks ABI.
  - nudpiedo 4y ago
    If I understood it correctly, the video at the end of the post is already using an eGPU. Do you have any pointers, either blog or article, regarding the issue with arm and the raspberry pi?
    - Wowfunhappy 4y ago
      > the video at the end of the post is already using an eGPU. That’s actually a non-Apple-Silicon machine using the M1 as an eGPU, for ease of development.

201 points by pantalaimon 4y ago

alberth 4y ago

Has anyone ran a web server on M1/Linux? Thoughts, comments, observations?

RMPR 4y ago
https://news.ycombinator.com/item?id=32140475 https://news.ycombinator.com/item?id=32140475

wdb 4y ago

Amazing work. I should check their website if it supports dual boot. I can't wait to try it out once a nice new Mac Mini is getting released :)

themadturk 4y ago
Definitely supports dual boot...it's baked into Apple's bootloader, so it's pretty much the only way it works.

pmarreck 4y ago

Tremendous progress. Hope to see some fun GPU support next year sometime!

yewenjie 4y ago

I am curious, is there anybody using Asahi Linux as their daily driver?

e40 4y ago
Not a daily driver but a server for porting work to Linux ARM. We had trouble finding a cheap ARMv8.1+ server, and the M1 really fit our needs. We're doing builds in a docker of Amazon Linux 2 ARM since the main use case for our software is running on AWS Graviton 2/3 instances.

pieter_mj 4y ago

Best bet for linux on the desktop, limit it to Apple hardware.

hendersoon 4y ago

Wow, they got the GPU working! Does this imply we can anticipate GPU virtualization in MacOS VMs (not running on a MacOS host) at some point?

petercooper 4y ago

Asahi Lina's livestreams (mentioned in the post) are very interesting and well worth a look, by the way. Clearly a very talented developer, but with a cool aesthetic and approach too.

oynqr 4y ago
Is anyone convinced it's not just marcan?
- pseudo0 4y ago
  I'm sure they just coincidentally have the same machine name, and both happen to have /home/marcan directories.

paulmd 4y ago

> Unfortunately, it seems a subset of monitors have a strangely broken behavior where, when waking up from standby, they will virtually disconnect their inputs a few seconds later, then connect them again. I'd be curious to know whether disabling "EUP Compliance"/"EUP Deep Sleep" mode resolves this issue. The long and short of it is that the EU passed some idle power requirements that monitor companies found difficult (or expensive?) to implement and it's caused basically a decade of weird bugs in PCs, docks, and other hardware. To hit the power target they put the monitor into a really really deep sleep state and some of the implementations don't always wake up properly, or do weird things as they wake back up and restart. (this occurs even on some premium monitors and brands... my Dell P2715Q is a very high-end monitor for its day and it has bad issues with freezing after wakeup!) This is the source of the classic "my monitor sometimes won't wake up after my PC goes to sleep, until I cycle the power to the monitor" and "all my desktop icons reshuffle themselves after sleep" and I suspect also the root cause of many "displayport issues" with thunderbolt docks. I think EUP power draw is also why many monitors "disconnect themselves" when idle... from the perspective of the PC it's in a deep enough state it's not even responding. This is legal behavior according to the spec, it's not incorrect to do so, but it's not required, and it confuses the PC which obviously now thinks the monitor is disconnected. I don't have any fine-grain knowledge of exactly what they are doing when they wake up but... rebooting the monitor as a method to wake it up from a deep-sleep state wouldn't surprise me all that much. It would explain the "desktop icons shuffling themselves" failure mode, windows sees a disconnected monitor (even for a second) and goes to the fallback virtual monitor (640x480 res), that's the classic behavior for a disconnected monitor, and rebooting explains why it would disconnect. Apologies to the planet, I wish it wasn't implemented so poorly, but, turning off EUP Deep Sleep is pretty much the first thing you should do when you buy a monitor.

ZiiS 4y ago

Love to know the progress on Macbook external displays (i.e. Thunderbolt). This is what is blocking my daily driving.

schaefer 4y ago

Okay, I don't have a mac. But the discussion of Apple's design for the trackpad and keyboard is fascinating. Running the touchpad and keyboard through an embedded M3 microcontroller that's wired to the rest of the system over the SPI bus rather than USB for both lower latency and higher power efficiency.

p_l 4y ago
It's somewhat common approach (I think USB was only done in Macs, in fact). HID over I2C/SPI is somewhat common solution, taking over from PS/2, and of course you need an MCU for the matrix scanner and the touchpad anyway.
- pantalaimon 4y ago
  I'm a bit surprised they have two MCUs though (BCM5976 and STM32)
  - p_l 4y ago
    the BCM5976 is dedicated touchscreen ASIC that Broadcom makes for Apple for their iPhone and iPad devices, there's probably MCU (or four, this is broadcom we're talking about) inside, but that's probably because it's simpler to implement this way.
    - magicalhippo 4y ago
      Reminded me of the Raspberry Pi Pico W[1], where they paired a dual-core ARM Cortex M0+ MCU with a wifi chip that has both a Cortex M3 core and a Cortex M4 core[2]. The Arduino Unos being paired with an ESP-01 module is similar. Tons of other examples out there as well of course. Not sure if there's a similar "power inversion" at play here, just find it funny when it shows up. [1]: https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-platform/ https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-... [2]: https://www.infineon.com/cms/en/product/wireless-connectivity/airoc-wi-fi-plus-bluetooth-combos/cyw43439/ https://www.infineon.com/cms/en/product/wireless-connectivit... (see block diagram)

vladdoster 4y ago

Cool to see this project is still alive. I made a small contribution[0] almost 1.5 years ago when this project debuted. Best of luck with future endeavors. [0]:https://github.com/AsahiLinux/AsahiLinux.github.io/pull/4 https://github.com/AsahiLinux/AsahiLinux.github.io/pull/4

coldtea 4y ago
>Cool to see this project is still alive Just "still alive"? They delivered solid results very fast, and never lost steam...
- vladdoster 4y ago
  Not sure how else I'd describe it. It's either dead or alive.
  - dev_tty01 4y ago
    You could have said "still thriving" or something similar. "Still alive" has connotations of barely surviving. This team has been doing incredible work incredibly quickly from the beginning.
  - endorphine 4y ago
    Or alive and kicking.

czzr 4y ago

I’m not even planning to run Linux on an Mx machine and these updates are fascinating - kudos to whoever writes them, great job!

sidkshatriya 4y ago

This is a great project. Can Apple be incentivized somehow to help the Asahi Linux folks? It is not possible to simply reverse engineer everything nowadays -- it could take years to build a polished system and in the meanwhile there will always be new hardware from Apple. It's a never ending game of "catch up". Are there some scenarios where Apple might want to allow "proper" Linux on Mx to happen ? The fact that Apple has not totally locked down these machines is tremendously heartening. Could it be in Apple's interest to somehow help the Asahi guys move faster -- release hardware specifications in the open etc.? I think that if Apple hardware releases Mx hardware specs, a high quality linux implementation can then take shape on the Mx. This will create some competition with the Apple software folks. People will benchmarks software running on Mx Linux vs Mx MacOS. This could create some healthy competition. Just like the arrival of llvm helped gcc improve its game, a well functioning software stack on Mx Linux can create some healthy competition for the Apple software team. Their software is quite decent already -- it can achieve greater heights with some competition !

xanaxagoras 4y ago
> This is a great project. Can Apple be incentivized somehow to help the Asahi Linux folks? > It is not possible to simply reverse engineer everything nowadays -- it could take years to build a polished system and in the meanwhile there will always be new hardware from Apple. It's a never ending game of "catch up". I would think it's very much in their favor to help. If it takes years to build a polished release, a lot of people will value years old apple hardware over whatever more recently released. Cut that down to months and they just added a new (albeit smaller) segment chomping at the bit for their latest hardware.
fweimer 4y ago
It's very difficult to do more to help Asahi Linux. If they upstreamed things properly into Linux (which is arguably the most cost-effective way to support hardware on a broad scale), Mesa, QEMU and related projects, Asahi Linux as a separate project would turn obsolete fairly quickly.
- humanwhosits 4y ago

foxhill 4y ago

this is something that has always puzzled me about bluetooth, which this article has reminded me of: why are there no bluetooth controllers that operate over pcie? well, with the now notable exception of these macs, apparently. i’d looked for them in the past, but could never find one. i always thought i’d just never looked in the right places, or there were a few obscure vendors for them. but the fact that bluetooth over pcie is not supported in linux yet indicates there might not be any out in the wild at all! very strange.

kitsunesoba 4y ago
Running Bluetooth over USB has always struck me as a bit of an odd choice. With USB having to run through the CPU, doesn’t that make things like Bluetooth audio more susceptible to load-induced dropouts? Would make more sense from my layman perspective to have it handled by a CPU-independent controller over PCI-E?
- AshamedCaptain 4y ago
  No CPU has any problem running audio through basically any interface anymore ever since the Windows 9x days; compressing audio will actually use significantly more CPU than transferring it. If your platform is so constrained the CPU can't send audio inline over USB, then it most definitely won't be able to compress it anyway. For such a scenario, there are Bluetooth controllers that send audio data out-of-band (e.g. through a I2S link), and may even perform the compression in hardware. But this is hardware that is significantly limited, not a PC.
pmorici 4y ago
Probably because Bluetooth has always been relatively slow while also being meant for battery operated devices. PCIe’s bandwidth is way overkill and the nature of pcie makes it more complex to implement while also taking more power than simpler low power alternatives.
AshamedCaptain 4y ago
What would be the benefit of that? Even the few PCI express add-on bluetooth cards that are "PCI only" have a small USB controller builtin. So the host OS sees a USB addon card with a Bluetooth device hanging from it. There's zero drivers needed since both the USB controller and the Bluetooth USB device is standarized. If you now decide to remove the USB controller, all you're doing is suddenly making an incompatible interface that now requires drivers for questionable benefits. I will vote to keep the standard any other day. That said, most PCI addon cards just ditch the onboard USB controller and force you to connect the USB bluetooth device to the USB controller on the motherboard, though. And THEN they require drivers anyway because volatile firmware or whatever.

butokai 4y ago

I am astonished by the progresses made by the Asahi folks. In particular, having been a Linux user for the past 15 years or so, I can't wrap my head around the fact that a single developer can get such impressive results in reverse engineering a device --- be it storage, Bluetooth, and now even the GPU! How can this be so different from the situation with, say, the nvidia drivers, or even many wi-fi drivers, where it took years of effort from the community before reaching fully working drivers?

tambourine_man 4y ago
Same. GPU in particular, seems like magic to a layman’s eye like mine. Bluetooth and WiFi reverse engineering is something I can conceptually grasp from afar, especially because they should be relatively similar across architectures. They are well defined protocols, you send and receive packages. OK. But GPUs are such complicated beasts, each on it’s own snowflakey way, I don’t even understand how the work on a deep level, let alone imagine how reverse engineering would begin. Memory access and sharing with the CPU, shaders, a massively parallel computing model. Crazy stuff. Oh, and you also get to draw lots of triangles really fast while you’re at it.
rvz 4y ago
> How can this be so different from the situation with, say, the nvidia drivers, or even many wi-fi drivers, where it took years of effort from the community before reaching fully working drivers? Support for Apple Silicon has much less device combinations to deal with unlike what you see with other devices. There is only one type and fixed set of GPU, storage, wifi, bluetooth drivers to support vs the hundreds of hundreds of GPU variants, with the infinite combinations of other devices found on PCs. Also the so-called 'open-sourcing' of the Nvidia drivers which got the Linux fans too excited, only to be disappointed to realise that Nvidia was not only still working against them, but the news of this announcement turned out to be a red herring. Pushing GPU FFI wrapper code to binary blobs is still not 'open-source'.
Topgamer7 4y ago
Marcan is quite the talented reverse engineer and low level engineer. From watching him on YouTube, and a small bit of research into his past (Wii/PS3 pwning), he figures out ways to creatively solve problems, and provide himself with fast feedback on the tough problems he works on. M1n1 is case and point.

nudpiedo 4y ago

for me the astonishing part is not only the development speed, but also the eGPU support on Linux. That's something which just doesn't work on Mac OS and won't unless Apple decides to support third party hardware which isn't going to happen any time soon. I hope over the next months there is a way to access eGPUs without giving up the macos installation, even if it is over some Asahi VM with direct access to the hardware somehow.

gjsman-1000 4y ago
Asahi Linux has said that the M1 is plagued by the same ARM bug as the Raspberry Pi 4, and so eGPUs will never be supported with the Linux driver. It can, theoretically, be enabled, but be prepared to give up a lot of hardware security and also expect every app you want to use to need a patch because it breaks ABI.
- nudpiedo 4y ago
  If I understood it correctly, the video at the end of the post is already using an eGPU. Do you have any pointers, either blog or article, regarding the issue with arm and the raspberry pi?
  - Wowfunhappy 4y ago
    > the video at the end of the post is already using an eGPU. That’s actually a non-Apple-Silicon machine using the M1 as an eGPU, for ease of development.