Tl;dr; as ChromeOS uses window focus status (background/foreground) to on-the-fly re-configure the CPU controller for the cgroup where ARC lives (and other VMs), I am trying to sketch out the same approach for GPU scheduling.
It would be the same semantics as the CPU controller, albeit a bit less strict in what can achieve. Despite that, with the i915 driver I can show that putting a GPU demanding ARC container in the background could significantly reduce the impact on the foreground rendering. Which should improve UI/graphics latency for the foreground window. For instance glxgears running un-vsynced and unfettered, in parallel to a 60fps workload:
474 frames in 5.0 seconds = 94.779 FPS
519 frames in 5.0 seconds = 103.740 FPS
518 frames in 5.0 seconds = 103.338 FPS
469 frames in 5.0 seconds = 93.788 FPS
482 frames in 5.0 seconds = 96.311 FPS
Versus same glxgears instance getting de-prioritized on the GPU after exceeding its GPU share, once its cgroup weight gets decreased:
369 frames in 5.0 seconds = 73.444 FPS
373 frames in 5.0 seconds = 74.434 FPS
389 frames in 5.0 seconds = 77.794 FPS
357 frames in 5.0 seconds = 71.393 FPS
308 frames in 5.0 seconds = 61.414 FPS
So far I've been sketching this out on Linux, but now I am moving into wiring up a ChromeOS prototype.
Controller is also designed in a way that any DRM driver which can query GPU utilisation and have some sort of scheduling priority control could implement the same approach.
I would be keen to know if ChromeOS would be interested in such capability.