Emacs user for >32 years now. It's a pity this won't get merged. There is a big usability/accessibility factor to consider here: I really wish I could have something like the Ghostty cursor_blaze.glsl shader for highlighting where the cursor is when you switch windows/buffers/apps.
Most people think GPU equals silly toys like video in a text window, but there is much more to it than that.
[and yes, I know about beacon, which unfortunately doesn't work too well, as well as about pulse, which I use]
I know this type of approach was rejected at the beginning, but you can also just ask CoreGraphics to use the GPU for 2D rendering (and I'm sure there are equivalent paths in e.g. Skia or Cairo).
On macOS/iOS, the easiest way would probably be to set the drawsAsynchronously property on a CALayer. Then, all CoreGraphics operations on the context passed back to the layer via drawInContext: will be GPU accelerated.
Lastly, there are some pretty sharp edges to this API, so definitely don't go flipping it on for every layer/view in your view hierarchy.
There's a lot to discuss here, a very interesting comment. I wouldn't want to talk too much publicly about certain technical elements, and because I don't want to encourage solutions decided by LLMs, however the Skia/Cairo-GL angle is interesting but would be a heavy dependency and does not help Linux, where the same gfxterm.c policy drives the OpenGL backend. The vtable abstraction was specifically designed so the rendering logic is written once and the platform just supplies the draw primitives.
Aside from the wonderful contribution to Emacs, I have the utmost respect for how straight-forward you were with the 100% LLM generated code. The enlightening conversation on GPU freedom that ensued was also informative.
This massive speed-up on 4K screens makes me want to try it. The wayland pgtk version has such terrible latency I have to use the X11 build to avoid gnashing teeth during my working hours. And I think it's the X11 version that uses cairo, so the actual speedup in my case might be even larger.
I reported the issue years ago, the pgtk maintainer confirmed, say they can't do much as they're using GTK3 which isn't hardware accelerated, so I have to wait until they migrate to GTK4 (in a decade or so). A bit disappointing, but that's open source.
Good news on the Wayland front: there is already a working branch (wayland-pgtk-backend) that adds a PGTK binding on top of the same EGL/GLES driver, pending merge to main. If you want to try it before that, the branch is available on the repo.
I have perf issues with emacs-pgtk on a 4k screen on Wayland with Niri in both Emacs as a client and not. The issues appear with typing or scolling, the delay and lag become noticeable.
For me the issue is only unbearable when running fractional scaling, for some reason.
I'm going to try the branch mentioned in the sibling comment, though.
I have almost the exact same setup as you and even have strange behavior with fractional scrolling. I'm on NixOS so the setup is even inspectable: https://codeberg.org/arik/dotfiles
After resetting the scale from 1.2 to 1.0 through 'niri msg output HDMI-A-2 scale 1' I actually noticed a performance increase! I will have to troubleshoot this, although you may have stumbled on a great lead toward the root cause.
Well done. Here’s hoping that a hand-written GPU backend gets developed based on this wonderful proof of concept. There’s no reason to not take advantage of the state of the art hardware when it’s available. And screens are only moving toward 4k and higher (6k or 8k).
Or that GNU updates a policy that will very rapidly go from probably net silly/mildly contestedly useful to completely ridiculous in a year or two. Not allowing LLM code will be basically turning down the work of the worlds best programmers running at 50x speed in couple years, and will functionally doom any software project that enforces such a policy.
could've guessed staying away from xdisp.c was a good idea, cf. the "Buttery Smooth Emacs"[0] post:
> Keep in mind that Emacs xdisp.c tries to support five different toolkits (including two different major versions of GTK) with #ifdefs. There is no runtime abstraction. We define three or four different versions of each damn function. It’s a nightmare.
Interesting improvement. My biggest issue with Emacs and the reason that I left it was because it was not multi-threaded. I wonder if is/can be multi-threaded now.
Concurrency is a source of many bugs and complexity. Emacs have a few async mechanisms and they’re good enough for most tasks. The async nature of other editors does not really matter as you’re still waiting for actions to complete.
There's not much of a secret here; I used ffmpeg to pre-download the video—there's... no actual streaming. When you select a video, it downloads in parallel and starts playing. Sorry to disappoint you :)
Yes, of course, I worked with the develop version until at a certain point I decided to downgrade to the stable versions. I'll be releasing more versions later; I'm still focused on fixing minor issues in Linux.
This is outstanding, if I have time I'll be switching over today.
This is the kind of thing that could drive a truly free fork of emacs forward, it's enough better on realistic desktop displays to rally around and as the parent discovered "Free Software" at this point has very little to do with the freedom to do what I want on my computer in a low friction way: an ideological position on "GPUs" as a category is bizarre even by Late Soviet FSF standards. By all means cite a vendor and a policy, but even NVIDIA is in tree now, it's got the same software freedom as ext4 and I don't hear anyone talking about chains on that.
In the age of machine assist emacs could get a modern fast/cachable build, clean under all the sanitizers, io_uring on Linux, deterministic clang formatting, compat break with zero-use junk from the 80s, WASM compilation for polyglot extension (I like lisp but I understand why some people don't), modern networking, modern chrome, 100% vscode compatible LSP, modern theming that defaults to something that doesn't drive users away. I would love to have a ten line init.el instead of 4k of workarounds.
Maybe this can be the nvim moment.
I love emacs but the nvim people have so many nice things and FSF emacs has a shelf life. If someone out of their own time and resources did a cross platform, mechanically verified, dramatically accelerated at HiDPI patch to basically anything else they'd be greeted like a hero.
I think a stronger basis for that is probably the Neomacs project aiming to rewrite the elisp layer and all C code in Rust, incorporating GPU rendering etc along the way, see https://github.com/eval-exec/neomacs
Pardon my shorthand. I meant open source and licensed under both MIT and GPLv2 such that distros build it alongside every other `.ko`.
One imagines if anyone has an issue it's with the RISC-V blob in GSP. Now while I myself wouldn't brave the wrath of NVIDIA's lawyers by like, calling Ghidra on it or anything, one imagines it doesn't have a lot of secrets from the motivated tinkerer!
I agree. Nvim already takes notes out of emacs with major contributors using Funnel to use Lisp as a workaround for working with Lua. This would be a step in the right direction for the continued pioneer emacs proves to be.
> In the age of machine assist emacs could get a modern fast/cachable build, clean under all the sanitizers, io_uring on Linux, deterministic clang formatting, compat break with zero-use junk from the 80s, WASM compilation for polyglot extension (I like lisp but I understand why some people don't), modern networking, modern chrome, 100% vscode compatible LSP, modern theming that defaults to something that doesn't drive users away. I would love to have a ten line init.el instead of 4k of workarounds.
A lot of wishes, but no concrete solutions (unlike TFA). A good design doc with factual arguments would be better.
>an ideological position on "GPUs" as a category is bizarre even by Late Soviet FSF standards.
The FSF and the GNU project are both paralyzed by their inability to move on from Stallman. He may have been a visionary 40 years ago but now he's an obsolete dinosaur who hasn't written a line of code in decades and has absolutely no idea how modern computers work.
He can't update his own website. He evidently doesn't seem to know how GPUs work. He does his computing in a very unorthodox and anachronistic manner, and that's great for him, but irrelevant to most people who would benefit from more free software.
This is for the GUI build of Emacs, not the terminal (tty) version. Emacs has had a native GUI renderer since the 90s, on macOS it uses Cocoa/NS, on Linux it uses GTK or raw X11. This project replaces that CPU-based drawing pipeline with a GPU backend: Metal on macOS and OpenGL/EGL on Linux. The tty build is unaffected.
Cool! Regardless of whether your code gets merged, it shows that xdisp.c can be tamed. Like Roger Bannister who ran the miracle mile, you showed that it can be done. Hopefully more will chip in and slay the Emacs redisplay code beast.
This was almost a good read (a very good goal and a sensible approach), But the pacing of the article smells of LLM. I would suggest to do another pass at editing it out as it diminishes the story.
If you've reached that conclusion, I'm truly proud of my writing technique. I'm sorry to say, though, that your instincts are failing you this time. I write my articles by hand over several days, although it's true that I do consult AI to improve my style, expressions, find synonyms, create tables, and correct spelling mistakes. Thank you for your comment!
With how straight forward you were about disclosing 100% LLM generated code, I have no reason to doubt you. Besides, the most riveting parts were the quotes from the ensuing discussion even from Stallman himself.
I don’t think it failed. I was reading it and it did not seem written by a LLM (which I was happy for). But a few sentences did have LLM style and they disrupted my reading flow.
This is my heuristics: Usually when writing a story, authors adopt a fluid flow as they know they have your attention. Same as when telling a story. But LLM tooling usually adopt a highly emphatic tone similar to speeches: Short propositions, emotional crescendo, lots of contrast.
The difference in style is like abruptly going from a conversation to having your interlocutors doing a marketing speech in front of a crowd of one. It’s really jarring.
It’s not the whole piece. Just a few places here and there. If you’ve adjusted a few sentences, maybe try leaving them as is after fixing spelling mistakes.
FWIW no one can tell anymore. Claude stopped doing all the LLM ticks like 6 months ago. There's a whole industry of people trying to detect LLM writing and they're getting stomped, this can be and is extremely well studied in the literature.
The criticism is that you did something wildly ambitious and pulled it off. The blog is just well written.
Very much this. I really dislike the somewhat corporate and characterless sounding tone of AI.
I really liked the part where he tried to get it into upstream emacs, most of these type of projects never even get there. But yeah things like "bring honest numbers" sounds just weird.
Emacs user for >32 years now. It's a pity this won't get merged. There is a big usability/accessibility factor to consider here: I really wish I could have something like the Ghostty cursor_blaze.glsl shader for highlighting where the cursor is when you switch windows/buffers/apps.
Most people think GPU equals silly toys like video in a text window, but there is much more to it than that.
[and yes, I know about beacon, which unfortunately doesn't work too well, as well as about pulse, which I use]
I know this type of approach was rejected at the beginning, but you can also just ask CoreGraphics to use the GPU for 2D rendering (and I'm sure there are equivalent paths in e.g. Skia or Cairo).
On macOS/iOS, the easiest way would probably be to set the drawsAsynchronously property on a CALayer. Then, all CoreGraphics operations on the context passed back to the layer via drawInContext: will be GPU accelerated.
Lastly, there are some pretty sharp edges to this API, so definitely don't go flipping it on for every layer/view in your view hierarchy.
There's a lot to discuss here, a very interesting comment. I wouldn't want to talk too much publicly about certain technical elements, and because I don't want to encourage solutions decided by LLMs, however the Skia/Cairo-GL angle is interesting but would be a heavy dependency and does not help Linux, where the same gfxterm.c policy drives the OpenGL backend. The vtable abstraction was specifically designed so the rendering logic is written once and the platform just supplies the draw primitives.
This seems like the "obvious" solution. Why was the rejected?
EDIT: It appears to be an objection to GPU programming entirely.
Aside from the wonderful contribution to Emacs, I have the utmost respect for how straight-forward you were with the 100% LLM generated code. The enlightening conversation on GPU freedom that ensued was also informative.
I completely agree with you. For me, it was the best reward.
https://github.com/tanrax/emacs-gpu/blob/main/.github/assets...
This massive speed-up on 4K screens makes me want to try it. The wayland pgtk version has such terrible latency I have to use the X11 build to avoid gnashing teeth during my working hours. And I think it's the X11 version that uses cairo, so the actual speedup in my case might be even larger.
I reported the issue years ago, the pgtk maintainer confirmed, say they can't do much as they're using GTK3 which isn't hardware accelerated, so I have to wait until they migrate to GTK4 (in a decade or so). A bit disappointing, but that's open source.
Looks like I'm not the only one suffering with a 4K screen: https://old.reddit.com/r/emacs/comments/ucv0at/awful_perform...
Good news on the Wayland front: there is already a working branch (wayland-pgtk-backend) that adds a PGTK binding on top of the same EGL/GLES driver, pending merge to main. If you want to try it before that, the branch is available on the repo.
I didn't notice to much performance issue switching to PGTK on an ultrawide on Niri. Are you using the daemon to render Emacs as a client?
I have perf issues with emacs-pgtk on a 4k screen on Wayland with Niri in both Emacs as a client and not. The issues appear with typing or scolling, the delay and lag become noticeable.
For me the issue is only unbearable when running fractional scaling, for some reason.
I'm going to try the branch mentioned in the sibling comment, though.
I have almost the exact same setup as you and even have strange behavior with fractional scrolling. I'm on NixOS so the setup is even inspectable: https://codeberg.org/arik/dotfiles
After resetting the scale from 1.2 to 1.0 through 'niri msg output HDMI-A-2 scale 1' I actually noticed a performance increase! I will have to troubleshoot this, although you may have stumbled on a great lead toward the root cause.
Well done. Here’s hoping that a hand-written GPU backend gets developed based on this wonderful proof of concept. There’s no reason to not take advantage of the state of the art hardware when it’s available. And screens are only moving toward 4k and higher (6k or 8k).
Or that GNU updates a policy that will very rapidly go from probably net silly/mildly contestedly useful to completely ridiculous in a year or two. Not allowing LLM code will be basically turning down the work of the worlds best programmers running at 50x speed in couple years, and will functionally doom any software project that enforces such a policy.
We shall see.
Me too. In the meantime, I'll stick with this version :)
could've guessed staying away from xdisp.c was a good idea, cf. the "Buttery Smooth Emacs"[0] post:
> Keep in mind that Emacs xdisp.c tries to support five different toolkits (including two different major versions of GTK) with #ifdefs. There is no runtime abstraction. We define three or four different versions of each damn function. It’s a nightmare.
[0] https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb7...
Interesting improvement. My biggest issue with Emacs and the reason that I left it was because it was not multi-threaded. I wonder if is/can be multi-threaded now.
You have libraries for multithreading. I use them myself for parallel tasks. However, how events and redrawing work is a completely different matter.
Concurrency is a source of many bugs and complexity. Emacs have a few async mechanisms and they’re good enough for most tasks. The async nature of other editors does not really matter as you’re still waiting for actions to complete.
I'm more impressed that you managed to stream youtube - that seems to me like almost the more impressive feat.
There's not much of a secret here; I used ffmpeg to pre-download the video—there's... no actual streaming. When you select a video, it downloads in parallel and starts playing. Sorry to disappoint you :)
Great work! Possible to have a patch that I can apply on 32.0.5 and try this out?
Yes, of course, I worked with the develop version until at a certain point I decided to downgrade to the stable versions. I'll be releasing more versions later; I'm still focused on fixing minor issues in Linux.
This is outstanding, if I have time I'll be switching over today.
This is the kind of thing that could drive a truly free fork of emacs forward, it's enough better on realistic desktop displays to rally around and as the parent discovered "Free Software" at this point has very little to do with the freedom to do what I want on my computer in a low friction way: an ideological position on "GPUs" as a category is bizarre even by Late Soviet FSF standards. By all means cite a vendor and a policy, but even NVIDIA is in tree now, it's got the same software freedom as ext4 and I don't hear anyone talking about chains on that.
In the age of machine assist emacs could get a modern fast/cachable build, clean under all the sanitizers, io_uring on Linux, deterministic clang formatting, compat break with zero-use junk from the 80s, WASM compilation for polyglot extension (I like lisp but I understand why some people don't), modern networking, modern chrome, 100% vscode compatible LSP, modern theming that defaults to something that doesn't drive users away. I would love to have a ten line init.el instead of 4k of workarounds.
Maybe this can be the nvim moment.
I love emacs but the nvim people have so many nice things and FSF emacs has a shelf life. If someone out of their own time and resources did a cross platform, mechanically verified, dramatically accelerated at HiDPI patch to basically anything else they'd be greeted like a hero.
Keep up the good work legend.
I think a stronger basis for that is probably the Neomacs project aiming to rewrite the elisp layer and all C code in Rust, incorporating GPU rendering etc along the way, see https://github.com/eval-exec/neomacs
Just to clarify: the NVIDIA driver is not in-tree, and probably never will be.
Intel and AMD are, but require proprietary firmware to work, so the freedom aspect is disputed.
Pardon my shorthand. I meant open source and licensed under both MIT and GPLv2 such that distros build it alongside every other `.ko`.
One imagines if anyone has an issue it's with the RISC-V blob in GSP. Now while I myself wouldn't brave the wrath of NVIDIA's lawyers by like, calling Ghidra on it or anything, one imagines it doesn't have a lot of secrets from the motivated tinkerer!
I agree. Nvim already takes notes out of emacs with major contributors using Funnel to use Lisp as a workaround for working with Lua. This would be a step in the right direction for the continued pioneer emacs proves to be.
> In the age of machine assist emacs could get a modern fast/cachable build, clean under all the sanitizers, io_uring on Linux, deterministic clang formatting, compat break with zero-use junk from the 80s, WASM compilation for polyglot extension (I like lisp but I understand why some people don't), modern networking, modern chrome, 100% vscode compatible LSP, modern theming that defaults to something that doesn't drive users away. I would love to have a ten line init.el instead of 4k of workarounds.
A lot of wishes, but no concrete solutions (unlike TFA). A good design doc with factual arguments would be better.
In fairness I only saw this like, an hour ago, so it'll probably be at least until after work before I start messing around with it.
>an ideological position on "GPUs" as a category is bizarre even by Late Soviet FSF standards.
The FSF and the GNU project are both paralyzed by their inability to move on from Stallman. He may have been a visionary 40 years ago but now he's an obsolete dinosaur who hasn't written a line of code in decades and has absolutely no idea how modern computers work.
He can't update his own website. He evidently doesn't seem to know how GPUs work. He does his computing in a very unorthodox and anachronistic manner, and that's great for him, but irrelevant to most people who would benefit from more free software.
Doesn't just emacs render to a tty?
Or is this for some Emacs build with its own renderer?
This is for the GUI build of Emacs, not the terminal (tty) version. Emacs has had a native GUI renderer since the 90s, on macOS it uses Cocoa/NS, on Linux it uses GTK or raw X11. This project replaces that CPU-based drawing pipeline with a GPU backend: Metal on macOS and OpenGL/EGL on Linux. The tty build is unaffected.
This is the way! Very nice work. I want it!
Thank you!
Cool! Regardless of whether your code gets merged, it shows that xdisp.c can be tamed. Like Roger Bannister who ran the miracle mile, you showed that it can be done. Hopefully more will chip in and slay the Emacs redisplay code beast.
Thank you, this means a lot!
This was almost a good read (a very good goal and a sensible approach), But the pacing of the article smells of LLM. I would suggest to do another pass at editing it out as it diminishes the story.
If you've reached that conclusion, I'm truly proud of my writing technique. I'm sorry to say, though, that your instincts are failing you this time. I write my articles by hand over several days, although it's true that I do consult AI to improve my style, expressions, find synonyms, create tables, and correct spelling mistakes. Thank you for your comment!
With how straight forward you were about disclosing 100% LLM generated code, I have no reason to doubt you. Besides, the most riveting parts were the quotes from the ensuing discussion even from Stallman himself.
I don’t think it failed. I was reading it and it did not seem written by a LLM (which I was happy for). But a few sentences did have LLM style and they disrupted my reading flow.
This is my heuristics: Usually when writing a story, authors adopt a fluid flow as they know they have your attention. Same as when telling a story. But LLM tooling usually adopt a highly emphatic tone similar to speeches: Short propositions, emotional crescendo, lots of contrast.
The difference in style is like abruptly going from a conversation to having your interlocutors doing a marketing speech in front of a crowd of one. It’s really jarring.
It’s not the whole piece. Just a few places here and there. If you’ve adjusted a few sentences, maybe try leaving them as is after fixing spelling mistakes.
FWIW no one can tell anymore. Claude stopped doing all the LLM ticks like 6 months ago. There's a whole industry of people trying to detect LLM writing and they're getting stomped, this can be and is extremely well studied in the literature.
The criticism is that you did something wildly ambitious and pulled it off. The blog is just well written.
People clearly can, though, because they did.
Very much this. I really dislike the somewhat corporate and characterless sounding tone of AI.
I really liked the part where he tried to get it into upstream emacs, most of these type of projects never even get there. But yeah things like "bring honest numbers" sounds just weird.
Please, have some mercy, English is not my first language! Thanks for the advice, I'll keep it in mind.
dont listen to insane people obsessed with llm hatred. thanks for the article
cudos
A new CUDA API? For DOS?
No, CUDOS is using CUDA as your OS.
What that has to do with this article about a new device driver for the EMACS OS, I don't quite know...
Why?