[RFC] DRI3/PRESENT Add a way to select whether to use scanout or not depending on needs

davyaxel at free.fr davyaxel at free.fr
Mon Jun 6 22:27:59 UTC 2016


Hi,

Currently when a buffer is presented with the Present extension, in case it meets all the criterias to be used for a flip, the Xserver asks the DDX to check the pixmap can be used for a flip (check_flip), and if yes, X schedules a flip.

I guess *theoritically* (perhaps there may need a few patches for that) DDXs are supposed to refuse to flip for example if the format isn't compatible with the display format (non scanout vs scanout format).

If the driver uses scanout-able buffers, and the Xserver returns PresentCompleteModeCopy, then the driver can deduce it should be ok to reallocate its pixmaps and use ones without scanout formats, if better for efficiency or vram usage.
However in case the driver uses non-scanout-able buffers, there is no way (except trying scanout-able buffers sometimes) to guess the Xserver could do flips if only the buffers were of another format.


A similar but different issue also happen for DCC compression for radeon cards: In case of DCC, the memory for the buffer is allocated, but a compressed state of the buffer is contained in a separate buffer that some metadata describes (that the driver and ddx can read).

Currently the driver will always resolve such buffers before sending them to the Xserver, however ideally when not used for flips, it would be more efficient (performance and energy wise) to keep a compressed state.
The ddx (via glamor) is able to understand these buffers without issues.

Similarly there'd need some information to tell whether such compression can be used or not (which currently is equivalent to the case described above for scanout: if we could flips, do not use DCC to be able to do flips, else use DCC).
However the case is different, because one could argue that the DDX could resolve the buffer to allow the flip.
But performance-wise, decompression is heavy, and it would be better for the driver to know about flips, and in that case it wouldn't compress that buffer in the first place (thus no need for decompression).



Has anyone suggestions to allow these two use cases ?

My suggestion is to add to the Present extension a new COMPLETE event that would say 'we do copy, but all conditions to flip were met, except the fact that the ddx said it couldn't flip with that buffer'.

How would people go with this proposition ?

My view is that it would allow:
"Using scanout + receiving copy event -> use non scanout buffers instead"
"Using non scanout + receiving the new event -> use scanout buffers instead"

My hypothesis is also that for some reason during rendering, we could switch from 'flips can be used' to 'flips cannot be used' and vice-versa, for example if playing a game fullscreen, then alt-tabbing (while game still rendering to the same size in the background) and then switching back. Also when Wayland uses drm planes more, it may use this to hint apps going through XWayland use scanout-able buffers or not, so it's not just about fullscreen surfaces. I think the new event would allow to have things done properly (rather than relying on behaviours of configure notify events or whatever).

Thanks,

Axel Davy 


More information about the xorg-devel mailing list