Initial support for DRM async page flip

[PolyMeilex]

This allows users to select if frame should be presented with VSync or fully ASync.

~~blocked by: https://github.com/Smithay/drm-rs/pull/190 (awaiting releasse)~~ ~~blocked by: https://github.com/Smithay/gbm.rs/pull/40~~ related: #1325

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 21.23%. Comparing base (91e61f1) to head (a7e1c32). Report is 16 commits behind head on master.

Files	Patch %	Lines
src/backend/renderer/element/mod.rs	0.00%	15 Missing :warning:
src/backend/renderer/element/surface.rs	0.00%	5 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1335      +/-   ##
==========================================
- Coverage   21.32%   21.23%   -0.09%     
==========================================
  Files         156      156              
  Lines       25121    25042      -79     
==========================================
- Hits         5356     5317      -39     
+ Misses      19765    19725      -40     

Flag	Coverage Δ
wlcs-buffer	18.37% <0.00%> (-0.05%)	:arrow_down:
wlcs-core	18.03% <0.00%> (-0.07%)	:arrow_down:
wlcs-output	7.78% <0.00%> (+0.02%)	:arrow_up:
wlcs-pointer-input	20.05% <0.00%> (-0.13%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[nferhat]

~~Well I'm no Smithay maintainer but still curious whether this will help with integrating tearing-control-v1 or not? Because it seems quite promising!~~

It actually does.

[PolyMeilex]

~~Well I'm no Smithay maintainer but still curious whether this will help with integrating tearing-control-v1 or not? Because it seems quite promising!~~

It actually does.

Yep, it's more or less the only use-case for this.

[PolyMeilex]

Ok, I belive this is ready.

Although I still can't test the atomic path, even tho my driver started to report AtomicASyncPageFlip as supported recently, any attempt to page flip results in Invalid argument (os error 22) (perhaps it's a code issue so any testing with presentation mode flipped to Async would be welcome, just flip VSync to Async in anvil's udev.rs)

Running with SMITHAY_USE_LEGACY=1 on the other hand works flawlesly for me already (if one can use flawless to describe tearing :smile:).

[cmeissl]

Okay, so this is not going to work this way unfortunately. Async page flips have some special limitations we need to account for. For an async page flip to succeed the atomic commit is only allowed to change the framebuffer on the primary plane. Every other change will result in the page flip request to be declined.

This unfortunately also includes IN_FENCE_FD required for explicit sync. But this is something that is being worked on, so imo we should not special case this and just wait for it to land. Currently we do not support explicit sync for direct scan-out anyway.

Not sure what to do about FB_DAMAGE_CLIPS, need to check what the plan for this is. (worst case is we disable it for async page flips).

There are also driver specific limitations like for example intel not supporting async page flips if the plane uses some compressed tiling format.

So imo the most sane way to handle this is to do best guessing in render_frame if an async page flip might work. Then in queue_frame do trail and error with a retry without async flip and remember that it failed for this frame state. render_frame would then use the state as a feedback loop to prevent endless retries. The failed state should reset in case the format or other stuff changes allowing to re-test.

I prototyped some parts of this and will post a patch when its ready.

[cmeissl]

Okay, I put something together that should work (at least it seems to work on my system). https://github.com/cmeissl/smithay/commits/drm_async_page_flip/ (@PolyMeilex PR branch rebased on top of current master + some small fixes)

Curious if this also works on AMD and Nvidia now @PolyMeilex @YaLTeR @Drakulix Filtering for linear formats is probably not going to work on Nvidia and probably also not needed. Intel also does support async page flips with some modifiers (probably only compressed one are not supported, which kind of makes sense), but I was too lazy to put together a list of working formats.

[PolyMeilex]

@cmeissl Atomic backend now works on my AMD systems, looks promising.

Rebased on master, and cherrypicked the cmeissl's commit (with some minnor reverts of debug code edits)

[PolyMeilex]

Confits resolved, everything seems to still work as expected on my AMD machines both with atomic and legacy

[Drakulix]

Feedback from the display next hackfest:

• IN_FENCE_FD will be added as a supported property in some future kernel
• FB_DAMAGE_CLIPS is unclear, but amd/intel are aware that their current set of properties is too restrictive
• There was a proposal to have an additional IN_FORMATS_ASYNC (or similarly named) property to solve the format issue.
• Other compositors currently seem to just fall back to non-tearing presentation, when the format doesn't work out or default to the legacy api. Just using linear was deemed to potentially have performance issues...