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

[Michel Dänzer]

On 07.06.2016 07:27, davyaxel at free.fr wrote:
> 
> 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 ?

One problem with this is that the DDX driver could refuse to flip for
other reasons, in which case the client side Present code could end up
flip-flopping between scanout/DCC enabled/disabled.

Instead, I'd propose adding an event which means something along the
lines of "you can try using buffers suitable for flipping now".


> 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.

Ignoring Wayland for a moment, unless I'm missing something, at least
one of two things always happens when a window becomes suitable for
flipping:

1. The window geometry changes
2. The window is unredirected

The new event could be sent on these two circumstances.


> 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.

Xwayland could similarly send the new event at appropriate times.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer