6 ms·

This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems f

This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems fairly simple graphically, you are just drawing glyphs at xy cords. Would love it if someone had a good explanation. Obviously there are some terminal applications that could be redrawing very quickly, but that seems like a solved problem.

mattbee 5y ago
Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my computer, more confident to try things out if I can see my typing updating instantly than 10s or 100s of milliseconds later.
- samwillis 5y ago
  I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?
  - mattbee 5y ago
    A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to get your shell prompt back? (ofc the differences might not be something you ever notice or care about)
    - mattbee 5y ago
      e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
      - dogma1138 5y ago
        The new terminal in windows 11 has GPU acceleration. Tho control character latency likely doesn’t have anything to do with the responsiveness that GPU text rendering provides, since ctrl+c is a sequence captured by the OS it’s more likely to have something to do with which ever API the terminal uses to capture input or even the OS itself since I guess the OS still captures the sequence first then has some checks if the object can be universally copied and if not passes the sequence to the active window in focus for it to handle that.
    - usrbinbash 5y ago
      But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
      - nix23 5y ago
        > But what's the use case for this? telnet towel.blinkenlights.nl
      - joseluis 5y ago
        well... come to the future: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
        usrbinbash 5y ago
        And what exactly is the use case for this? If I want to work with images, animations, etc. I use a GUI library. These in turn already use hardware accelerated rendering. And I already have powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side; the DESKTOP ENVIRONMENT.
        filmor 5y ago
        Please be aware that all uppercase comes across as quite aggressive. Writing a lot of data to a terminal can happen accidentally or by having an application running that throws out a burst of log messages. In both cases, you'll want to have your terminal to be responsive again as soon as possible and you want it to be light on your cpu s.t. it doesn't interrupt other applications.
        usrbinbash 5y ago
        > In both cases, you'll want to have your terminal to be responsive again as soon as possible. My terminal emulator doesn't become unresponsive just because the renderer cannot keep up. It still processes input, so if I accidentially cat some-linux-distro-1of4.iso ...I can still Ctrl-C it and stop the process. > it doesn't interrupt other applications. It can't do that anyway in an environment that does preemptive multitasking.
  - vidarh 5y ago
    I tested kitty (GPU accelerated) and rxvt on my laptop, and rxvt beat kitty on throughput. Now, kitty looks much nicer, and I prefer it over rxvt any day. My local copy applies a shader to add a subtle glow so the transparent background doesn't make the text unreadable, for example. That is where GPU rendered terminal shines - not speed. High terminal throughput you get from good architecture (do decouple IO and rendering in separate threads; don't trigger your rendering pipeline for every character output if the buffer is growing; very few terminals bother to do this because a more naive approach is generally fast enough on modern hardware), and even a brutally naive CPU rendered terminal can render fast enough if your architecture is decent.
  - ohgodplsno 5y ago
    For a basic example of why you would want GPU acceleration, have a look at refterm: https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm Even processes that you wouldn't think would be impacted by a terminal can be hurt relaly bad by your terminal's performance: your compiler's logs, etc. The GPU rendering part merely guarantees that your terminal sticks at 60FPS (or, whatever your refresh rate is) if the processing behind is efficient.
    - vidarh 5y ago
      This was a solved problem in the 1980's with Amiga consoles separating input processing, high level terminal handling and rendering into separate threads.
