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
