I built a GPU back end for Emacs

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]

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...

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.

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).

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...

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.

"That was the moment the architecture stopped being a promise and became a fact."

The post is AI generated as well, right?

If I were you, it'd be pretty much worth it when you had a conversation with Stallman.

Great work! Possible to have a patch that I can apply on 32.0.5 and try this out?

Wow, I was just looking for something like this 15 minutes before you posted! Seems to not support Wayland though, from a quick scan, but cool project nonetheless

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.

I tried to look for the thread on the emacs-devel archive, and couldn't find it. Is it not archived for some reason?

This is a really cool project. And it's so small, too, when you consider what it unlocks and the opportunities it creates.

Really awesome!

Andros is also the guy behind the really cool Org Social:

https://org-social.org/

Hey @d12frosted, would it be possible to have it as the emacs-plus (homebrew formula) option?

This should also compile to WASM, and support WebGPU, not that I’m advocating for it.

I'm more impressed that you managed to stream youtube - that seems to me like almost the more impressive feat.

This is the way! Very nice work. I want it!

Doesn't just emacs render to a tty?

Or is this for some Emacs build with its own renderer?

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.

What is a backend for GPU?

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.

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.

cudos