4 ms·

Is there any indication of the energy impact using a GL context to render plain old text? These concepts seem incompatible in the context of a laptop, and who n

Is there any indication of the energy impact using a GL context to render plain old text? These concepts seem incompatible in the context of a laptop, and who needs GL here when the bottleneck is biological. One of my favourite working modes is shutting down everything and just hacking away in vim, partly for distraction management but primarily because of battery.

traverseda 5y ago
Everything is a GL context under wayland isn't it?
- Cloudef 5y ago
  It's technically possible to create a wayland compositor without GL/GLES/Vulkan, but only SHM clients will work, unless you go with mixed approach which wouldn't be zero-copy. (Or of course you could also use llvmpipe or something to do software emulation of GL, but that will be very slow and ineffective). I'm not aware of any such wayland compositor however.
halz 5y ago
There is at lease one open issue¹ with the clipboard crate that causes a high amount of wakeups (under Wayland at least). Whatmore, the wakeups scale with the number of terminals open. The project is ruthless about performance[latency] regressions, but not so much about performance[energy] overhead. [¹https://github.com/alacritty/alacritty/issues/3108 https://github.com/alacritty/alacritty/issues/3108]
- Narishma 5y ago
  They seem to care more about throughput than latency.
  - jorams 5y ago
    Yes, which seems very very weird to me. When it launched they immediately marketed it as super fast, but just typing into it had noticeable latency. Throughput is great if a command is producing massive amounts of output, but it's not like you're going to read at that speed. I can usually pipe into less instead. I hope latency has improved to be much better. Haven't tried it in a few years.
slabity 5y ago
Well it can't be known for certain without performing benchmarks to test it, but I would presume a hardware-accelerated renderer is far more efficient than a software-based one.
reader_mode 5y ago
Why would GL rendering be any less efficient ? You don't have to rerender the entire screen in GL or render at MAX FPS if nothing changed.
- deleted 5y ago
  [deleted]
- stuaxo 5y ago
  It may or may not be - it certainly should be tested.
- cookguyruffles 5y ago
  I'd be incredibly surprised if mobile power management did not account for the difference between "blitting array of 2D pixels" and "running massively parallel shader". Even if not done for energy conservation, it might be for TDP profile. Separately, it's long been a thing on Nvidia Optimus laptops where the most inexplicable thing could cause the iGPU to be swapped out for the power-hungry discrete GPU. A GL-powered terminal definitely seems like it could be in that territory. In short, many reasons it could be less efficient, hence the question, is there any evidence that it /is/ less efficient?
  - reader_mode 5y ago
    These days a lot (most ?) of rendering toolkits are GPU accelerated, including things like your browser - you'd likely hit those issues with other apps as well then. You could hit drivers bugs for sure, but that means in your particular config GL will be worse so you need to test, doubt this translates to a general scenario. I think a lot of people assume because your default GL setup is to use immediate mode to re-render everything at refresh rate that's the only way to do rendering and that's why GL apps get the reputation for being power hungry.

traverseda 5y ago

Everything is a GL context under wayland isn't it?

Cloudef 5y ago
It's technically possible to create a wayland compositor without GL/GLES/Vulkan, but only SHM clients will work, unless you go with mixed approach which wouldn't be zero-copy. (Or of course you could also use llvmpipe or something to do software emulation of GL, but that will be very slow and ineffective). I'm not aware of any such wayland compositor however.

halz 5y ago

There is at lease one open issue¹ with the clipboard crate that causes a high amount of wakeups (under Wayland at least). Whatmore, the wakeups scale with the number of terminals open. The project is ruthless about performance[latency] regressions, but not so much about performance[energy] overhead. [¹https://github.com/alacritty/alacritty/issues/3108 https://github.com/alacritty/alacritty/issues/3108]

Narishma 5y ago
They seem to care more about throughput than latency.
- jorams 5y ago
  Yes, which seems very very weird to me. When it launched they immediately marketed it as super fast, but just typing into it had noticeable latency. Throughput is great if a command is producing massive amounts of output, but it's not like you're going to read at that speed. I can usually pipe into less instead. I hope latency has improved to be much better. Haven't tried it in a few years.

slabity 5y ago

Well it can't be known for certain without performing benchmarks to test it, but I would presume a hardware-accelerated renderer is far more efficient than a software-based one.

reader_mode 5y ago

Why would GL rendering be any less efficient ? You don't have to rerender the entire screen in GL or render at MAX FPS if nothing changed.

deleted 5y ago
[deleted]
stuaxo 5y ago
It may or may not be - it certainly should be tested.
cookguyruffles 5y ago
I'd be incredibly surprised if mobile power management did not account for the difference between "blitting array of 2D pixels" and "running massively parallel shader". Even if not done for energy conservation, it might be for TDP profile. Separately, it's long been a thing on Nvidia Optimus laptops where the most inexplicable thing could cause the iGPU to be swapped out for the power-hungry discrete GPU. A GL-powered terminal definitely seems like it could be in that territory. In short, many reasons it could be less efficient, hence the question, is there any evidence that it /is/ less efficient?
- reader_mode 5y ago
  These days a lot (most ?) of rendering toolkits are GPU accelerated, including things like your browser - you'd likely hit those issues with other apps as well then. You could hit drivers bugs for sure, but that means in your particular config GL will be worse so you need to test, doubt this translates to a general scenario. I think a lot of people assume because your default GL setup is to use immediate mode to re-render everything at refresh rate that's the only way to do rendering and that's why GL apps get the reputation for being power hungry.