12 ms·
Just curious, why GPU rendered?
by cosmotic 5y ago
Just curious, why GPU rendered?
- ben-schaaf 5y agoCan't speak for this project, but you simply can't get good performance at high resolutions (4k+) using CPU rendering.
- sidpatil 5y agoI suppose "good performance" is subjective. I run VS Code on a 4k (well, 3840-by-2160) monitor attached to a ThinkPad T440, and the performance is acceptable. The CPU does get busier, but not by much. Though, the biggest limitation is that the framerate is only 30Hz since the HDMI version is older on that laptop, so maybe that has something to do with it as well.
- vidarh 5y agoYou could get good performance with CPU rendering on machines several orders of magnitude slower than what we had today to screens that certainly did not have as many orders of magnitude fewer pixels.
- pcwalton 5y agoIt's the right choice. Otherwise you're wasting power for no reason. The only reason not to use the GPU is driver bugs, usually on Linux, that cause it to use more energy than the CPU.
- nomel 5y agoWhy would you paint pixels with a CPU when you have a GPU that's optimized for it? :)
- vidarh 5y agoThat depends on how much of the effort requires CPU work in order to transfer data to the GPU relative to the work that will actually be done on the GPU. For text rendering it's possible but not a given you'll save all that much, depending on how fast your GPU is, and how big you're rendering the glyphs, and whether or not you're applying any effects to them. For most text-heavy apps there's little reason for the text-rendering to be a bottleneck either way.
- dahart 5y agoWhile you’re right that it does depend, the imbalance is so large in practice that it’s extremely difficult to find a workload where CPU wins, especially when you’re talking about 2d screen rendering. The bottlenecks are: per-pixel compute multiplied by the number of pixels, and bandwidth of transferring data to the GPU (must include this when doing “CPU” rendering). What does CPU rendering even mean? Is it sending per-pixel instructions to the GPU, or is it rendering a framebuffer in CPU ram, and transferring that to the GPU or something else? Pure software would be the latter (save pixels to a block of RAM, then transfer to the GPU), but the line today isn’t very clear because most CPU renderers aren’t transferring pixels, they’re calling OS level drawing routines that are turned into GPU commands. Most of the time, CPU rendering is mostly GPU rendering anyway. > there’s little reason for the text-rendering to be a bottleneck either way. Think about 4K screens, which is up to 8M pixels to render. Suppose you’re scrolling and want 60fps. If you wanted to rendering this to your own framebuffer in RAM, and you render in 24 bit color, then your bandwidth requirement is 8M * 3bytes * 60frames = 1.4GB/s bandwidth. It’s also 8M * 60 pixel rendering operations. Even if the per-pixel rendering was 1 single CPU instruction (it’s more, probably a lot more, but suppose anyway) then the CPU load is 0.5 billion instructions per second, which is a heavy load even without any cache misses. Most likely, this amount of rendering would consume 100% of a CPU core at 4K. Anyway, there’s no reason to have the CPU do all this work and to fill the bus with pixels when we have hardware for it.
- stonogo 5y agoperhaps the answer can be found in the 'motivation' section of the linked website. "The base motivation was just simply that i wanted to have a look into OpenGL and doing GPU accelerated things, i did not plan to create a text editor from the get go. After starting to experiment a bit i decided to call this a small side Project and implement a proper editor."
- chrisseaton 5y agoDon't all serious desktop environment render glyphs using the GPU anyway? So don't you get that for free when you use the standard frameworks?
- myfavoritedog 5y agoStandard frameworks give you text frames with minimal hooks to customize them and "good enough" performance. They're great for dumping a log file to or for small documents, but when you want the fine control of a text editor that can handle big files, you need to roll your own.
- kazinator 5y agoGPU acceleration of the text editing viewport, which will not show much more than 100 lines of text at any time, has almost nothing to do with the issues in editing large files.
- floatboth 5y agoGtk4 and QML sure do (QML still (?) uses SDFs, Gtk4 uses atlas textures like WebRender does). Older frameworks don't.
- jcelerier 5y agoThe default in QML used to be atlases, you can revert back to them with the following: renderType: Text.NativeRendering or: QQuickWindow::setTextRenderType
- mananaysiempre 5y agoBecause 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 agoGPUs used to be 2D oriented. You’re making me feel very old now, lol.
- zaptheimpaler 5y agoJust one more answer - why not? It seems to me that GPUs are heavily underutilized most of the time a PC is running. They kick in only in a few rare applications like gaming/rendering/video decoding and run at literal 0% utilization the other times (atleast according to what windows task manager tells me). On the other hand, the CPU is often busy. Particularly for a text editor, theres a good chance the user is running all sorts of CPU heavy stuff like code analysis tools, databases, compile loops etc.
- fulafel 5y agoLearning, as it reads on the page. GPU programming is hard, and splitting work between CPU and GPU is too, at least if you try to make the program go faster.