- jcelerier 5y ago
  Lower CPU usage but higher GPU usage. On my laptop I get muuuch more battery out of it (going from 6 hours to ~2 hours) if I disable everything that may wake up the GPU and force software rendering everywhere (since, unlike GPUs, it's much more often able to rerender only the parts of the screen which changed)
  - unbanned 5y ago
    Wall socket
  - heftig 5y ago
    That isn't an inherent limitation of GPUs, though. More likely just a missing feature in whatever GPU rendering path.
  - floatboth 5y ago
    > rerender only the parts of the screen which changed e.g. Firefox is already good at doing that on the GPU. WezTerm isn't yet, but We're Working On It™ (i.e. someday it will be done), follow https://github.com/wez/wezterm/issues/1134 https://github.com/wez/wezterm/issues/1134
- usrbinbash 5y ago
  > until you accidentally unleash a lot of output at once The only time this happens, is when I do something wrong, like `cat`-ing the 12MB binary instead of the config.json, or `tail -f` into the output device of the core logging endpoint and forget to pipe into `grep`. If that happens, I usually terminate the process anyway.
  - nyadesu 5y ago
    This is also pretty common when running test runners a lot
    - usrbinbash 5y ago
      So I pipe their output into a file, or into a logger engine. Problem solved.
  - cyberge99 5y ago
    You can also run ‘reset’ which will clear escape codes and reset your session.
CyberRabbi 5y ago
Well since GPU acceleration minimizes latency (because of zero-copy, all character textures are resident in video memory), that is a boon to perceived responsiveness. IMO that is the single most important feature in a terminal, next to correctness. It’s like typing on an old serial terminal.
- geokon 5y ago
  Latency and throughput benchmarks don't confirm this. Eshell has one of the best latencies (that's why it feels so responsive compared to VS Code) but low throughput Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. GPU terminals seem to do this kinda slowly last I checked
  - gravypod 5y ago
    > Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) Why? Many commands I've run have produced a lot of log output in my day.
    - geokon 5y ago
      Bc you wanna see the output? With less you can go page by page and read the output. If there is so much output you can't read it.. then what's the point of printing it to the screen? If you're looking for something in the stream then maybe you should grep for it? I'm not saying you never ever should barf to screen - but as far as I can see, you kinda have to strain yourself to concoct a "valid" usecase
      - vidarh 5y ago
        The irony of this is that with a faster terminal you'll be even less likely to actually read the data scrolling by. And the solution is very simple: Update a text buffer in one thread and render updates as fast as possible on another. If something barfs massive amounts of text you won't ever see all of it as not all of it will get rendered as it'll have "scrolled past" before the renderer gets to it. But it won't matter because it will be in scrollback if configured and you'd never have been able to read it as it passes by anyway, even with much faster rendering.
user-the-name 5y ago
"cat 1_gb_of.txt" will push your terminal far beyond what just a CPU can comfortably handle.
- usrbinbash 5y ago
  And when do I want to `cat` 1GiB of text? I cannot process it with my human eyes, so what does it matter if the CPU rendering can keep up or not? cat 1_gb_of.txt | less Is what I want to do, and this is easily rendered even on older hardware.
  - user-the-name 5y ago
    When you don't actually realise it is 1 GB before you cat it.
    - usrbinbash 5y ago
      So then I hit Ctrl-C and issue the correct command. How does a GPU based renderer improve on that use-case?
      - ziotom78 5y ago
        Before you press Ctrl+C and type the correct command, your neighbour running Kitty has already got the last line of the output (which is often the only thing that one really needs). I switched to Kitty because I felt that the increased speed produced a perceived improvement in my workflow.
        usrbinbash 5y ago
        >which is often the only thing that one really needs) tail 1_gb_of.txt ...will get the last line of output long before the rendering engine finished initializing. And it will probably do so even on a 10year old laptop with no GPU, in virtual console, while the system is running under load ;-)
pradeepchhetri 5y ago
Well, atleast the CPU will be free for doing other things by offloading some work to GPU.
orangeoxidation 5y ago
Terminals don't just render what you see, but everything that programs output, which can be enormous amounts of text, grinding non-accelerated terminals to a halt. I don't know if they actually have to do this (It might be necessary for seamless scrolling?), but building some partial rendering might be more complicated than GPU acceleration as well. I'd be interested if someone knows more about this.
ahefner 5y ago
I don't get it either. The 2D APIs used for font rendering built into every window system (xrender, etc.) are already hardware accelerated and more than fast enough. Going to OpenGL or whatever this uses just seems ridiculous. There's no use case for rendering your terminal emulator at 10,000 frames per second.
baq 5y ago
Note that consoles back in the day (e.g. classic 80x25) were essentially hardware accelerated.
- samwillis 5y ago
  I suppose that’s quite true as you were probably running in something like VGA text mode.
