Hello,
I'm trying to understand why our application does not play well with the i915 driver. We're trying to drive a 4k/60Hz display using an OpenGL ES application, the GL context being derived directly from the DRM device. Depending on the GPU load we generate, we quite frequently manage to get stuck with an GPU clocked just a smidge too low to actually hit the 60Hz target.
E.g. right now I'm looking at less than ideal animations because the time to complete a frame is 17.1ms, causing every other vsync to be missed. This is while the GPU, according to intel_gpu_top, is 50.4% busy with rendering and the video decoder is at 6.7%. I'm pretty sure there is room for improvement because decoding a higher bitrate video *will* cause the GPU to clock up, then hitting the 60Hz no problem.
While investigating this I discovered the concept of "wait boost", although I'm not really sure what triggers it. To my understanding there are two ways to benefit from it:
* calling glFinish() (gave it a try, makes no difference) * tying the render job to a pending vsync event using an IN_FENCE_FD, we do that but it does not help either
Manual intervention using /sys/class/drm/card0/gt_min_freq_mhz is not very effective either, causing the long-time average clocks jump to 501 MHz, up from 495 MHz. Those extra 6 MHz really don't cut it. The reported maximum is 900 MHz, which was also written to gt_min_freq_mhz.
The output of /sys/kernel/debug/dri/0/i915_rps_boost_info alternates between two states:
RPS enabled? yes RPS active? no GPU busy? no Boosts outstanding? 0 Interactive? 2 Frequency requested 867, actual 300 min hard:300, soft:900; max soft:900, hard:900 idle:300, efficient:300, boost:900 Wait boosts: 0
and
RPS enabled? yes RPS active? yes GPU busy? yes Boosts outstanding? 0 Interactive? 2 Frequency requested 900, actual 900 min hard:300, soft:900; max soft:900, hard:900 idle:300, efficient:300, boost:900 Wait boosts: 0
This is on Linux 5.17.5 with Mesa 22.0.2, but we're seeing this problem since at least two years so the exact version seems not to matter very much. It may be worth to mention that this behavior can be reproduced using the Weston Wayland compositor, and according the some mailing list there are Kodi users suffering from this too.
I'm really out of ideas here, is there anything obvious wrong with our approach?
Kind regards, -Matthias