Live data from Hacker News

I built a GPU back end for Emacs

en.andros.dev

91–100 of 117 posts

Re: I built a GPU back end for Emacs

#91
post #34

Earlier quoted context omitted.

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.

Also on Niri with fractional scaling and pgtk. IIRC the issue here is that for programs that don't support wp_fractional_scale, compositors deal with this by rendering at the next highest integer factor, and downscaling it down to achieve the desired factor. This is much, much worse for Emacs since it uses GTK3 and doesn't support hardware acceleration with Cairo, at least according to Po Lu [1] so you're effectively rendering via CPU at a very high resolution.

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

Re: I built a GPU back end for Emacs

#92

Earlier quoted context omitted.

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.

I'm also on Emacs and Niri, seems to be a popular combo, and I don't have any performance problem. 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.

It might also just be the case that the hardware you have is good enough that the lag isn't noticable.

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.

Re: I built a GPU back end for Emacs

#94
post #86
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,…

My experience with Emacs, 4K and Wayland was so abysmal that I spent a weekend making my config fully compatible with a terminal. Not ideal, but I'll keep running it through Ghostty until it's fixed.

Use the x11 build. It’s night and day

Re: I built a GPU back end for Emacs

#95
post #60
post #42

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

GPU speedups are welcome, but you don't need a shader and a gpu to insert a flashy effect. 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.

I expected this kind of reply, which is why I specifically mentioned that I actually use pulse.

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.

Re: I built a GPU back end for Emacs

#96
post #78

Earlier quoted context omitted.

> because it was not multi-threaded 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.

Curious that your comment was dead for whatever reason. I vouched for you because I'm also curious at what a user would need concurrency for in a text editor (I mean, granted, Emacs is a Lisp implementation with an amazing text editor attached so in theory someone may want concurrency for programming something in Elisp).

To avoid UI freezes, separate event processing from rendering (for example). It's very common to see the interface freeze while a complex command is running.

Re: I built a GPU back end for Emacs

#98
post #10

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.

[deleted]

Re: I built a GPU back end for Emacs

#99
post #42

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

I'd be thrilled with a second thread much less GPU.

https://www.gnu.org/software/emacs/manual/html_node/elisp/Ba...

Re: I built a GPU back end for Emacs

#100
post #86
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,…

My experience with Emacs, 4K and Wayland was so abysmal that I spent a weekend making my config fully compatible with a terminal. Not ideal, but I'll keep running it through Ghostty until it's fixed.

Just switch to X11. Wayland is never going to work.
Post reply on HN