4 ms·

I was amused to read this morning that Microsoft's new Terminal client has "GPU accelerated text rendering engine". WT actual F??? You can't run a terminal wind

I was amused to read this morning that Microsoft's new Terminal client has "GPU accelerated text rendering engine". WT actual F??? You can't run a terminal window without a few Gig of video ram and a couple of teraflops of GPU horsepower??? Boggle! https://www.theregister.co.uk/2019/06/24/microsoft_round_up/ https://www.theregister.co.uk/2019/06/24/microsoft_round_up/

comex 7y ago
If you're on, say, a 4K 10-bit display, there's quite a bit more pixel data to push than there used to be. You still don't need a GPU just to draw text, but since you already have one, using it will provide better performance and likely consume less power.
- Crinus 7y ago
  > but since you already have one, Since i already have one i might want to use it for other things. The reason computers are slow is this sort of "since you already have that resource, might as well use it" thinking - which makes sense if only one program does it, but if almost all programs do it then it breaks down quickly.
  - skybrian 7y ago
    The same could be said for the CPU, and this helps free up the CPU for other things. It's a trade-off. But the underlying problem here is higher resolution screens than needed. Most people don't actually need a 4k display. Sometimes, they can't really see small print that easily anyway and what they need is UI's designed with large print in mind.
    - Crinus 7y ago
      CPUs are more generic though and pretty much every single GPU accelerated text drawing operation i've seen allocates permanent GPU resources (textures mainly). It isn't impossible to not do that, but if you only allocate the necessary resources for the GPU on an as-needed basis and then release them once you're done, you are introducing latency which invalidates any gains you may have. The alacritty terminal linked elsewhere in this post, for example, keeps a bunch of atlases around with hundreds of glyphs which are local to each instance of the program (thus using both CPU and GPU resources) and for macOS and Windows ignoring any system-wide glyph caching the APIs it uses may already have (caches that will be created - and thus resource allocated - anyway when it tries to rasterize those glyphs for its own use). FWIW yeah, i agree that most people do not really need 4K displays but that is another matter.
      - comex 7y ago
        > CPUs are more generic though Which is exactly why you want to save the GPU for what it does best – drawing pixels. > and pretty much every single GPU accelerated text drawing operation i've seen allocates permanent GPU resources (textures mainly). Makes sense as a concern, and it's not something I've looked into. (I don't use alacritty.) On the other hand, how much memory are we actually talking about? On my system (total screen resolution 2880x1800), a typical terminal glyph has a roughly 14x16 bounding box; let's bump that up to 20x20 to account for padding. Stored as 8-bit RGBA, that would take 1600 bytes. An atlas of "hundreds" of glyphs would then be expected to take up on the order of hundreds of KB... which seems pretty negligible? A larger font, multiple atlases, or more characters per atlas would require more memory, but I still don't see how you get to an amount worth worrying about. I could be missing something.
        bigiain 7y ago
        I'm sure my rose-tinted glasses memories of the olden days are entirely unfounded, but I've written code using a VT100 plugged into a VAX 11/780, and the first machine I had at home was an Osbourne 1, with a 4kHz Z80 processor and 64kb of ram (the top 4kb of which was the memory mapped video ram)... It seems the increase in utility we've got from being able to use teraflops of massively parallel GPU with Gigabytes of ram available - doesn't exactly match the 6 orders of magnitude or so more resource use... "It scrolls soooo smoothly, and you can use the poop emoji in your source code!!!" ;-) </old_man type='grumpy'>
        Crinus 7y ago
        One important thing you are missing is that you are focusing on a single instance of a single program doing that. These caches are not shared among programs and unless you are only running a single program at a time in your OS, if every program does such resource abuse (not necessarily this particular type of abuse, but in not caring about resources in general) then you get a slow computer. Computers feel as slow as ever (which was the topic a few nodes above) despite being much faster in theory not because of a single program but because all (or well, the overwhelming majority) the programs in your computer abuse resources - even if a little. It is death from a thousand little abuses.
