Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native Linux GPU Driver for Apple M1

twitter.com

Post reply on HN
Print view View original

241–250 of 322 posts

Re: Native Linux GPU Driver for Apple M1

#241

Post by zeckalpha »

bityard wrote: post #133
Rygian wrote: post #39

"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.

Just a hobby, won't be big and professional like GNU

Re: Native Linux GPU Driver for Apple M1

#243

Post by [deleted] »

toxik wrote: post #27
angelmm wrote: post #13

I've been following Asahi for some time on twitter. The work she did is incredible and everything was streamed and the recordings are available in Youtube. In case you're curious about the process, here you have her YouTube profile: https://www.youtube.com/AsahiLina

Wow, that's certainly a novel way to disseminate technical information. I could not stand it, and I'm not very dismissive of geek content.

[deleted]

Re: Native Linux GPU Driver for Apple M1

#244

Post by lmm »

jorvi wrote: post #227
acomjean wrote: post #164

Earlier quoted context omitted.

You can't tell people who are doing the work what to work on.. but considering there is a mountain of linux development for people with the expertise to be done for more open platforms. This work pretty much only helps one of the richest companies and Apple shows very little inclination to help by providing documentation or support (they let an alternative OS boot seems to be the extent of it).

And yet Linus used a MacBook Air as his daily driver for many many years. The XPS series might have caught up for a while, but until they flip over to ARM, Apple laptops simply blow anything else out of the water. What’s wrong with trying to run Linux on that?

It sets the wrong incentives. Companies that are more developer-friendly, publishing specs and so on, should be rewarded for it.

Re: Native Linux GPU Driver for Apple M1

#245

Post by sph »

atty wrote: post #142
rufusroflpunch wrote: post #138

I'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…

Maybe I'm old too, but I don't have a problem with avatars and virtual ones, it's the extremely high pitch and cartoony voices VTubere tend to have. And why does it have to be anime or furry aesthetic every time?

Give me Optimus Prime doing kernel Rust coding. Even better, gimme the sarcastic high pitch of Skeletor. I'd also be fine with, I dunno, Lara Croft or other virtual female character.

Everybody has their own preferences, fine, but outside of that overrepresented niche of sexually ambiguous anime and furry there's just... nothing.

Re: Native Linux GPU Driver for Apple M1

#246

Post by [deleted] »

Rygian wrote: post #39

"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

[deleted]

Re: Native Linux GPU Driver for Apple M1

#247

Post by mnd999 »

jorvi wrote: post #227
acomjean wrote: post #164

Earlier quoted context omitted.

You can't tell people who are doing the work what to work on.. but considering there is a mountain of linux development for people with the expertise to be done for more open platforms. This work pretty much only helps one of the richest companies and Apple shows very little inclination to help by providing documentation or support (they let an alternative OS boot seems to be the extent of it).

And yet Linus used a MacBook Air as his daily driver for many many years. The XPS series might have caught up for a while, but until they flip over to ARM, Apple laptops simply blow anything else out of the water. What’s wrong with trying to run Linux on that?

I don’t like your implication that ARM is the only way to do this. The Apple chips are fast and low power because they are good designs built on a very modern fabrication process.

It’s perfectly possible to build such chips with other designs and instruction sets, for example x86_64 or risc-v, in the same way it’s pretty common to build cheaper slower ARM processors. Plenty of folks at Intel and AMD are doing that right now.

Re: Native Linux GPU Driver for Apple M1

#248

Post by ideologysec »

brundolf wrote: post #189
kitsunesoba wrote: post #183

Earlier quoted context omitted.

Web technologies in and of themselves aren't bad, but their usage is strongly correlated with cost-saving measures and the questionable technical decisions that result since choosing a web app itself is often a cost-saving measure. VS Code is an example of things gone right, where Microsoft has clearly hired an AAA-class team and funded them well. Within the same company, Teams is an example of the exact opposite and…

> their usage is strongly correlated with cost-saving measures and the questionable technical decisions that result since choosing a web app itself is often a cost-saving measure Correlation is not causation We can debate the specific design choices that Spotify or any other company has made, but my original point was to push back against the tired trope that using web technologies for an app automatically means runa…

Except in this case, correlation is so strongly correlated with causation that it becomes causation.

Look, the plural of anecdotes is not data, but you can't argue against the general trend of "applications using web frameworks like Electron tend to consume more RAM" by saying "well in this specific case they made poor design decisions that would bite anyone in the ass"; while that may be true it misses the point, which is the much larger (and well-correlated) & overarching tendency of such apps to absolutely chew RAM.

That it's a "tired trope" doesn't make it untrue; it just means that enough people have accepted what is functionally the new state of the software application world that it's considered passé to call such things out.

Re: Native Linux GPU Driver for Apple M1

#249

Post by p1necone »

Underphil wrote: post #221
coldtea wrote: post #205

Earlier quoted context omitted.

> Totally non-sarcastic question: then why bother? Because most of us looking into Asahi don't care for playing AAA games with it. We want Linux on our Mac laptop, with hw acceleration for the desktop and apps.

What AAA games would even run on an M1?

Basically all AAA games will run relatively smoothly (30-60fps) with low-midrange dedicated gpus which is effectively what the M1 performs like on paper (I think it's in the ballpark of the NVidia 1050/1050ti/1650).

You just have to lower the settings and resolution to get that smooth performance - think base model last gen console/nintendo switch levels of visual fidelity rather than up to date gaming pc/current gen console levels of visual fidelity.

It's kinda fun squeezing performance out of woefully underpowered hardware - LowSpecGamer on youtube is a channel dedicated to this kind of stuff.

Re: Native Linux GPU Driver for Apple M1

#250

Post by wtallis »

gpm wrote: post #229
amelius wrote: post #195

Earlier quoted context omitted.

Of course, guarantees in the non-legal sense of the word. If you work towards correctness by design this gives a certain assurance that you don't get if you do a lot of guesswork and hope for the best.

I'd be more sympathetic to this argument, by a lot, if I wasn't constantly encountering bugs in systems where there wasn't (or shouldn't have been) any guesswork needed. To (substantially) rephrase the point, you're saying "there's this additional source of bugs" without an argument that it's a significant enough source that it will stand out against the background of all the other sources of bugs. There's also a str…

> I'd be more sympathetic to this argument, by a lot, if I wasn't constantly encountering bugs in systems where there wasn't (or shouldn't have been) any guesswork needed.

In my experience, you can take any consumer PC (laptop or desktop), install Linux on it, and find a firmware or hardware bug or unsupported hardware feature in the time it takes to read through the kernel log. Often the broken functionality becomes obvious just from the process of trying to boot, log in, and type dmesg. Unless the broken feature in question stems from a component that is wholly unsupported, it is very likely that the flaw is a result of the hardware or firmware's behavior differing from what the documentation or relevant industry standard specifies.

So the status quo is that everybody is always deciding to live without some features that their computer "should" be providing based on its hardware capabilities. Of course, it's perfectly valid for some users to not care about a feature like having a working fingerprint sensor or sensible fan control or automatic brightness, and even more understandable for features that are less readily apparent to the end user (eg. idle power management). But when those gaps between theory/design and reality do get closed, it's usually a result of reverse engineering leading to an acceptable workaround, not the OEM coming back to finish the job.

Post reply on HN