[HN Gopher] An Update on Apple M1/M2 GPU Drivers
___________________________________________________________________
An Update on Apple M1/M2 GPU Drivers
Author : MrBuddyCasino
Score : 138 points
Date : 2024-10-31 20:36 UTC (2 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| renewiltord wrote:
| The work by Alyssa R and Asahi Lina is great stuff. I have to say
| that a lot of this is really inscrutable unless you're used to
| driver code. I wish it were much easier to write this stuff but
| hardware stuff is so idiosyncratic.
|
| Have to say I do enjoy all the old school style whimsy with the
| witch costume and whatnot.
| dylan604 wrote:
| what they do is just this side of magic, so maybe it's not
| really a costume?
| amelius wrote:
| Any sufficiently closed technology is indistinguishable from
| magic.
|
| In fact, the company is so closed that Rosenzweig is the one
| we should consult when we encounter aliens.
| dylan604 wrote:
| I don't think the work they do is what one could call
| closed though is it?
| UncleOxidant wrote:
| Will M3/M4 need completely different drivers?
| wmf wrote:
| Probably. Apple made major changes to the GPU in M3.
| a_wild_dandan wrote:
| What were the major differences?
| coldtea wrote:
| Major base changes, or just added more stuff on top of the
| same base?
| wtallis wrote:
| https://forum.beyond3d.com/threads/apple-dynamic-caching-
| on-... Changing the register file into a cache sounds like
| a major base change. Raytracing is a major feature added on
| top of existing functionality. So I'd say the answer is:
| plenty of both.
| scottlamb wrote:
| > tessellator.cl is the most unhinged file of my career
|
| ...so far. The presenter is only 23 apparently. Maybe I'm
| speaking only for myself here, but I think career unhingedness
| does not go down over time as much as one might hope.
|
| In all seriousness, she does really impressive work, so when she
| says this 2,000 lines of C++ is inscrutable, that gives one
| pause. Glad it's working nonetheless.
| dividuum wrote:
| I guess it's these two files?
|
| The original 2600+ lines of C++:
| https://gitlab.freedesktop.org/asahi/mesa/-/blob/main/src/ga...
|
| The translated code:
| https://gitlab.freedesktop.org/asahi/mesa/-/blob/main/src/as...
| whatever1 wrote:
| She is not doing CI/CD so the PMs would fire her in any
| modern company. "Where are the unit tests?!? How is it
| possible to write code without tests and 100% coverage!"
| wmf wrote:
| OpenGL and Vulkan have tons of tests and Alyssa runs them.
| I don't know if it's automated through CI.
| nwallin wrote:
| It's unfathomable that she's 23 and wrote an open source
| graphics driver for a closed-source graphics card. At least
| Einstein had the decency to wait until he was 26 to invent
| special relativity.
| kachapopopow wrote:
| I always wondered about these /SubscriberLink/ links. Is sharing
| them considered unethical?
| anamexis wrote:
| From the LWN FAQ:
|
| > Where is it appropriate to post a subscriber link?
|
| > Almost anywhere. Private mail, messages to project mailing
| lists, and blog entries are all appropriate. As long as people
| do not use subscriber links as a way to defeat our attempts to
| gain subscribers, we are happy to see them shared.
| vintagedave wrote:
| It says,
|
| > The following subscription-only content has been made
| available to you by an LWN subscriber.
|
| I might be wrong but I read that as there being funding to make
| the previously paywalled content available, probably on an
| article-specific basis. Does anyone know?
| anamexis wrote:
| Also from the LWN FAQ:
|
| > What are subscriber links
|
| > A subscriber link is a mechanism by which LWN subscribers
| may grant free access to specific LWN articles to others. It
| takes the form of a special link which bypasses the
| subscription gate for that article.
| cbhl wrote:
| The purpose of these links is to be shared, see the FAQ:
| https://lwn.net/op/FAQ.lwn#slinks
|
| The LWN paywall is unique in that all the content becomes
| freely available after a week. The subscriber links are there
| to encourage you to subscribe if you are in a position to do
| so.
| sophacles wrote:
| Representatives of LWN have posted here before saying they are
| OK with it, along with a polite request not to have it go
| overboard since they need to fund the site and writers,
| editors, etc. That funding comes from subscriptions only IIUC.
|
| FWIW an LWN subscription is pretty affordable and supports some
| of the best in-depth technical reporting about Linux and linux-
| related topics available.
|
| (I am not affiliated with LWN, just a happy subscriber - I also
| credit some of my career success to the knowledge I've gained
| by reading their articles).
| flykespice wrote:
| It's not different from shared articles here from subscriber-
| only newsletters being accompanied by the archived link in the
| topmost comment.
|
| Users here seem to not care about those "ethics"
| gigatexal wrote:
| Is anyone else astonished at how much is missing in the hardware
| and how much is emulated?
| jsheard wrote:
| The things being emulated are mostly legacy features that are
| barely used in modern software, if at all, so the overhead of
| emulating them for backward compatibility isn't the end of the
| world. I can't blame Apple for not supporting geometry shaders
| in hardware, when they're widely considered to be a mistake
| that never should have been standardized in the first place,
| and Metal never supported them at all so they could only ever
| come up in old OpenGL code on macOS.
|
| https://x.com/pointinpolygon/status/1270695113967181827
| parl_match wrote:
| I wouldn't go so far as to say "mistake that should never
| have been standardized". Their intended use was always pretty
| limited, though. There's zero reason for anything built in
| recent memory to use them.
| jsheard wrote:
| They had limited uses _and_ turned out to be incredibly
| hard to implement efficiently in hardware, so in practice
| it was nearly always faster to just keep using the proven
| techniques that GS was supposed to replace.
|
| http://www.joshbarczak.com/blog/?p=667
| dtquad wrote:
| The graphics pipeline in modern GPUs are mostly a thin low-
| level Vulkan/Metal-like layer on top of a massively parallel
| CUDA-like compute architecture.
|
| It's basically all emulated. One of the reasons GPU
| manufacturers are unwilling to open source their drivers is
| because a lot of their secret sauce actually happens in
| software in the drivers on top of the massively parallel CUDA-
| like compute architecture.
| tedunangst wrote:
| Is this really so different from any other mobile derived GPU?
| refulgentis wrote:
| Idk, TIL, had a career in mobile for 15 years running and I
| didn't know this was a distinctive quality of mobile GPUs.
| (makes sense! but all that to say, I'm very interested to
| hear more, and I'll trade you an answer to that question:
| "maybe not! sounds like you got some smart stuff to share
| :)")
| ferbivore wrote:
| Yes. Apple have their own graphics API. They were able to
| decide that, say, geometry shaders aren't worth the chip area
| or engineering effort to support. Other IHVs don't get that
| choice; for geometry shaders, for instance, they're part of
| both Vulkan and OpenGLES, there are games and benchmarks that
| use them, and customers (end-users, gamedevs,
| review/benchmark sites, SoC vendors) will evaluate GPUs
| based, in some small part, on how good their geometry shader
| support is. Same story for tessellation, transform feedback,
| and whatever else Apple dropped.
| egwor wrote:
| Really impressive. Well done (and thanks for the laughs. Starting
| in French would be so funny)
___________________________________________________________________
(page generated 2024-10-31 23:00 UTC)