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.
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.
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.
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.
And yet one of the fancy new features being advertised in recent years (in multiple APIs including Metal) is support for mesh shaders – which seem to have a lot in common with geometry shaders, including the output ordering property that that post blames for geometry shaders’ bad performance. I’m not a graphics programmer myself, but this makes me suspect there’s more to the story.
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.
At least some Qualcomm, Imagination and Broadcom GPUs support geometry shaders in hardware. Not entirely sure about Arm. To be fair, it could be the support isn't very good.
I don’t think it’s accurate to say Apple “dropped” these features. Tessellation is done with general purpose compute shaders. You can do the same with “geometry shaders” if the need arises as well
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 :)")
> 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.
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).
> 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?
> 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.
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.
I think the answer is yes. I'm making assumptions based on this part of Alyssas talk a couple of weeks ago where she talks about M3 having specific driver support for raytracing which doesn't exist in previous versions.
The whole thing is worth watching to be honest, it's a privilege to watch someone share their deep knowledge and talent in such an engaging and approachable way.
M3 has mesh shader support. The geometry pipeline they inherited from PowerVR fundamentally doesn't support them, for reasons that go way over my head. They probably changed a good chunk of it.
In fairness to you I think a lot of the stuff involving hardware goes over everyone's heads :D
I've seen comments in a number of articles (and I think a few comments in this thread) saying that there are a few features in Vulcan/opengl/direct3d that were standardized ("standardized" in the D3D case?)/required that turned out to be really expensive to implement, hard to implement fast in hardware anyway, and not necessarily actually useful in practice. I think geometry shaders may have been one of those cases but I can't recall for sure.
> 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.
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.
Is there a blog post about what specifically she found to be inscrutable? The C++ doesn't look all that terse at a syntactic level, and has plenty of comments. Are the problems at the domain level?
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!"
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.
I've just been watching her recent talk. I noticed she appears to change slides with a wave of her wand. Is there an known piece of hardware one can purchase to do this?
I tried googling, but trying to find the specific result I'm interested in amongst all the blog spam garbage related to powerpoint is beyond me. Even googles own AI couldn't help. Sad times!
She might be doing some OpenCV/MedaPipe gesture tracking? There's lots of tutorials out there and it's not super difficult to get some basic gesture tracking going on your laptop.
> Since this was going to be the first Linux Rust GPU kernel driver, I had a lot of work ahead! Not only did I have to write the driver itself, but I also had to write the Rust abstractions for the Linux DRM graphics subsystem. While Rust can directly call into C functions, doing that doesn’t have any of Rust’s safety guarantees. So in order to use C code safely from Rust, first you have to write wrappers that give you a safe Rust-like API. I ended up writing almost 1500 lines of code just for the abstractions, and coming up with a good and safe design took a lot of thinking and rewriting!
> frankly, I think ray tracing is a bit of a gimmick feature
That's incredibly arrogant. The whole industry is adopting ray tracing, and it is a very desired feature people are upgrading video cards to get working on games they play.
I don't know, Hardware Unboxed recently did a review of 30-some games comparing the visuals with and without ray tracing, and the conclusion for the majority of them was that it wasn't worth it. There were only maybe half a dozen games where the ray tracing was an unambiguous improvement.
So I think calling it "a bit of a gimmick" is accurate for many of the games that shipped in, even if not all of them.
It's also a pretty large performance hit, even when the quality improvement is subtle. A major and unfortunate consequence is that it has driven even more games to rely on upscaling and heavy post-processing, all of which tend to blur the output image and introduce artifacts and add latency.
That's not even a costume because she's definitely a wizard
I’ve been trained to expect articles with this headline to say something like “we’re dropping support and are getting acqui-hired.”
Is anyone else astonished at how much is missing in the hardware and how much is emulated?
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.
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
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.
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
And yet one of the fancy new features being advertised in recent years (in multiple APIs including Metal) is support for mesh shaders – which seem to have a lot in common with geometry shaders, including the output ordering property that that post blames for geometry shaders’ bad performance. I’m not a graphics programmer myself, but this makes me suspect there’s more to the story.
So why does instancing suck? I would have thought it would be heavily optimised in the driver...
Is this really so different from any other mobile derived GPU?
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.
Other hardware vendors absolutely do the same. Geometry shaders are poor performers on several other vendors for precisely the same reason
At least some Qualcomm, Imagination and Broadcom GPUs support geometry shaders in hardware. Not entirely sure about Arm. To be fair, it could be the support isn't very good.
I don’t think it’s accurate to say Apple “dropped” these features. Tessellation is done with general purpose compute shaders. You can do the same with “geometry shaders” if the need arises as well
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 :)")
I always wondered about these /SubscriberLink/ links. Is sharing them considered unethical?
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.
I'm sure that they are very, very happy that HN is directing a firehose of traffic at their site on the regular.
In order to subscribe people need to know that LWN exists.
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).
A couple times now I’ve remembered to refill my subscription after my old one ran out of months thanks to an LWN free article being posted to HN.
So n=1 it’s an effective advertising tactic even though I can read the specific article for free.
Funding also comes from sponsors, as the article obviously states:
"I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Montreal for XDC."
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?
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.
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.
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"
Will M3/M4 need completely different drivers?
I think the answer is yes. I'm making assumptions based on this part of Alyssas talk a couple of weeks ago where she talks about M3 having specific driver support for raytracing which doesn't exist in previous versions.
https://youtu.be/pDsksRBLXPk?t=2895
The whole thing is worth watching to be honest, it's a privilege to watch someone share their deep knowledge and talent in such an engaging and approachable way.
ooh, I missed this, thanks for the link!
Probably. Apple made major changes to the GPU in M3.
What were the major differences?
Major base changes, or just added more stuff on top of the same base?
M3 has mesh shader support. The geometry pipeline they inherited from PowerVR fundamentally doesn't support them, for reasons that go way over my head. They probably changed a good chunk of it.
> for reasons that go way over my head
In fairness to you I think a lot of the stuff involving hardware goes over everyone's heads :D
I've seen comments in a number of articles (and I think a few comments in this thread) saying that there are a few features in Vulcan/opengl/direct3d that were standardized ("standardized" in the D3D case?)/required that turned out to be really expensive to implement, hard to implement fast in hardware anyway, and not necessarily actually useful in practice. I think geometry shaders may have been one of those cases but I can't recall for sure.
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.
How it handles memory and registers is quite different.
Really impressive. Well done (and thanks for the laughs. Starting in French would be so funny)
> 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.
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.
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...
Is there a blog post about what specifically she found to be inscrutable? The C++ doesn't look all that terse at a syntactic level, and has plenty of comments. Are the problems at the domain level?
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!"
OpenGL and Vulkan have tons of tests and Alyssa runs them. I don't know if it's automated through CI.
Reportedly, the lack of M3 support so far is because there is no M3 Mac Mini which they can use for CI.
That was one reason to delay it, but another more important they said was to implement gpu things like this and other missing features.
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.
I've just been watching her recent talk. I noticed she appears to change slides with a wave of her wand. Is there an known piece of hardware one can purchase to do this?
I tried googling, but trying to find the specific result I'm interested in amongst all the blog spam garbage related to powerpoint is beyond me. Even googles own AI couldn't help. Sad times!
Purchasing one has been illegal since 1863, but the technology typically used is a human assistant, although the signal is usually more subtle.
Who can forget 1863. The year BigMagic ruined the fun for everyone.
Ug… a person is watching and clicking for her when she does that?
She might be doing some OpenCV/MedaPipe gesture tracking? There's lots of tutorials out there and it's not super difficult to get some basic gesture tracking going on your laptop.
what they do is just this side of magic, so maybe it's not really a costume?
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.
I don't think the work they do is what one could call closed though is it?
Alyssa is amazing, I remember the first article about the GPU work, and then learning she was only 17 and poof mind blown.
It's truly stunning that anyone could do what she did, let alone a teenager (yes I know, she's not a teenager anymore, passage of time, etc :D)
Any link to the fact that the drivers are written in Rust?
https://asahilinux.org/2022/11/tales-of-the-m1-gpu/
> Since this was going to be the first Linux Rust GPU kernel driver, I had a lot of work ahead! Not only did I have to write the driver itself, but I also had to write the Rust abstractions for the Linux DRM graphics subsystem. While Rust can directly call into C functions, doing that doesn’t have any of Rust’s safety guarantees. So in order to use C code safely from Rust, first you have to write wrappers that give you a safe Rust-like API. I ended up writing almost 1500 lines of code just for the abstractions, and coming up with a good and safe design took a lot of thinking and rewriting!
Also https://github.com/AsahiLinux/linux/blob/de1c5a8be/drivers/g... where "drm" is https://en.wikipedia.org/wiki/Direct_Rendering_Manager
> frankly, I think ray tracing is a bit of a gimmick feature
That's incredibly arrogant. The whole industry is adopting ray tracing, and it is a very desired feature people are upgrading video cards to get working on games they play.
I don't know, Hardware Unboxed recently did a review of 30-some games comparing the visuals with and without ray tracing, and the conclusion for the majority of them was that it wasn't worth it. There were only maybe half a dozen games where the ray tracing was an unambiguous improvement.
So I think calling it "a bit of a gimmick" is accurate for many of the games that shipped in, even if not all of them.
It's also a pretty large performance hit, even when the quality improvement is subtle. A major and unfortunate consequence is that it has driven even more games to rely on upscaling and heavy post-processing, all of which tend to blur the output image and introduce artifacts and add latency.
The M1-M4 GPUs are also nowhere close to fast enough for it to be useful. Just like Snapdragon having ray tracing support is ridiculous.
That doesn’t necessarily mean it’s important, just that it’s the only thing they can think of to sell. Much like some AI stuff we’re seeing right now.
Personally I think it’s useful for a few things, but it’s not the giant game changer I think they want you to think it is.
Raytraced reflections are a very nice improvement. Using it for global illumination and shadows is also a very good improvement.
But it’s not exactly what the move to multi texturing was, or the first GPUs. Or shaders.
The same was true about 3D TVs. Also a gimmick.