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]
Emacs has had this for decades: `pulse.el`. And building your own is very simple also.
You'll still need someone to write the glue code to trigger the pulse, but then a gpu patch on the backend wouldn't give you that either.
I'm sure someone on MELPA/Github has written code to do just this already.
This attitude of "Emacs already has this" is not helpful and limits the development and evolution of Emacs. Have you seen how the Ghostty shaders work and how specifically the cursor highlighting one works? It is way better than what Emacs does today.
Pulse works, but honestly it pales when compared to neovim's effect. It would be nice to have a machinery to create things like that in Emacs.
I’m all for speeding up Emacs as a long time user, but I share emacs maintainers stance on not accepting llm code.
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...
Am I looking in the wrong place?
The main emacs-gpu branch doesn't have wayland support.
Not ideal, but I'll keep running it through Ghostty until it's fixed.
During the years, I have used a great number of text editors, e.g. vim, jedit, kate, geany, Visual Studio Code, neovim, etc.
Only this year I have switched to emacs, because it is more suitable for certain customizations that I prefer (for scripting, I like more Emacs Lisp than alternatives like Lua).
I have seen no performance problems (in GUI mode, I do not use it under a terminal emulator). On my hardware (with NVIDIA GPU) it is at least as fast as any other text editor that I had been using. Certainly much faster than Visual Studio Code.
As a terminal emulator I am now using ghostty, after previously using kitty and many other terminal emulators more distantly in the past, so GUI performance is important for me.
Ghostty seems faster than Emacs, so I believe that switching to GPU text rendering could accelerate Emacs, but for a significant speedup a more complete redesign of the graphics output would be necessary than in the parent article.
The problem is that this might be easy only when targeting a single GUI environment, but that would be in contradiction with the original Emacs goal, to be usable under many operating systems and GUI environments.
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.
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.
For XWayland apps Niri just renders at the native resolution (ignoring scaling), meaning a decent workaround is to use the Lucid/non-pgtk version and manually scaling up the UI. Unfortunately I go from scaling at 1.25 on my screen to 1.00 on my external monitors, which means I can't use the non-Wayland versions without messing up the font size on either my desktop and monitor.
[1] https://mail.gnu.org/archive/html/bug-gnu-emacs/2024-09/msg0...
At home I'm driving an Ultrawide (3440x1440@75Hz) at scale 1.1.
At work I'm driving two 4k screens at scale 1.2.
I might be less sensitive to latency but it could also be a graphics driver issue or something similar. I'm using Arch with emacs-wayland (pgtk) with a strix halo (all AMD) laptop.
You should still be able to notice a spike in CPU usage whenever you force Emacs to redraw the frame by typing into it though.
Wayland is a dead end.
Or sometimes you get suggested a method or library you've never heard of, opening your horizons.
otherwise, allowing sloptributions opens the gates to a myriad you-know-who who used to submit pull requests for ESL rewrite of two sequences in README.md and now submit chatgpt-generated refactors - which waste even more human time - just so they can proudly put "open source contributor" on their resumes.
https://www.reddit.com/r/lisp/comments/1rasjwf/elgpu/
https://dataswamp.org/~incal/el-gpu/
Big thread on devel as well also 'forgetting' to mention it eheh? Well, now then :)
> 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...
Run-time abstractions should always be avoided when the problem can be solved at compile-time.
While the conditional compilation syntax of the C/C++ preprocessor is not nice, good programming text editors can make it much more readable, by highlighting/hiding appropriate text sections.
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.
EDIT: It appears to be an objection to GPU programming entirely.
The post is AI generated as well, right?
I'm honestly curious, what kind of multi-threading you use, in whatever you're using now instead of Emacs? Can you share some practical example(s)? I'm not trying to trick you, I'm just curious for what kind of complex tasks possible there and where Emacs comes short.
---
Really awesome!
Or is this for some Emacs build with its own renderer?
A GPU (graphics processing unit) is a piece of hardware which is very good at doing a lot of calculations with a lot of numbers very quickly.
Making a backend for the GPU means programming the backend in such a way that it can run on the GPU, thereby (hopefully) getting the program to run faster and more efficiently.
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.
Intel and AMD are, but require proprietary firmware to work, so the freedom aspect is disputed.
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!
A lot of wishes, but no concrete solutions (unlike TFA). A good design doc with factual arguments would be better.
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.
"obsolete dinosaur who hasn't written a line of code in decades"
The most recent code change in Emacs by RMS was on 2026-04-22 (0fb9d096e38), so ~3 months ago. He can write complex code (without AI), such as the `cond*` macro (707 LOC, all macro code), authored and pushed to Emacs on 2024-08-02 (18491f48d97).
I think RMS does far more harm to the movement than he does good, and this ignorant, luddite take on GPUs is a poignant example.
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.
The criticism is that you did something wildly ambitious and pulled it off. The blog is just well written.
Oh God, if only. You’re right that it moved on from the classics, but it has new ones, and they’re just as identifiable.
More broadly, I'm just getting tired of the low effort snark on this. If someone is going to cite a passage, or examples of a theme, do some serious analysis by all means. I'm not trying to tone police high effort comments.
But this drive by "that's LLM output" thing is the new low effort "javascript is just as hard as c++" a.k.a "i don't know how to do that and i have no intention of learning and it feels bad so i'm going to lash out".
Make a case that something is deficient on its merits or don't, but baseless accusations of dishonesty are not a reasonable default. The parent here did real work that no one paid them to do, donated it to the community asking nothing in return, it's meticulous and high value, and they've already been run over by the FSF goons, you really want to pile on with no evidence?
Perhaps the opening post was ill-phrased, but I think the second post clarifies it a bit: https://news.ycombinator.com/item?id=48677597 - and I was certainly getting some vague LLM vibes from the writing, so I was curious about this too.
So, whatever it is in the LLM output that is detectable, it's clearly detectable, even with the latest LLMs, and even when it's present possibly only in trace quantities.
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.
You should be proud of both the work you did and the article :-).
What that has to do with this article about a new device driver for the EMACS OS, I don't quite know...