otabdeveloper4 5y ago
> What is the advantage of GPU acceleration for a terminal emulator? I haven't found any. Seems like it's just a fashion accessory for $THIS_YEAR.
- samwillis 5y ago
  I don’t think there is anything wrong with that. Also building a GPU accelerated terminal emulator is probably a brilliant project to learn loads of low level skills.
vidarh 5y ago
Very little unless you use shaders for effects. . Updating terminals fast enough was a solved problem on 30 year old hardware. Most of the slowness of some terminal apps is down to poor design not CPU rendering (see the speed differences between various CPU rendered terminals)
- floatboth 5y ago
  30 year old hardware didn't have to render fancy antialiased fonts at 3840x2160 @ 144Hz.
  - vidarh 5y ago
    My computer in the 80s ran at 7.16MHz and a single core. The CPU speedup has increased far more than the amount of data to be moved even at the kind of setup you're describing.
    - floatboth 5y ago
      Data rates for display have increased very much too. Don't underestimate the, uhh, "how rectangles work" factor – doubling the resolution means doubling both width and height, so quadrupling the pixel count. 80s computers also used lots of special hardware for graphics output, they didn't software render everything ;)
      - vidarh 5y ago
        Yes, but as I said the increase in data rates has not been anywhere near as fast as the increase in CPU speed, even with the unusal example you gave. As for special hardware for graphics output, that's not really true. Some, sure. My Amiga had a basic blitter. But all that allowed for that helped a terminal was scrolling at a few times higher speed than the CPU - it was limited by the memory bus speed. That was revolutionary at the time. Most other 80's hardware had much less, except for having character modes, but I was specifically talking about ones using bitmap screens like the Amiga for example. But a blitter does not help you with the worst case scenario of filling the terminal with text from scratch as the setup cost is typically higher than the cost of having the CPU render individual characters (it certainly was on the Amiga - the blitter helped when moving larger chunks of data, but not for character sized areas). I have written terminals for 1980s hardware and for modern hardware. I know where the bottlenecks are and there is no issue whatsoever keeping up with the graphical display. When a terminal is slow it's a design issue.

mattbee 5y ago

Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my computer, more confident to try things out if I can see my typing updating instantly than 10s or 100s of milliseconds later.

samwillis 5y ago
I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?
- mattbee 5y ago
  A really basic test is just type "base64 < /dev/urandom" in your terminal. How fast does the screen update? And if you press ctrl+C, how long does it take to get your shell prompt back? (ofc the differences might not be something you ever notice or care about)
  - mattbee 5y ago
    e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
    - dogma1138 5y ago
      The new terminal in windows 11 has GPU acceleration. Tho control character latency likely doesn’t have anything to do with the responsiveness that GPU text rendering provides, since ctrl+c is a sequence captured by the OS it’s more likely to have something to do with which ever API the terminal uses to capture input or even the OS itself since I guess the OS still captures the sequence first then has some checks if the object can be universally copied and if not passes the sequence to the active window in focus for it to handle that.
  - usrbinbash 5y ago
    But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
    - nix23 5y ago
      > But what's the use case for this? telnet towel.blinkenlights.nl
    - joseluis 5y ago
      well... come to the future: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
      - usrbinbash 5y ago
        And what exactly is the use case for this? If I want to work with images, animations, etc. I use a GUI library. These in turn already use hardware accelerated rendering. And I already have powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side; the DESKTOP ENVIRONMENT.
        filmor 5y ago
        Please be aware that all uppercase comes across as quite aggressive. Writing a lot of data to a terminal can happen accidentally or by having an application running that throws out a burst of log messages. In both cases, you'll want to have your terminal to be responsive again as soon as possible and you want it to be light on your cpu s.t. it doesn't interrupt other applications.
        usrbinbash 5y ago
        > In both cases, you'll want to have your terminal to be responsive again as soon as possible. My terminal emulator doesn't become unresponsive just because the renderer cannot keep up. It still processes input, so if I accidentially cat some-linux-distro-1of4.iso ...I can still Ctrl-C it and stop the process. > it doesn't interrupt other applications. It can't do that anyway in an environment that does preemptive multitasking.
