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

291–300 of 322 posts

Re: Native Linux GPU Driver for Apple M1

#291

Post by _piif »

Melatonic wrote: post #130
cguess wrote: post #47

Earlier quoted context omitted.

I don't want to run a web browser to run a desktop app. I don't care how useful it is to run JS and HTML from a dev standpoint it's an absolutely absurdity that my desktop app has a CORS vulnerability.

I could be wrong but I feel like literally running some kind of little mini virtualized instance and just running a desktop app meant for OSX or Windows could end up being more efficient than running a whole browser.....

Or running a more optimized app meant for Windows using WINE.

Re: Native Linux GPU Driver for Apple M1

#292

Post by flyinghamster »

Wowfunhappy wrote: post #226
brokenmachine wrote: post #219

Although I'm thoroughly impressed and applaud people for doing this in their spare time, I sort of wish they wouldn't help Apple in their developer-hostile actions. If Apple don't want to release documentation on their chips, then leave them to rot in their walled garden.

I mean, I guess there are various degrees of hostility. When Apple ported their iOS bootloader to the new Macs, they purposefully added the ability to boot third-party operating systems. They just didn't tell anyone how to actually build a third-party operating system.

Exactly the middle ground, but it's a shame so much has to be reverse-engineered due to lack of documentation. It's quite a contrast from the Apple II, which came complete with schematics and a ROM listing. Obviously, today's computers are nowhere near as simple, but I hate seeing more and more about our systems becoming jealously guarded secrets.

Nonetheless, a half-step like this is vastly better than the locked bootloaders, jailbreaking, and outright hostility of the smartphone/tablet/console world.

Re: Native Linux GPU Driver for Apple M1

#294

Post by BackBlast »

Melatonic wrote: post #130
cguess wrote: post #47

Earlier quoted context omitted.

I don't want to run a web browser to run a desktop app. I don't care how useful it is to run JS and HTML from a dev standpoint it's an absolutely absurdity that my desktop app has a CORS vulnerability.

I could be wrong but I feel like literally running some kind of little mini virtualized instance and just running a desktop app meant for OSX or Windows could end up being more efficient than running a whole browser.....

Not necessarily. If you're running the browser anyway, and the app is a PWA and can share that same instance. The "browser" overhead is not really there.

A native app, lets say that wants to play video and is using a cross platform GUI. You've got to load and run that code, and have all the relevant code in the native app's address space. That would be a bunch of code that needs to load over the PWA which is leveraging something you have loaded in RAM anyway. In this case the native is actually worse than the PWA for resource utilization.

Launch CPU cycles can be similar, running a huge swath of GUI code for the native app vs a pre-loaded browser which only needs to run the JS and render the page.

Having your app's runtime already loaded on the system is a huge advantage.

Electron does not benefit from these advantages though. These are PWA exclusive advantages.

Re: Native Linux GPU Driver for Apple M1

#295

Post by snvzz »

cylon13 wrote: post #252
mnd999 wrote: post #247

Earlier quoted context omitted.

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 ri…

There are fundamental issues with x86 that make it impossible to match the efficiency of ARM. Variable length instruction coding for instance, which means a surprising amount of power is dedicated to circuitry which is just to find where the instruction boundaries are for speculative execution. Made sense in the 80s when memory was scarce and execution was straightforward, but now it’s a barrier to efficiency that’s…

>Variable length instruction coding for instance, which means a surprising amount of power is dedicated to circuitry which is just to find where the instruction boundaries are for speculative execution.

This does apply to x86 and m68k, as "variable" there means 1-16 byte, and dealing with that means bruteforcing decode at every possible starting point. Intel and AMD have both thus found 4-wide decode to be a practical limit.

It does not apply to RISC-V, where you get either 32bit or 2x 16bit. The added complexity of using the C extension is negligible, to the point where if a chip has any cache or rom in it, using C becomes a net benefit in area and power.

Therefore, ARMv8 AArch64 made a critical mistake in adopting a fixed 32bit opcode size. A mistake we can see in practice when looking at the L1 cache size that Apple M1 needed to compensate for poor code density.

