I'm in awe of anyone who can reverse engineer and build a driver for something like this that isn't documented at all (AFAIK). Impressive stuff. And to use that knowledge to contribute to Linux is a great thing. Kudos to everyone involved.
Native Linux GPU Driver for Apple M1
141–150 of 322 posts
Re: Native Linux GPU Driver for Apple M1
#142I'm just getting old, I do not understand VTubers or the appeal.
Complete speculation on my part, but I think the biggest appeal is supply side, that people can be Internet personalities with an avatar without sharing their real identity. That helps a lot of people who would like to start sharing content but are otherwise too shy, or for various reasons think they can’t/shouldn’t use their real identity.
On the consumption side, I find the VTuber method to be more compelling than pure voiceovers, even if it’s silly. An avatar helps create a sense of engagement. It’s also interesting to see what sort of characters people come up with.
Re: Native Linux GPU Driver for Apple M1
#143Can anyone explain why it's hard to get GPU-accelerated ML libraries such as Torch running on a Mac (Intel or M1/M2)?
Re: Native Linux GPU Driver for Apple M1
#144Earlier quoted context omitted.
What AAA games run not only on Linux, but ARM Linux? This is more for going on YouTube with hardware acceleration than gaming, which is niche upon niche in its current state anyway.
Do Rosetta apps utilize the GPU on M1 (on macOS)?
Yes. The calls to the platform graphics APIs and underlying drivers are identical (and literally hit the same code), whether from x86/Rosetta or native/ARM64.
Re: Native Linux GPU Driver for Apple M1
#145"Please temper your expectations: even with hardware documentation, an optimized Vulkan driver stack (with enough features to layer OpenGL 4.6 with Zink) requires many years of full time work. At least for now, nobody is working on this driver full time3. Reverse-engineering slows the process considerably. We won’t be playing AAA games any time soon." From https://rosenzweig.io/blog/asahi-gpu-part-6.html
Totally non-sarcastic question: then why bother? It's an honest question. Even if someone (or a team) could somehow be paid for this work, by the time the results are usable, the hardware will be more or less functionally obsolete. And that is on top of the fact that ARM64 on MacOS will always be a small slice of the gaming pie, and ARM64 on Linux games and GPU applications virtually nonexistent.
Machine learning
Re: Native Linux GPU Driver for Apple M1
#146"Please temper your expectations: even with hardware documentation, an optimized Vulkan driver stack (with enough features to layer OpenGL 4.6 with Zink) requires many years of full time work. At least for now, nobody is working on this driver full time3. Reverse-engineering slows the process considerably. We won’t be playing AAA games any time soon." From https://rosenzweig.io/blog/asahi-gpu-part-6.html
Totally non-sarcastic question: then why bother? It's an honest question. Even if someone (or a team) could somehow be paid for this work, by the time the results are usable, the hardware will be more or less functionally obsolete. And that is on top of the fact that ARM64 on MacOS will always be a small slice of the gaming pie, and ARM64 on Linux games and GPU applications virtually nonexistent.
note it’s probably a lot less effort to add support for M2’s GPU than starting from scratch and having to reverse engineer everything.
So eventually the gap between hardware release and fairly complete driver support could close quite a lot.
Re: Native Linux GPU Driver for Apple M1
#147"Please temper your expectations: even with hardware documentation, an optimized Vulkan driver stack (with enough features to layer OpenGL 4.6 with Zink) requires many years of full time work. At least for now, nobody is working on this driver full time3. Reverse-engineering slows the process considerably. We won’t be playing AAA games any time soon." From https://rosenzweig.io/blog/asahi-gpu-part-6.html
Totally non-sarcastic question: then why bother? It's an honest question. Even if someone (or a team) could somehow be paid for this work, by the time the results are usable, the hardware will be more or less functionally obsolete. And that is on top of the fact that ARM64 on MacOS will always be a small slice of the gaming pie, and ARM64 on Linux games and GPU applications virtually nonexistent.
There's a much lower standard than "AAA gaming" which still delivers massive value to most users in running a desktop environment.
Also, the Apple GPU has evolved from PowerVR roots dating back to the 1990s. It is fairly safe to assume that the next generation of Apple GPU will share enough with the current generation that in 3 years, supporting whatever new hardware exists will be incremental rather than transformative ground-up work.
This was already the case for M1 into M2.
Re: Native Linux GPU Driver for Apple M1
#148Can anyone explain why it's hard to get GPU-accelerated ML libraries such as Torch running on a Mac (Intel or M1/M2)?
In each library, their operations need to be implemented for each backend separately (CPU, GPU, TPU, etc). All of these libraries support CUDA as their default GPU implementation because it’s by far the largest in terms of market share. But since Apple GPUs do not implement CUDA or a translation layer (they use Metal, Apples graphics and compute acceleration library), that means all those mathematical operations need to be rewritten targeting Metal before torch can even communicate usefully with an M1/M2 GPU. That doesn’t even touch on the fact that different backends need to have work scheduled on them slightly differently. Some expect a graph of operations to be submitted, some are just submitted as a series of asynchronous operations, etc.
Also just wanted to point out that torch does support Apple GPUs now, however.
Re: Native Linux GPU Driver for Apple M1
#149Earlier quoted context omitted.
> I can't imagine it being enough to load many electron apps in a few years time. I honestly hopoe Electron has to improve it's performance or companies start moving off of it. It's honestly a bit of a joke at this point.
Are you all using some rare electron apps that are unknown to me because I keep hearing this meme repeated but when I look at my RAM usage[0], it never corroborates this. I just don't see how 220MB for Discord is unreasonable in any way, when Firefox with 8 tabs takes 1.2GB. Telegram written in Qt meanwhile takes 200MB, literally no difference to Discord, an electron app. [0] https://i.imgur.com/cfCRWDS.jpg
Because weechat uses <18 megs?
Re: Native Linux GPU Driver for Apple M1
#150The November 2020 M1 machines are nearly getting to daily usability in Linux. Support for screen brightness adjustment, the webcam, speakers and mic are the remaining things for day to day use for me. All look like they should be working in 6 months-1 year. It's a bit of a shame that the RAM is so limited on all those platforms - I can't imagine it being enough to load many electron apps in a few years time.
It's enough memory for most applications that are not Electron. Not to say that it should not have more, far from it. But the Electron framework is so wasteful, compared with basically all the alternatives. I wish the framework developed for Sublime Text were not secret.
Yeah it's funny that every cross-platform UI kit seems to suck, but both Unity and Sublime have in-house custom things that are good.
Que pedo, wey.