- vidarh 5y ago
  I tested kitty (GPU accelerated) and rxvt on my laptop, and rxvt beat kitty on throughput. Now, kitty looks much nicer, and I prefer it over rxvt any day. My local copy applies a shader to add a subtle glow so the transparent background doesn't make the text unreadable, for example. That is where GPU rendered terminal shines - not speed. High terminal throughput you get from good architecture (do decouple IO and rendering in separate threads; don't trigger your rendering pipeline for every character output if the buffer is growing; very few terminals bother to do this because a more naive approach is generally fast enough on modern hardware), and even a brutally naive CPU rendered terminal can render fast enough if your architecture is decent.
- ohgodplsno 5y ago
  For a basic example of why you would want GPU acceleration, have a look at refterm: https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm Even processes that you wouldn't think would be impacted by a terminal can be hurt relaly bad by your terminal's performance: your compiler's logs, etc. The GPU rendering part merely guarantees that your terminal sticks at 60FPS (or, whatever your refresh rate is) if the processing behind is efficient.
  - vidarh 5y ago
    This was a solved problem in the 1980's with Amiga consoles separating input processing, high level terminal handling and rendering into separate threads.
jcelerier 5y ago
Lower CPU usage but higher GPU usage. On my laptop I get muuuch more battery out of it (going from 6 hours to ~2 hours) if I disable everything that may wake up the GPU and force software rendering everywhere (since, unlike GPUs, it's much more often able to rerender only the parts of the screen which changed)
- unbanned 5y ago
  Wall socket
- heftig 5y ago
  That isn't an inherent limitation of GPUs, though. More likely just a missing feature in whatever GPU rendering path.
- floatboth 5y ago
  > rerender only the parts of the screen which changed e.g. Firefox is already good at doing that on the GPU. WezTerm isn't yet, but We're Working On It™ (i.e. someday it will be done), follow https://github.com/wez/wezterm/issues/1134 https://github.com/wez/wezterm/issues/1134
usrbinbash 5y ago
> until you accidentally unleash a lot of output at once The only time this happens, is when I do something wrong, like `cat`-ing the 12MB binary instead of the config.json, or `tail -f` into the output device of the core logging endpoint and forget to pipe into `grep`. If that happens, I usually terminate the process anyway.
- nyadesu 5y ago
  This is also pretty common when running test runners a lot
  - usrbinbash 5y ago
    So I pipe their output into a file, or into a logger engine. Problem solved.
- cyberge99 5y ago
  You can also run ‘reset’ which will clear escape codes and reset your session.

CyberRabbi 5y ago

Well since GPU acceleration minimizes latency (because of zero-copy, all character textures are resident in video memory), that is a boon to perceived responsiveness. IMO that is the single most important feature in a terminal, next to correctness. It’s like typing on an old serial terminal.

geokon 5y ago
Latency and throughput benchmarks don't confirm this. Eshell has one of the best latencies (that's why it feels so responsive compared to VS Code) but low throughput Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. GPU terminals seem to do this kinda slowly last I checked
- gravypod 5y ago
  > Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) Why? Many commands I've run have produced a lot of log output in my day.
  - geokon 5y ago
    Bc you wanna see the output? With less you can go page by page and read the output. If there is so much output you can't read it.. then what's the point of printing it to the screen? If you're looking for something in the stream then maybe you should grep for it? I'm not saying you never ever should barf to screen - but as far as I can see, you kinda have to strain yourself to concoct a "valid" usecase
    - vidarh 5y ago
      The irony of this is that with a faster terminal you'll be even less likely to actually read the data scrolling by. And the solution is very simple: Update a text buffer in one thread and render updates as fast as possible on another. If something barfs massive amounts of text you won't ever see all of it as not all of it will get rendered as it'll have "scrolled past" before the renderer gets to it. But it won't matter because it will be in scrollback if configured and you'd never have been able to read it as it passes by anyway, even with much faster rendering.

user-the-name 5y ago

