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

Tales of the M1 GPU

asahilinux.org

Post reply on HN
Print view View original

31–40 of 390 posts

Re: Tales of the M1 GPU

#31

Post by Arelius »

worldsavior wrote: post #7
2OEH8eoCRo0 wrote: post #2

Apple should upstream their drivers. Who is Asahi Lina? Is that an actual person?

Asahi Lina is a maintainer in Asahi Linux project. She is now much known because of the achivement she earned, programming the Asahi Linux GPU driver for MacOS.

I assume you mean Asahi Linux GPU driver for Mac M1? or does this run ontop of MacOS somehow?

Re: Tales of the M1 GPU

#32

Post by bogeholm »

dkdbejwi383 wrote: post #26
wincy wrote: post #10

Earlier quoted context omitted.

I think it’s a vTuber anime persona of a very talented programmer or something?

And, sorry for continuing this thread, what is a "vTuber anime persona"?

vTuber = virtual YouTuber (YouTube as genericized term for “video platform”, as in Xerox for copying)

Anime = Japanese cartoon style

Re: Tales of the M1 GPU

#33

Post by gjsman-1000 »

abdusco wrote: post #30
masklinn wrote: post #21

Earlier quoted context omitted.

Porting what?

GPU driver. So that one can install Windows on Apple Silicon and get accelerated graphics.

It would take more than a GPU Driver, or actually, drivers at all.

Windows has some behavior that is hard-coded and cannot be changed except by Microsoft. This behavior can fairly easily be bent on Linux, but Windows drivers can't bend the rules for some of these issues.

The biggest issue that immediately comes to mind is that the M1 MMU (Memory Management Unit) only can handle 16K pages. Linux can easily be built for 16K, and most programs work on 16K, but Windows currently only supports 4K on ARM. No driver can fix that - only Microsoft. Of course, if Microsoft joins the Apple Silicon train (which Apple has said they are more than welcome to do), then they probably will have official Apple documentation and not need the Asahi Linux findings.

Re: Tales of the M1 GPU

#36

Post by wincy »

dkdbejwi383 wrote: post #26
wincy wrote: post #10

Earlier quoted context omitted.

I think it’s a vTuber anime persona of a very talented programmer or something?

And, sorry for continuing this thread, what is a "vTuber anime persona"?

It’s like a full time filter where the only online identity someone presents is as an anime girl. I think it was popularized by a company called HoloLive that has Japanese girls do this as a full time job? It’s a VERY niche culture thing.

Check out the Asahi Lina channel to see what I mean.

https://m.youtube.com/watch?v=LonzMviFCNs

Re: Tales of the M1 GPU

#37

Post by hedgehog »

nicoburns wrote: post #15

The m1n1 hypervisor specialised for debugging is a pretty genius idea. Is anyone aware of anyone else taking a similar approach? Seems like it would be a pretty generally applicable technique and would make OS/hardware driver development a lot more approachable.

Some developers used user mode Linux for driver development, and I think some development has happened on the NetBSD rump kernel more recently. I find the work that goes into building this kind of tooling all pretty impressive.

Re: Tales of the M1 GPU

#38

Post by psychphysic »

dkdbejwi383 wrote: post #26
wincy wrote: post #10

Earlier quoted context omitted.

I think it’s a vTuber anime persona of a very talented programmer or something?

And, sorry for continuing this thread, what is a "vTuber anime persona"?

One of those threads where you comment and more questions are raised that feel almost irrelevant.

From what I have gleaned, vTuber is a virtual YouTuber. The streams use an anime model a s behaviour.

So we've no idea who it is.

And for some reason I feel creeped out now. There is something perturbing about the saccharin persona coupled with the pseudonym.

Like Pennywise (It) vibes?

Re: Tales of the M1 GPU

#39

Post by monocasa »

tiahura wrote: post #20

Is anyone porting the GPU driver to Windows?

I think there's larger barriers to getting windows running on Apple Silicon that would need to be addressed first.

For one example, Windows ARM kernels are pretty tied to the GIC (ARM's reference interrupt controller), but Apple has its own interrupt controller. Normally on ntoskrnl this distinction would simply need hal.dll swapped out, but I've heard from those who've looked into it that the clean separation has broken down a bit and you'd have to binary patch a windows kernel now if you don't have source access.

Post reply on HN