Hey Jakob, On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz <jakob@xxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
