3 ms·

> A whole lot of the obsession with GPU acceleration in terminal emulators and text editors is not driven by benchmarking against the fastest alternatives, but

by dahart 5y ago

> A whole lot of the obsession with GPU acceleration in terminal emulators and text editors is not driven by benchmarking against the fastest alternatives, but cargo-culting. It seems strange to demand evidence and benchmarking but end with pure unsupported hyperbolic opinion. If you can’t explain why a huge number of major text editors are now starting to support GPU rendering directly, nor why the OS has already for a long time been using the GPU instead of the CPU for rendering, then it seems like you might simply be ignorant of their reasons, unaware of the measurements that demonstrate the benefits. I really don’t even know what were talking about anymore exactly, since you moved the goal posts. I don’t disagree that most of the time text rendering isn’t consuming a ton of resources, until it does. I don’t disagree that many editors aren’t exactly optimized. None of that changes the benefits of offloading framebuffer work to the GPU. The ship sailed already, it’s too late to quibble. I can’t speak to rxvt vs Kitty (you really need to do a comparison of features and their design decisions and team sizes and budgets before assuming your cherry picked apps reflect on the hardware in any way), but by and large everyone already moved to the GPU and justifications are pretty solidly explained and understood, evidence for these decisions abounds if you care to look for it.

vidarh 5y ago
I have not demanded evidence. I have suggested that you try benchmarking and measuring this for yourself, because it would demonstrate very clearly the points I've been making. I don't need evidence from you, because I've spent a huge amount of time actually testing and profiling more terminals and editors than most people can name. > If you can’t explain why a huge number of major text editors are now starting to support GPU rendering directly I did give a reason: It's largely cargo-culting. Some have other reasons. E.g. using shaders to offer fancy effects is a perfectly valid reason if you want those effects. Most of these applications do not take advantage of that. Some, like the linked one, are learning experiences, and that's also a perfectly fine justification. Very few have put any effort into actually benchmarking their code to a terminal which is actually fast - most of the performance claims I've seen comes from measuring against slow alternatives. Hence why "cherry picking" rxvt: The point being to illustrate that when someone can't even match rxvt, which is open source and so easy to copy and at least match in performance, maybe they should actually figure out why rxvt is fast first before worrying about the specific low level rendering choice. One of the things people would learn from that is that the rendering choice is rarely where the bottlenecks arise. > then it seems like you might simply be ignorant of their reasons, unaware of the measurements that demonstrate the benefits. I've done many enough code reviews and enough measurements and benchmarking of terminals and text rendering code over the years that I'm quite content in my knowledge that I know the performance characteristics of this better than most of those who have implemented the large number of poorly performing terminals over the years. That's not a criticism of most of them - performance on text rendering is simply such a minor aspect of a terminal because most of them are fast enough that it's rarely priority. What this has taught me is that the rendering itself isn't typically the bottleneck. It hasn't been the bottleneck for most such projects since the 1980's. You can continue to disbelieve that all you want. Or you can try actually looking at some of this code yourself and try profiling it, and you'll see the same thing. Your choice. > I really don’t even know what were talking about anymore exactly, since you moved the goal posts. I did no such thing. In the comment I made that you replied to first I made two claims: 1. that it is not a given GPU use will be faster. 2. that for most text-heavy apps there's little reason for the text-rendering to be a bottleneck either way. I stand by those. > I don’t disagree that most of the time text rendering isn’t consuming a ton of resources, until it does. My point is that the "until it does" is largely irrelevant, as even the most pathological case for a terminal is easily accommodated and in practice almost never occurs. And as you pointed out a lot of OS text rendering support is accelerated anyway (or will get there), which makes this largely moot anyway by making it a system concern rather than something an application ought to put effort into dealing with. > I don’t disagree that many editors aren’t exactly optimized. None of that changes the benefits of offloading framebuffer work to the GPU. The point is that the failure of prominent "accelerated" terminals to even match rxvt is a demonstration that spending the effort to write code that is far less portable is a poor tradeoff and tend to show that people writing these terminals rarely understand where the actual bottlenecks are. > but by and large everyone already moved to the GPU This is only true to the extent you're calling running on top of OS API's that have been accelerated as "moving to the GPU". The vast majority of terminal emulators and editors are still relying on generic APIs that may or may not be accelerated depending on where they're running. Only a small minority are targeting GPU specific APIs. In this context when people are talking about GPU accelerated editors or terminals, they're talking about the latter.

by dahart 5y ago

vidarh 5y ago

I have not demanded evidence. I have suggested that you try benchmarking and measuring this for yourself, because it would demonstrate very clearly the points I've been making. I don't need evidence from you, because I've spent a huge amount of time actually testing and profiling more terminals and editors than most people can name. > If you can’t explain why a huge number of major text editors are now starting to support GPU rendering directly I did give a reason: It's largely cargo-culting. Some have other reasons. E.g. using shaders to offer fancy effects is a perfectly valid reason if you want those effects. Most of these applications do not take advantage of that. Some, like the linked one, are learning experiences, and that's also a perfectly fine justification. Very few have put any effort into actually benchmarking their code to a terminal which is actually fast - most of the performance claims I've seen comes from measuring against slow alternatives. Hence why "cherry picking" rxvt: The point being to illustrate that when someone can't even match rxvt, which is open source and so easy to copy and at least match in performance, maybe they should actually figure out why rxvt is fast first before worrying about the specific low level rendering choice. One of the things people would learn from that is that the rendering choice is rarely where the bottlenecks arise. > then it seems like you might simply be ignorant of their reasons, unaware of the measurements that demonstrate the benefits. I've done many enough code reviews and enough measurements and benchmarking of terminals and text rendering code over the years that I'm quite content in my knowledge that I know the performance characteristics of this better than most of those who have implemented the large number of poorly performing terminals over the years. That's not a criticism of most of them - performance on text rendering is simply such a minor aspect of a terminal because most of them are fast enough that it's rarely priority. What this has taught me is that the rendering itself isn't typically the bottleneck. It hasn't been the bottleneck for most such projects since the 1980's. You can continue to disbelieve that all you want. Or you can try actually looking at some of this code yourself and try profiling it, and you'll see the same thing. Your choice. > I really don’t even know what were talking about anymore exactly, since you moved the goal posts. I did no such thing. In the comment I made that you replied to first I made two claims: 1. that it is not a given GPU use will be faster. 2. that for most text-heavy apps there's little reason for the text-rendering to be a bottleneck either way. I stand by those. > I don’t disagree that most of the time text rendering isn’t consuming a ton of resources, until it does. My point is that the "until it does" is largely irrelevant, as even the most pathological case for a terminal is easily accommodated and in practice almost never occurs. And as you pointed out a lot of OS text rendering support is accelerated anyway (or will get there), which makes this largely moot anyway by making it a system concern rather than something an application ought to put effort into dealing with. > I don’t disagree that many editors aren’t exactly optimized. None of that changes the benefits of offloading framebuffer work to the GPU. The point is that the failure of prominent "accelerated" terminals to even match rxvt is a demonstration that spending the effort to write code that is far less portable is a poor tradeoff and tend to show that people writing these terminals rarely understand where the actual bottlenecks are. > but by and large everyone already moved to the GPU This is only true to the extent you're calling running on top of OS API's that have been accelerated as "moving to the GPU". The vast majority of terminal emulators and editors are still relying on generic APIs that may or may not be accelerated depending on where they're running. Only a small minority are targeting GPU specific APIs. In this context when people are talking about GPU accelerated editors or terminals, they're talking about the latter.