search

misyltoad / frog-protocols

Other
395 stars 5 forks source link

FIFO in mutter #8

Closed swick closed 1 week ago

swick commented 1 week ago

Hey, just wanted to let you know that I also got frustrated with how things are going with the upstream fifo protocol and that feedback given by a bunch of folks about requiring a fallback on the client side has been ignored. Some days before you published this repo I went ahead and prototyped a version which has the fallback on the compositor side.

There are now two MRs for mutter. One implementing the upstream fifo protocol from Derek (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355) and the modified version from me (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4051). There is disagreement on how to proceed but I hope that having implementations of both approaches will be valuable for that. I also don't believe that frog-protocols is necessary for this kind of experimentation and that we can make upstream a better place for that.

I only dropped the part about being allowed to ignore the fifo barrier in certain cases (other than synchronized subsurfaces) from the upsteam fifo protocol so I believe this is compatible with the frog-fifo version.

Would be nice if we can show that this is not just viable but actually the better path forward for everyone.

(Feel free to close this issue, it's mostly just a comment)

misyltoad commented 1 week ago

Yes, we also modified that and made it implementation defined with a forward progress guarantee.

I agree with this from a Gamescope perspective, and I think @Zamundaaa was arguing that too. The compositor is usually the best arbiter.

Closing as this was just a comment.