L1 is never free. It is always *very* costly: Its size dictates area the cache takes, clocks the cache itself can achieve (which in turns caps the speed of the CPU), and power the cache draws.

Re: Native Linux GPU Driver for Apple M1

#296

Post by snvzz »

dontlaugh wrote: post #283
cylon13 wrote: post #252

Earlier quoted context omitted.

There are fundamental issues with x86 that make it impossible to match the efficiency of ARM. Variable length instruction coding for instance, which means a surprising amount of power is dedicated to circuitry which is just to find where the instruction boundaries are for speculative execution. Made sense in the 80s when memory was scarce and execution was straightforward, but now it’s a barrier to efficiency that’s…

And sadly this partly applies to RISC-V too. It only achieves competitive density with the (optional) instruction compression, which makes instructions vary in length. Not as big of a problem as on x86, but still a fundamental limitation.

>sadly this partly applies to RISC-V too.

Not in any way that has any relevance.

>Not as big of a problem as on x86, but still a fundamental limitation.

Huge understatement. Instructions being any size 1-16 (x86) vs being either 16bit or 32bit long (RISC-V).

As with everything else in RISC-V, the architects did the weighting, and found that the advantage in code size overwhelms the (negligible by design) added decoding cost, for anything but the tiniest of implementations (no on-die cache + no builtin ROM).

As it turns out, it would be difficult to even find a use for such a core, but in any event it is still possible to make one such very specialized chip, and simply not use the C extension.

Such a use would be deeply embedded, and the vendor would be in control of the full stack so there would be no concerns of compatibility with e.g. mainstream Linux distributions. They would still get ecosystem benefits; they'd be able to use the open source toolchains, as they support even naked RV32E with no extensions.

Re: Native Linux GPU Driver for Apple M1

#297

Post by chris_wot »

coldtea wrote: post #209
rand0m4r wrote: post #185

Earlier quoted context omitted.

The answer could be: because they like it. People do great stuff with computers and programming and I think this is a good example. Passion is what it's all about.

This is not about just doing it for passion or for hacking fun despite being worthless of something. There's a very pragmatic reason that makes it very useful! The "why bother" is missing the crucial point, that the most important use of the GPU driver for Asahi would be HW accelerated desktop (and driving external monitors, etc) - it's not like a GPU driver for M1 is useless if no AAA games aren't supported...

I totally concur, AAA games aren’t really the main driver for desktop Linux anyway.

Re: Native Linux GPU Driver for Apple M1

#299

Post by bacchusracine »

coldtea wrote: post #205
bityard wrote: post #133

Earlier quoted context omitted.

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.

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

>We want Linux on our Mac laptop, with hw acceleration for the desktop and apps.

Again, why bother?

Why continue to choose user hostile hardware made by a manufacture who seeks to frustrate your precise desire to do this? Wouldn't it be much more logical to purchase from a manufacturer who doesn't care what you use on the hardware--or even better yet, actively supports you in getting the hardware to perform as well as possible with Linux? What is the point in continuing to chase after hardware which doesn't fully work in your chosen operating system with your preferred applications? Why pay full price for hardware that will never be fully supported and work to its full potential?

Re: Native Linux GPU Driver for Apple M1

#300

Post by renox »

snvzz wrote: post #295
cylon13 wrote: post #252

Earlier quoted context omitted.

There are fundamental issues with x86 that make it impossible to match the efficiency of ARM. Variable length instruction coding for instance, which means a surprising amount of power is dedicated to circuitry which is just to find where the instruction boundaries are for speculative execution. Made sense in the 80s when memory was scarce and execution was straightforward, but now it’s a barrier to efficiency that’s…

>Variable length instruction coding for instance, which means a surprising amount of power is dedicated to circuitry which is just to find where the instruction boundaries are for speculative execution. This does apply to x86 and m68k, as "variable" there means 1-16 byte, and dealing with that means bruteforcing decode at every possible starting point. Intel and AMD have both thus found 4-wide decode to be a practica…

Maybe. If I remember well, Apple ARM M1 can decode up to 8 instruction at the same time, is-there any RISC-V CPU with the C extension which is able to decode 8 instructions?
Post reply on HN