mpsq / arewewaylandyet

Sources for https://arewewaylandyet.com
https://arewewaylandyet.com
MIT License
280 stars 62 forks source link

synchronization model design flaw #169

Open matu3ba opened 1 year ago

matu3ba commented 1 year ago

Stolen from reddit https://www.reddit.com/r/linux/comments/wwsiaf/comment/ilosxsf/?utm_source=share&utm_medium=web2x&context=3:

synchronization model

This one is a bit more obscure, but Wayland's synchronization is outdated as well. In fairness, they started in 2008 so this wasn't clear then, but modern graphics developers all agree that explict synchronization (like Vulkan or Direct3D 12) is the correct way to go. Wayland and Xorg are both implicitly synchronized which essentially means that they depend on APIs executing in a specific certain order (e.g. in Wayland a client renders, sends a surface commit, then after that the compositor does its thing). This scales poorly as clients become more complicated with rendering and leads to a ton of over-synchronization. The correct fix is to use explict synchronization. All the commands are executed as asynchronously as possible with synchronization only happening when strictly necessary. The kernel graphics substack is still playing catch up on this as well, but Android moved SurfaceFlinger to explict synchronization a couple of years ago. Xorg's present extension allows waiting on a CPU fence which is OK but hardly there. For Wayland, is an explicit synchronization protocol that nobody on the Linux desktop actually uses (it's for ChromeOS when it interfaces with Android applications under Wayland) which has some limited support. A correct windowing system needs to be designed from the ground up to support this. Basically like what Android did.