"cat 1_gb_of.txt" will push your terminal far beyond what just a CPU can comfortably handle.

usrbinbash 5y ago
And when do I want to `cat` 1GiB of text? I cannot process it with my human eyes, so what does it matter if the CPU rendering can keep up or not? cat 1_gb_of.txt | less Is what I want to do, and this is easily rendered even on older hardware.
- user-the-name 5y ago
  When you don't actually realise it is 1 GB before you cat it.
  - usrbinbash 5y ago
    So then I hit Ctrl-C and issue the correct command. How does a GPU based renderer improve on that use-case?
    - ziotom78 5y ago
      Before you press Ctrl+C and type the correct command, your neighbour running Kitty has already got the last line of the output (which is often the only thing that one really needs). I switched to Kitty because I felt that the increased speed produced a perceived improvement in my workflow.
      - usrbinbash 5y ago
        >which is often the only thing that one really needs) tail 1_gb_of.txt ...will get the last line of output long before the rendering engine finished initializing. And it will probably do so even on a 10year old laptop with no GPU, in virtual console, while the system is running under load ;-)

pradeepchhetri 5y ago

Well, atleast the CPU will be free for doing other things by offloading some work to GPU.

orangeoxidation 5y ago

Terminals don't just render what you see, but everything that programs output, which can be enormous amounts of text, grinding non-accelerated terminals to a halt. I don't know if they actually have to do this (It might be necessary for seamless scrolling?), but building some partial rendering might be more complicated than GPU acceleration as well. I'd be interested if someone knows more about this.

ahefner 5y ago

I don't get it either. The 2D APIs used for font rendering built into every window system (xrender, etc.) are already hardware accelerated and more than fast enough. Going to OpenGL or whatever this uses just seems ridiculous. There's no use case for rendering your terminal emulator at 10,000 frames per second.

baq 5y ago

Note that consoles back in the day (e.g. classic 80x25) were essentially hardware accelerated.

samwillis 5y ago
I suppose that’s quite true as you were probably running in something like VGA text mode.

otabdeveloper4 5y ago

> What is the advantage of GPU acceleration for a terminal emulator? I haven't found any. Seems like it's just a fashion accessory for $THIS_YEAR.

samwillis 5y ago
I don’t think there is anything wrong with that. Also building a GPU accelerated terminal emulator is probably a brilliant project to learn loads of low level skills.

vidarh 5y ago

Very little unless you use shaders for effects. . Updating terminals fast enough was a solved problem on 30 year old hardware. Most of the slowness of some terminal apps is down to poor design not CPU rendering (see the speed differences between various CPU rendered terminals)

floatboth 5y ago
30 year old hardware didn't have to render fancy antialiased fonts at 3840x2160 @ 144Hz.
- vidarh 5y ago
  My computer in the 80s ran at 7.16MHz and a single core. The CPU speedup has increased far more than the amount of data to be moved even at the kind of setup you're describing.
  - floatboth 5y ago
    Data rates for display have increased very much too. Don't underestimate the, uhh, "how rectangles work" factor – doubling the resolution means doubling both width and height, so quadrupling the pixel count. 80s computers also used lots of special hardware for graphics output, they didn't software render everything ;)
    - vidarh 5y ago
      Yes, but as I said the increase in data rates has not been anywhere near as fast as the increase in CPU speed, even with the unusal example you gave. As for special hardware for graphics output, that's not really true. Some, sure. My Amiga had a basic blitter. But all that allowed for that helped a terminal was scrolling at a few times higher speed than the CPU - it was limited by the memory bus speed. That was revolutionary at the time. Most other 80's hardware had much less, except for having character modes, but I was specifically talking about ones using bitmap screens like the Amiga for example. But a blitter does not help you with the worst case scenario of filling the terminal with text from scratch as the setup cost is typically higher than the cost of having the CPU render individual characters (it certainly was on the Amiga - the blitter helped when moving larger chunks of data, but not for character sized areas). I have written terminals for 1980s hardware and for modern hardware. I know where the bottlenecks are and there is no issue whatsoever keeping up with the graphical display. When a terminal is slow it's a design issue.