Keeping the Screen Turned off While Getting Inputs

[Vladimir Dergachev]

On Sat, 26 Aug 2023, Ahmad Nouralizadeh wrote:

> > > However, I would have expected that VLC would produce a lot
> > > GPU/iGPU accesses even without drawing anything, because it would
> > > try to use GPU decoder.
> 
> For the discrete GPU, the turned off screen requires much smaller bandwidth in any benchmark (reduces from 2GB/s to several KB/s). The same seems to be true with iGPU. Of course, there might exist
> some DRAM accesses originating from the GPU/iGPU. But the main traffic seems to fade. These assumptions are based on my experiments and I could be wrong.
> (P.S.: VLC seems to be aware of the screen state. The rendering thread will stop when the screen is off (mentioned here:https://stackoverflow.com/q/76891645/6661026).)
> 
> > > Displaying video is also often done using GL or Xvideo - plain X is
> > > too slow for this.
> I'm looking for a simpler solution. I'm not familiar with these Xorg-related concepts! It seems a bit strange that turning off screen requires so much effort! If `xset dpms force off` would not
> cause screen activation with user input or `xrandr --output...` wouldn't cause segfault, everything would be fine.

Here is a simplified explanation:

In order to display anything on the screen the video card needs an array 
of data given color of each pixel. This is usually called "framebuffer" 
because it buffers data for one frame of video.

For every monitor you plugged in there is a separate framebuffer, unless 
they display the same thing (mirror).

To draw, the CPU either sends data directly to framebuffer, requests video 
card to pull data from RAM, or does some more complicated combination of 
the two (this includes GL and Xvideo acceleration).

So you have a system CPU -> Video Card -> Monitor

When you request "dpms off" all this does is tell monitor to turn off the 
light and save power. Everything that normally be drawn will still be 
drawn, as you can verify using x11vnc and vncviewer.

When you request "xrandr ... --off" you are requesting the equivalent of 
physically unplugging monitor cable. The framebuffer associated with that 
monitor will get destroyed. That's likely why you saw that gnome-panel 
error - some library it relies on could not deal with the fact that the 
framebuffer it was supposed to draw into suddenly disappeared.

>From the point of view of a benchmark you need to be very careful not 
alter the task, as modern systems love to optimize.

For example, many applications will stop drawing when their window is 
fully obscured (don't know about vlc, but likely).

However, this behaviour will change depending on whether compositor is 
enabled, and even depending on how many windows are open as compositor has 
limits.

best

Vladimir Dergachev


> 
> >edit to add: google suggests another candidate might be something
> >called pin-instatPin works at the source code level. It counts source-level accesses which might not reach DRAM (e.g., services by caches).
> 
> > > best
> > >
> > > Vladimir Dergachev 
> 
>