4 ms·

> Missing damage tracking, always painting everything (even when the window is a full 4k monitor), Out of curiosity, what GPU accelerated terminal does this.

by epcoa 2y ago

cztomsik 2y ago
+1, no idea. But maybe to add a little bit of context, "damage tracking" means for example, that if there is any ongoing animation (like a spinner), then only a small part of the screen will be re-rendered (with proper vertex-time scissors, so only relevant pixels will be computed). I am not sure if it makes sense in the context of a terminal emulator, but it's certainly a big issue for any non-toy GUI toolkits. GPUs are incredibly fast parallel computers, so you will likely not observe any perf difference (unless you need order-dependent transparency which you don't), but it might improve your battery life significantly.
- arghwhat 2y ago
  No, damage tracking is important as it about reporting that you only updated that spinner, which means that your display server also knows to only redraw and repaint that area, and in turn that your GPU knows during scanout that only that area changed. Without, even if you only redrew your spinner, your display server ends up having to redraw what might be a full screen 4k window, as well as every intersecting window above and below until an opaque surfaces are hit to stop blending.
  - cztomsik 2y ago
    That's what I meant to say. There are 2 parts, and both need to work correctly, otherwise you're wasting power.
  - epcoa 2y ago
    Well it sounds like ghostty is like all the other major GPU terminal emulators (unless you know of a counterexample) and does full redraw, though it appears to have some optimizations about how often that occurs. The power issue might be true in some cases, but even as foot’s own benchmarks against alacritty demonstrate, it’s hyperbolic to say it “kills performance”.
    - mitchellh 2y ago
      We do a full redraw but do damage tracking ("dirty tracking" for us) on the cell state so we only rebuild the GPU state that changed. The CPU time to rebuild a frame is way more expensive than the mostly non-existent GPU time to render a frame since our render pipeline is so cheap. As I said in another thread, this ain't a AAA game. Shading a text grid is basically free on the GPU lol.
      - arghwhat 2y ago
        It's actually not at all free, even if you're barely using the shading capacity. The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Battery life is all about letting hardware turn off entirely. Also, if you do damage tracking, make sure to report it to the display server so they can avoid doing more expensive work blending several sources together, and in case of certain GPUs and certain scanout modes, also more efficient scanout. Depending on your choice of APIs, that would be something like eglSwapBuffersWithDamage, wl_surface_damage_buffer, and so forth.
        epcoa 2y ago
        > The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely uselessly fast update rate we're still in the high 80s). If you're updating faster than 100ms legitimately, it's probably video or animation that is updating a large percentage of the display area anyway. The overall time my terminal is doing some animation while on battery is low enough that in practice it just doesn't matter. https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law The problem you're up against is that, maybe if this was optimized most people would get 2 or 3 (or even 10) more minutes on a 12 hour battery life or something. No one really cares. Maybe they should, but they don't. And there's plenty of other suck in their power budget. You make it sound like a binary power saving scenario, but it tends to be more nuanced in practice. Most people run their terminal opaque, most display systems optimize this common case. > Also, if you do damage tracking, make sure to report it to the display server I'm not unsympathetic to your point of view. But I am skeptical that the power savings for most use cases ends up being much of a big deal in practice for most people (even accepting there may be some annoying edge cases that annoy some). I am interested in this topic, but I am still awaiting an example of a GPU accelerated terminal emulator that works this way to even make a real world comparison.

> Missing damage tracking, always painting everything (even when the window is a full 4k monitor), Out of curiosity, what GPU accelerated terminal does this.

by epcoa 2y ago

> Missing damage tracking, always painting everything (even when the window is a full 4k monitor), Out of curiosity, what GPU accelerated terminal does this.

cztomsik 2y ago

+1, no idea. But maybe to add a little bit of context, "damage tracking" means for example, that if there is any ongoing animation (like a spinner), then only a small part of the screen will be re-rendered (with proper vertex-time scissors, so only relevant pixels will be computed). I am not sure if it makes sense in the context of a terminal emulator, but it's certainly a big issue for any non-toy GUI toolkits. GPUs are incredibly fast parallel computers, so you will likely not observe any perf difference (unless you need order-dependent transparency which you don't), but it might improve your battery life significantly.

arghwhat 2y ago
No, damage tracking is important as it about reporting that you only updated that spinner, which means that your display server also knows to only redraw and repaint that area, and in turn that your GPU knows during scanout that only that area changed. Without, even if you only redrew your spinner, your display server ends up having to redraw what might be a full screen 4k window, as well as every intersecting window above and below until an opaque surfaces are hit to stop blending.
- cztomsik 2y ago
  That's what I meant to say. There are 2 parts, and both need to work correctly, otherwise you're wasting power.
- epcoa 2y ago
  Well it sounds like ghostty is like all the other major GPU terminal emulators (unless you know of a counterexample) and does full redraw, though it appears to have some optimizations about how often that occurs. The power issue might be true in some cases, but even as foot’s own benchmarks against alacritty demonstrate, it’s hyperbolic to say it “kills performance”.
  - mitchellh 2y ago
    We do a full redraw but do damage tracking ("dirty tracking" for us) on the cell state so we only rebuild the GPU state that changed. The CPU time to rebuild a frame is way more expensive than the mostly non-existent GPU time to render a frame since our render pipeline is so cheap. As I said in another thread, this ain't a AAA game. Shading a text grid is basically free on the GPU lol.
    - arghwhat 2y ago
      It's actually not at all free, even if you're barely using the shading capacity. The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Battery life is all about letting hardware turn off entirely. Also, if you do damage tracking, make sure to report it to the display server so they can avoid doing more expensive work blending several sources together, and in case of certain GPUs and certain scanout modes, also more efficient scanout. Depending on your choice of APIs, that would be something like eglSwapBuffersWithDamage, wl_surface_damage_buffer, and so forth.
      - epcoa 2y ago
        > The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely uselessly fast update rate we're still in the high 80s). If you're updating faster than 100ms legitimately, it's probably video or animation that is updating a large percentage of the display area anyway. The overall time my terminal is doing some animation while on battery is low enough that in practice it just doesn't matter. https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law The problem you're up against is that, maybe if this was optimized most people would get 2 or 3 (or even 10) more minutes on a 12 hour battery life or something. No one really cares. Maybe they should, but they don't. And there's plenty of other suck in their power budget. You make it sound like a binary power saving scenario, but it tends to be more nuanced in practice. Most people run their terminal opaque, most display systems optimize this common case. > Also, if you do damage tracking, make sure to report it to the display server I'm not unsympathetic to your point of view. But I am skeptical that the power savings for most use cases ends up being much of a big deal in practice for most people (even accepting there may be some annoying edge cases that annoy some). I am interested in this topic, but I am still awaiting an example of a GPU accelerated terminal emulator that works this way to even make a real world comparison.