On Sun, 27 Aug 2023, Ahmad Nouralizadeh wrote:
> 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. Thank you for the enlightening explanation! An unrelated question: IIUC the framebuffer is a shared memory in userspace. I see a huge amount of memory (around 1GB) in the kernel space related to sth called the GEM layer. Why is this large allocation needed?
The framebuffer that is displayed on the monitor is always in video card memory. There is a piece of hardware (CRTC) that continuously pulls data from the framebuffer and transmits it to the monitor.
A notable special case is when the "video card" is part of the CPU, in this case the main memory can serve dual purpose: most of it used by the main CPU, while a portion of main memory is allocated to the video card (there are BIOS options to change the amount).
This has impact on the performance - the CRTC needs to send a frame to the monitor at the refresh rate and it needs to pull data from memory - everything else has to wait.
If you are using a 4K (3840x2160) monitor that refreshes at 60 Hz, with each pixel a customary 32 bits, the CRTC needs 2 GB/s of bandwidth.
> 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. How does the interactive input cause screen reactivation? Is it signaled in software? If yes, perhaps the signal could be hidden by some small changes in the software to prevent the reactivation.
There is likely a piece of software that sends "dpms on" the moment a cursor moves. Probably in the Xserver itself.
best Vladimir Dergachev
> From the point of view of a benchmark you need to be very careful not > alter the task, as modern systems love to optimize. I will have to do some approximations using a combination of the processor and IMC counters.
