4 ms·

Because it’s very easy for the CPU-GPU interface to become the bottleneck, as state-of-the-art resolutions require shoving around literal gigabytes per second t

Because it’s very easy for the CPU-GPU interface to become the bottleneck, as state-of-the-art resolutions require shoving around literal gigabytes per second to get a standard framerate (seriously, make a rough estimate how much data your 300 ppi phone or tablet is pumping over the bus to the screen, it’s chilling), and the less you do it the better. (See a HN comment about Audacity slowing down in recent years [as screen resolution increases]: https://news.ycombinator.com/item?id=26498649 https://news.ycombinator.com/item?id=26498649.) Getting a not-quite-SIMD processing unit specializing in throughput above all else to do your heavy lifting is a bonus. I suspect the underlying question is “why a supposedly-3D-optimized GPU for a 2D task?” While it’s true that modern GPUs are 3D-optimized, that’s AFAICS because the decade-long lull of 1MP-or-so screens and ever-more-powerful desktop CPUs ca. 2000–2010(?) made CPU 2D rendering mostly “fast enough” so as the programmable 3D pipeline emerged the 2D accelerator from the workstation era died out, leaving perhaps only an optimized blit behind. Compute- and power-constrained handheld devices and higher-resolution screens made developers (software and hardware) wake up in a hurry, but now, a redraw-everything-every frame, 3D-adapted graphics facility is what you have, so a redraw-everything-every-frame, 3D-adapted graphics facility is what you shall use. The much more parallel and power-efficient processor and wider bus is still easily worth it, if you spend the effort to wrangle it. (It’s interesting to think what 2D-optimized hardware would look like. Do people know how to do analytic or even just AGG-quality 2D rasterization on a GPU? Or anything but simple oversampling.) Not a graphics programmer, treat with a measure of skepticism.

zozbot234 5y ago
> Do people know how to do analytic or even just AGG-quality 2D rasterization on a GPU? I suppose the sensible answer is "do it in a compute shader if you care about pixel-perfect accuracy". Which you arguably should for 2D stuff, given that the overhead is low enough.
deleted 5y ago
[deleted]
adastra22 5y ago
GPUs used to be 2D oriented. You’re making me feel very old now, lol.
- zozbot234 5y ago
  Sure, but did that "2D" orientation boil down to anything beyond accelerated blitting and perhaps a few geometry-rendering primitives? Part of the problem is also that there never was a standard feature set and API for 2D acceleration comparable to OpenGL or Vulkan. So support for it was highly hardware-dependent and liable to general bit rot.
  - sfuller808 5y ago
  - CodeArtisan 5y ago
    VESA had one but it never took off. https://web.archive.org/web/20081209121702/http://www.vesa.org/public/VBE/VBE-AF07.pdf https://web.archive.org/web/20081209121702/http://www.vesa.o...
  - adastra22 5y ago
    Yes, there were other hardware acceleration tricks implemented. For example, hardware sprites allowed for bitmaps that were composed in real time for display rather than blitted to the framebuffer. This trick is still used for the mouse cursor. There was hardware scrolling which meant you could move the whole display and only render the edge that came into view. Both of these together is how platformer games were implemented on the SNES and similar hardware of that generation, and it’s why the gameplay was so smooth. The NES could either do hardware sprites or hardware scrolling, but not both IIRC, which is why the game world freezes when Link reaches the edge of the screen and the new screen comes into view in the original Zelda. There were other hardware accelerations my memory is somewhat more vague on. I remember there were some color palate translation hardware, and hardware dithering. There wasn’t any standard cross platform graphics api back then, but that’s more a statement about the era. Everyone wrote directly to the metal.
cosmotic 5y ago
I guess I'm just looking for some evidence to support the decision to use GPU. Show some framerate benchmarks, some CPU usage comparisons, etc.
- dahart 5y ago
  Why does it need “evidence”? GPUs are fast and good at displaying pixels. Moving rendering to the GPU lets the CPU focus on things it’s good at rather than bog it down with a high bandwidth task that has to go to the GPU anyway. Lots of editors have been getting GPU acceleration (I use Sublime and Visual Studio among others, both have hardware acceleration). All major browsers and operating systems support hardware accelerated drawing. Video games of course… I think the question is why wouldn’t you use the GPU for rendering these days? It’s a pixel processor that nearly everyone has in their machine. What evidence is there to support the decision to render pixels on a CPU rather than use the rendering co-processor?
  - anthk 5y ago
    Because that's snake oil. I had accelerated 2D since XV days (XVideo extension for X) back in 2003.
    - dahart 5y ago
      I’m very confused by that comment, what do you mean snake oil? Are you saying GPUs don’t do anything? Isn’t the XV you’re referring to in the same category as today’s GPU wrt parent’s comment? @cosmotic asked for evidence why not to use the CPU, and XV is not implemented on the CPU. Also it looks like XV did video resizing and some color mapping (https://en.wikipedia.org/wiki/X_video_extension https://en.wikipedia.org/wiki/X_video_extension). Today’s GPUs are doing the rendering. Filling the display buffer using primitives and textures, and outputting the display buffer are different activities that are both done by the GPU today, but it sound like XV didn’t do the first part at all, and that first part is what we’re talking about here.
      - anthk 5y ago
ppier 5y ago
Raph Linus has recently has his work posted on HN, which features GPU rasterization [1] Also, Pathfinder [2] has the ability to do most of its rasterization on the GPU. I read somewhere that an experimental renderer for Google’s Fuchsia (Spinel?) [3] also does this. 1: https://github.com/linebender/piet-gpu https://github.com/linebender/piet-gpu 2: https://github.com/servo/pathfinder https://github.com/servo/pathfinder 3: https://www.tdcommons.org/cgi/viewcontent.cgi?article=1580&context=dpubs_series https://www.tdcommons.org/cgi/viewcontent.cgi?article=1580&c...
bityard 5y ago
I have been using computers on a daily basis since the mid 80's. I have seen many applications that stretched or exceeded the capabilities of the machine I was running them on, resulting in sub-par performance that left me wishing for a hardware upgrade to make using the application a more pleasant experience. None of them were text editors or terminal emulators.
- vidarh 5y ago
  Notably there's something like an order of magnitude or more difference in performance between terminals that people are perfectly happy to use. (EDIT: To quantify this: on my system, catting the same file to a window taking about half my screen took an average of 1.443s with st, 1.16 seconds with xterm, 0.165s with rxvt xterm, and 0.404s with Kitty - all average over 3 runs) Very few non-gpu accelerated terminals get anywhere near maximising performance and they're still fast enough that most people don't even notice because most applications, including most editors, once even remotely optimized themselves, don't tend to push even a non-accelerated terminal very hard. Put another way: a typical test case of the performance of a terminal tends to be spewing log output or similar to it at a rate where the obvious fix is to simply decouple the text buffer from the render loop because nobody can read it all anyway (but really, a lot of the developers of these terminals should start by looking at rxvt and at least get to a decent approximation first before they start doing those kinds of shortcuts) Fast enough terminal rendering was solved by the mid 1980s, and performance increases have outpaced resolution increases by a substantial factor.
dahart 5y ago
> why a supposedly-3D-optimized GPU for a 2D task […] 3D-adapted graphics facility is what you shall use. Modern GPUs & so-called 3D APIs don’t really do all that much that is 3D specific. @greggman likes to talk about WebGL as a fundamentally 2D API https://webglfundamentals.org/webgl/lessons/webgl-2d-vs-3d-library.html https://webglfundamentals.org/webgl/lessons/webgl-2d-vs-3d-l... The bulk of the 3D work is still 2D, filling all the pixels, rasterizing 2D triangles after they’ve been transformed, projected to 2D, and clipped. Shaders might have lots of 3D math, but that’s really just pure math and no different from 2D math as far as the GPU is concerned. > Do people know how to do analytic or even just AGG-quality 2D rasterization on a GPU? Or anything but simple oversampling. Yes, I think so - if you mean quads & triangles. The problem, of course, is analytic filtering (even 2D) usually isn’t worth the cost, and that oversampling is cheap and effective and high enough quality for most tasks. (Still, adaptive oversampling and things like DLSS are popular ways to reduce the costs of oversampling.) The path rendering people think carefully about 2d path rendering though: https://hhoppe.com/ravg.pdf https://hhoppe.com/ravg.pdf https://developer.nvidia.com/gpu-accelerated-path-rendering https://developer.nvidia.com/gpu-accelerated-path-rendering And don’t forget mipmapped texture sampling, even in 2D, is better than oversampled. A very common shader trick for 2d antialiasing that’s better than oversampling (not analytic, but sometimes damn close) is to use the pixel derivatives to compute the edges of a mask that blends from opaque to transparent in ~1-pixel. https://www.shadertoy.com/view/4ssSRl https://www.shadertoy.com/view/4ssSRl

zozbot234 5y ago

> Do people know how to do analytic or even just AGG-quality 2D rasterization on a GPU? I suppose the sensible answer is "do it in a compute shader if you care about pixel-perfect accuracy". Which you arguably should for 2D stuff, given that the overhead is low enough.

deleted 5y ago

[deleted]

adastra22 5y ago

GPUs used to be 2D oriented. You’re making me feel very old now, lol.

zozbot234 5y ago
Sure, but did that "2D" orientation boil down to anything beyond accelerated blitting and perhaps a few geometry-rendering primitives? Part of the problem is also that there never was a standard feature set and API for 2D acceleration comparable to OpenGL or Vulkan. So support for it was highly hardware-dependent and liable to general bit rot.
- sfuller808 5y ago
- CodeArtisan 5y ago
  VESA had one but it never took off. https://web.archive.org/web/20081209121702/http://www.vesa.org/public/VBE/VBE-AF07.pdf https://web.archive.org/web/20081209121702/http://www.vesa.o...
- adastra22 5y ago
  Yes, there were other hardware acceleration tricks implemented. For example, hardware sprites allowed for bitmaps that were composed in real time for display rather than blitted to the framebuffer. This trick is still used for the mouse cursor. There was hardware scrolling which meant you could move the whole display and only render the edge that came into view. Both of these together is how platformer games were implemented on the SNES and similar hardware of that generation, and it’s why the gameplay was so smooth. The NES could either do hardware sprites or hardware scrolling, but not both IIRC, which is why the game world freezes when Link reaches the edge of the screen and the new screen comes into view in the original Zelda. There were other hardware accelerations my memory is somewhat more vague on. I remember there were some color palate translation hardware, and hardware dithering. There wasn’t any standard cross platform graphics api back then, but that’s more a statement about the era. Everyone wrote directly to the metal.

cosmotic 5y ago

I guess I'm just looking for some evidence to support the decision to use GPU. Show some framerate benchmarks, some CPU usage comparisons, etc.

dahart 5y ago
Why does it need “evidence”? GPUs are fast and good at displaying pixels. Moving rendering to the GPU lets the CPU focus on things it’s good at rather than bog it down with a high bandwidth task that has to go to the GPU anyway. Lots of editors have been getting GPU acceleration (I use Sublime and Visual Studio among others, both have hardware acceleration). All major browsers and operating systems support hardware accelerated drawing. Video games of course… I think the question is why wouldn’t you use the GPU for rendering these days? It’s a pixel processor that nearly everyone has in their machine. What evidence is there to support the decision to render pixels on a CPU rather than use the rendering co-processor?
- anthk 5y ago
  Because that's snake oil. I had accelerated 2D since XV days (XVideo extension for X) back in 2003.
  - dahart 5y ago
    I’m very confused by that comment, what do you mean snake oil? Are you saying GPUs don’t do anything? Isn’t the XV you’re referring to in the same category as today’s GPU wrt parent’s comment? @cosmotic asked for evidence why not to use the CPU, and XV is not implemented on the CPU. Also it looks like XV did video resizing and some color mapping (https://en.wikipedia.org/wiki/X_video_extension https://en.wikipedia.org/wiki/X_video_extension). Today’s GPUs are doing the rendering. Filling the display buffer using primitives and textures, and outputting the display buffer are different activities that are both done by the GPU today, but it sound like XV didn’t do the first part at all, and that first part is what we’re talking about here.
    - anthk 5y ago

ppier 5y ago

Raph Linus has recently has his work posted on HN, which features GPU rasterization [1] Also, Pathfinder [2] has the ability to do most of its rasterization on the GPU. I read somewhere that an experimental renderer for Google’s Fuchsia (Spinel?) [3] also does this. 1: https://github.com/linebender/piet-gpu https://github.com/linebender/piet-gpu 2: https://github.com/servo/pathfinder https://github.com/servo/pathfinder 3: https://www.tdcommons.org/cgi/viewcontent.cgi?article=1580&context=dpubs_series https://www.tdcommons.org/cgi/viewcontent.cgi?article=1580&c...

bityard 5y ago

I have been using computers on a daily basis since the mid 80's. I have seen many applications that stretched or exceeded the capabilities of the machine I was running them on, resulting in sub-par performance that left me wishing for a hardware upgrade to make using the application a more pleasant experience. None of them were text editors or terminal emulators.

vidarh 5y ago
Notably there's something like an order of magnitude or more difference in performance between terminals that people are perfectly happy to use. (EDIT: To quantify this: on my system, catting the same file to a window taking about half my screen took an average of 1.443s with st, 1.16 seconds with xterm, 0.165s with rxvt xterm, and 0.404s with Kitty - all average over 3 runs) Very few non-gpu accelerated terminals get anywhere near maximising performance and they're still fast enough that most people don't even notice because most applications, including most editors, once even remotely optimized themselves, don't tend to push even a non-accelerated terminal very hard. Put another way: a typical test case of the performance of a terminal tends to be spewing log output or similar to it at a rate where the obvious fix is to simply decouple the text buffer from the render loop because nobody can read it all anyway (but really, a lot of the developers of these terminals should start by looking at rxvt and at least get to a decent approximation first before they start doing those kinds of shortcuts) Fast enough terminal rendering was solved by the mid 1980s, and performance increases have outpaced resolution increases by a substantial factor.

dahart 5y ago

> why a supposedly-3D-optimized GPU for a 2D task […] 3D-adapted graphics facility is what you shall use. Modern GPUs & so-called 3D APIs don’t really do all that much that is 3D specific. @greggman likes to talk about WebGL as a fundamentally 2D API https://webglfundamentals.org/webgl/lessons/webgl-2d-vs-3d-library.html https://webglfundamentals.org/webgl/lessons/webgl-2d-vs-3d-l... The bulk of the 3D work is still 2D, filling all the pixels, rasterizing 2D triangles after they’ve been transformed, projected to 2D, and clipped. Shaders might have lots of 3D math, but that’s really just pure math and no different from 2D math as far as the GPU is concerned. > Do people know how to do analytic or even just AGG-quality 2D rasterization on a GPU? Or anything but simple oversampling. Yes, I think so - if you mean quads & triangles. The problem, of course, is analytic filtering (even 2D) usually isn’t worth the cost, and that oversampling is cheap and effective and high enough quality for most tasks. (Still, adaptive oversampling and things like DLSS are popular ways to reduce the costs of oversampling.) The path rendering people think carefully about 2d path rendering though: https://hhoppe.com/ravg.pdf https://hhoppe.com/ravg.pdf https://developer.nvidia.com/gpu-accelerated-path-rendering https://developer.nvidia.com/gpu-accelerated-path-rendering And don’t forget mipmapped texture sampling, even in 2D, is better than oversampled. A very common shader trick for 2d antialiasing that’s better than oversampling (not analytic, but sometimes damn close) is to use the pixel derivatives to compute the edges of a mask that blends from opaque to transparent in ~1-pixel. https://www.shadertoy.com/view/4ssSRl https://www.shadertoy.com/view/4ssSRl