jjeaff 7y ago
You don't in most cases, buy in the case of en enhanced terminal with things like full color emojis, and smooth scrolling rather than line by line, then I'm sure GPU acceleration will be welcome.
butteroverflow 7y ago
This is old news. Pretty usual situation for the MS world though. Take a look at alacritty. In my experience GPU rendering does provide buttery smooth scrolling and output for tons and tons of text. Now you can `cat` that 1 GiB log file that much faster! I still prefer libvte-based terminals though. https://github.com/jwilm/alacritty/ https://github.com/jwilm/alacritty/
tinus_hn 7y ago
A large terminal window is a surprisingly large amount of pixels. If you want to keep up with fast scrolling text you need some tricks. But GPU accelerated doesn’t necessarily mean you need gigabytes of memory or teraflops of compute power.
GuB-42 7y ago
Interestingly, GPU accelerated text rendering has always been a thing, except back then, it was called text mode (https://en.wikipedia.org/wiki/Text_mode https://en.wikipedia.org/wiki/Text_mode). And the main reason was to save memory and computing power. And even today, a GPU is designed to do graphics, that's in the name. Text rendering is graphics, so why not use it? It is more efficient than a CPU, and the reason it isn't done more isn't because one needs huge GPUs, but rather because it is more difficult for the devs. Because CPUs today are powerhouses and text is a rather simple task, devs take the easy way and do text rendering on the CPU. But when you throw Unicode, anti-aliasing and high resolution into the mix, things that modern terminals should support, it stops being so simple, and the GPU regains value.
mariusmg 7y ago
It's because of things like Alacritty https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty "Using the GPU for rendering enables optimizations that simply aren't possible without it"
MisterTea 7y ago
I thought about this the other day after I ripped on a similar concept. Yes, at first it seems like an incredibly dumb waste of resources. This is true if the rendering is used to only add useless fluff and effects to the rendering process. However, the G in GPU stands for graphics and accelerated graphics is nothing new. An early example I remember are the windows accelerator cards. https://en.wikipedia.org/wiki/Windows_accelerator https://en.wikipedia.org/wiki/Windows_accelerator Though let's be honest here, if the OS were designed properly then the terminal application would not need to worry if there is a GPU or not. The graphics libraries and drivers should take care of all that.

comex 7y ago

If you're on, say, a 4K 10-bit display, there's quite a bit more pixel data to push than there used to be. You still don't need a GPU just to draw text, but since you already have one, using it will provide better performance and likely consume less power.

Crinus 7y ago
> but since you already have one, Since i already have one i might want to use it for other things. The reason computers are slow is this sort of "since you already have that resource, might as well use it" thinking - which makes sense if only one program does it, but if almost all programs do it then it breaks down quickly.
- skybrian 7y ago
  The same could be said for the CPU, and this helps free up the CPU for other things. It's a trade-off. But the underlying problem here is higher resolution screens than needed. Most people don't actually need a 4k display. Sometimes, they can't really see small print that easily anyway and what they need is UI's designed with large print in mind.
  - Crinus 7y ago
    CPUs are more generic though and pretty much every single GPU accelerated text drawing operation i've seen allocates permanent GPU resources (textures mainly). It isn't impossible to not do that, but if you only allocate the necessary resources for the GPU on an as-needed basis and then release them once you're done, you are introducing latency which invalidates any gains you may have. The alacritty terminal linked elsewhere in this post, for example, keeps a bunch of atlases around with hundreds of glyphs which are local to each instance of the program (thus using both CPU and GPU resources) and for macOS and Windows ignoring any system-wide glyph caching the APIs it uses may already have (caches that will be created - and thus resource allocated - anyway when it tries to rasterize those glyphs for its own use). FWIW yeah, i agree that most people do not really need 4K displays but that is another matter.
    - comex 7y ago
      > CPUs are more generic though Which is exactly why you want to save the GPU for what it does best – drawing pixels. > and pretty much every single GPU accelerated text drawing operation i've seen allocates permanent GPU resources (textures mainly). Makes sense as a concern, and it's not something I've looked into. (I don't use alacritty.) On the other hand, how much memory are we actually talking about? On my system (total screen resolution 2880x1800), a typical terminal glyph has a roughly 14x16 bounding box; let's bump that up to 20x20 to account for padding. Stored as 8-bit RGBA, that would take 1600 bytes. An atlas of "hundreds" of glyphs would then be expected to take up on the order of hundreds of KB... which seems pretty negligible? A larger font, multiple atlases, or more characters per atlas would require more memory, but I still don't see how you get to an amount worth worrying about. I could be missing something.
      - bigiain 7y ago
        I'm sure my rose-tinted glasses memories of the olden days are entirely unfounded, but I've written code using a VT100 plugged into a VAX 11/780, and the first machine I had at home was an Osbourne 1, with a 4kHz Z80 processor and 64kb of ram (the top 4kb of which was the memory mapped video ram)... It seems the increase in utility we've got from being able to use teraflops of massively parallel GPU with Gigabytes of ram available - doesn't exactly match the 6 orders of magnitude or so more resource use... "It scrolls soooo smoothly, and you can use the poop emoji in your source code!!!" ;-) </old_man type='grumpy'>
      - Crinus 7y ago
        One important thing you are missing is that you are focusing on a single instance of a single program doing that. These caches are not shared among programs and unless you are only running a single program at a time in your OS, if every program does such resource abuse (not necessarily this particular type of abuse, but in not caring about resources in general) then you get a slow computer. Computers feel as slow as ever (which was the topic a few nodes above) despite being much faster in theory not because of a single program but because all (or well, the overwhelming majority) the programs in your computer abuse resources - even if a little. It is death from a thousand little abuses.

