Hey Jakob,
On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz jakob@collabora.com wrote:
So from a VR compositor getting blocked like this is a no-go as the user would quickly throw EPUKE. The situation is compounded by the fact that the VR compositor has no idea what the display compositor is doing with regards to setting modes so can not do any mitigating on its side (like displaying a black screen).
Yeah, definitely.
Some solutions that springs to mind (some I admit are probably not possible).
- Make sure we don't get into this situation by locking the resources
of the VR crtc group or allocating enough bandwidth for the display compositor crtcs up front.
- Add priority and preemption to atomic so that VR compositor can
never be blocked.
- Add X/Wayland protocol for the compositor to tell the VR compositor
that a modeset might effect it, so it can display a black-screen during that time.
- Make it possible for the VR compositor to tell the kernel what it
should do this case, like show black if I happen to get block before I can queue a new pageflip.
The specific issue on Intel is that they have a shared FIFO setup, and that enabling/reconfiguring a new CRTC requires FIFO reconfiguration, which in turn requires a global stall, even if you're not touching any leased resources directly. So there's no way to avoid the resources, or get around it with priorities.
Ultimately I think we're going to need a general protocol to deal with this though. I can think of other situations - say, DDR reclocking, where the reclocking isn't voluntary but forced by platform thermals - where you might need to sit out a frame or two due to external factors.
Cheers, Daniel