Hi Emre, On Thu, 26 Jul 2018 at 14:54, Ucan, Emre (ADITG/ESB) <[email protected]> wrote: > We are currently querying supported modifiers only from gpu drivers via > EGL_EXT_image_dma_buf_modifiers extension. > But we should also query and advertise modifiers which are supported by DRM > device. We are already getting this information via IN_FORMATS of a drm plane. > > IMO, it is not enough to just query and advertise every supported format and > modifiers combination to applications. > Applications can easily choose a format, which is only supported by GPU > device and not DRM device. In the end, this would force us to use gpu for > composition. > We should mark modifiers of DRM device as preferred ones. This would require > modifying linux-dmabuf protocol.
I agree; I've had the same thought. I think we want to do something more nuanced than this though. Say for example the display controller only supports linear formats. Doing a clear intersection would mean all clients rendering to linear at a performance loss, even if they are not candidates for display scanout. What we would want is a more dynamic hint from the compositor: to tell clients to prefer scanout-compatible formats where they are useful, but else to just pick the best GPU format. I think the best thing to do would be to make a new dmabuf interface which takes a surface as a creation parameter, where the compositor would update the per-surface interface with preferred modifiers. Since we don't know preference order between modifiers, rather than enforcing any order, the best thing to do would be to break it into tranches: send one set of modifiers which are both GPU + scanout compatible and ask the client to preferentially allocate from that set, then send a second GPU-only set which the client may fall back to if it cannot render to the first set. I don't have plans to work on that right now - I'd happily review any patches or have a more detailed discussion though! - but as part of the debug work I sent out last week, I am planning to expose the current scanout status of surfaces to the core compositor. For example, 'is on a plane now', vs. 'can never be on a plane because of compositor configuration (transform/alpha/etc)' vs. 'could maybe be on a plane but is not allowed (couldn't find suitable plane, kernel rejected, etc)' vs. 'could be on a plane but client needs to change (modifiers, transform, etc)'. That should be quite useful for this work as well. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