jjeaff 7y ago

You don't in most cases, buy in the case of en enhanced terminal with things like full color emojis, and smooth scrolling rather than line by line, then I'm sure GPU acceleration will be welcome.

butteroverflow 7y ago

This is old news. Pretty usual situation for the MS world though. Take a look at alacritty. In my experience GPU rendering does provide buttery smooth scrolling and output for tons and tons of text. Now you can `cat` that 1 GiB log file that much faster! I still prefer libvte-based terminals though. https://github.com/jwilm/alacritty/ https://github.com/jwilm/alacritty/

tinus_hn 7y ago

A large terminal window is a surprisingly large amount of pixels. If you want to keep up with fast scrolling text you need some tricks. But GPU accelerated doesn’t necessarily mean you need gigabytes of memory or teraflops of compute power.

GuB-42 7y ago

Interestingly, GPU accelerated text rendering has always been a thing, except back then, it was called text mode (https://en.wikipedia.org/wiki/Text_mode https://en.wikipedia.org/wiki/Text_mode). And the main reason was to save memory and computing power. And even today, a GPU is designed to do graphics, that's in the name. Text rendering is graphics, so why not use it? It is more efficient than a CPU, and the reason it isn't done more isn't because one needs huge GPUs, but rather because it is more difficult for the devs. Because CPUs today are powerhouses and text is a rather simple task, devs take the easy way and do text rendering on the CPU. But when you throw Unicode, anti-aliasing and high resolution into the mix, things that modern terminals should support, it stops being so simple, and the GPU regains value.

mariusmg 7y ago

It's because of things like Alacritty https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty "Using the GPU for rendering enables optimizations that simply aren't possible without it"

MisterTea 7y ago

I thought about this the other day after I ripped on a similar concept. Yes, at first it seems like an incredibly dumb waste of resources. This is true if the rendering is used to only add useless fluff and effects to the rendering process. However, the G in GPU stands for graphics and accelerated graphics is nothing new. An early example I remember are the windows accelerator cards. https://en.wikipedia.org/wiki/Windows_accelerator https://en.wikipedia.org/wiki/Windows_accelerator Though let's be honest here, if the OS were designed properly then the terminal application would not need to worry if there is a GPU or not. The graphics libraries and drivers should take care of all that.