I built a GPU back end for Emacs • Hacker News Board

Re: I built a GPU back end for Emacs

#31

Post by andros » Thu, Jun 25, 2026, 6:52 PM UTC

abstractbg wrote: post #25

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.

Re: I built a GPU back end for Emacs

#32

Post by simscitizen » Thu, Jun 25, 2026, 6:52 PM UTC

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.

Re: I built a GPU back end for Emacs

#33

Post by arikrahman » Thu, Jun 25, 2026, 6:53 PM UTC

andros wrote: post #5

skydhash wrote: post #4

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.

Re: I built a GPU back end for Emacs

#34

Post by zeendo » Thu, Jun 25, 2026, 6:54 PM UTC

arikrahman wrote: post #24

sph wrote: post #8

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,…

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.

Re: I built a GPU back end for Emacs

#35

Post by saltcured » Thu, Jun 25, 2026, 6:54 PM UTC

qrios wrote: post #6

semessier wrote: post #2

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

Re: I built a GPU back end for Emacs

#36

Post by skydhash » Thu, Jun 25, 2026, 6:55 PM UTC

abstractbg wrote: post #25

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.

Re: I built a GPU back end for Emacs

#37

Post by wasting_time » Thu, Jun 25, 2026, 6:56 PM UTC

reinitctxoffset wrote: post #19

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 bizar…

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.

Re: I built a GPU back end for Emacs

#38

Post by Conscat » Thu, Jun 25, 2026, 6:56 PM UTC

simscitizen wrote: post #32

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

This seems like the "obvious" solution. Why was the rejected?

EDIT: It appears to be an objection to GPU programming entirely.

Re: I built a GPU back end for Emacs

#39

Post by kleiba2 » Thu, Jun 25, 2026, 6:59 PM UTC

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

Re: I built a GPU back end for Emacs

#40

Post by andros » Thu, Jun 25, 2026, 6:59 PM UTC

simscitizen wrote: post #32

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

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.