Shared atomic state causing Weston repaint failure

[Daniel Stone]

Hey Jakob,

On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz <jakob at 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