Hi,
On 27/01/2016 13:43, Daniel Stone wrote:
Hi,
On 27 January 2016 at 09:34, Michel Dänzer <[email protected]> wrote:
The compositor may have the hardware scan out directly from the buffers
sent by the client, so we must make sure the buffers we create are
suitable for scanout.
If the compositor wants to scan out directly, it will import via GBM,
which is in a position to reject the import if the buffer is not
suitable for scanout. So there's something missing here, either in the
GBM implementation to set magic flags when importing, or failure to
communicate tiling mode correctly, or whatever.
So for now, I would NAK this and fix the underlying problem, before
forcing every client buffer to be scanout-capable, which can cause
performance issues of its own. This also introduces a
resource-contention issue (e.g. if the display controller can only
scan out from physically-contiguous memory); you'll cause all client
buffer allocations to fail unless it can allocate a potentially
contended resource.
Please fix the radeonsi/Gallium implementations of GBM and/or wl_drm
to deal with tiling/compression correctly instead.
Cheers,
Daniel
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Scanout buffers are already used for DRI2 and DRI3 by default (for Mesa
drivers),
and it looks like a sane default behaviour given there is no current
way to know if the compositor would like to use the buffer as scanout
or not.
As long as the app has no way to know what the compositor wants (there
was talks I remember on irc on ways to do that), I think enforcing scanout
as default is sane.
The other thing you mention, ie failing to import non-scanout buffers
when scanout is requested is, I believe,
unrelated to this patch, and would require a bit more work. In
particular this is handled by a function validateUsage,
which doesn't seem to be fully implemented on gallium. I suggest to file
a bug on bugzillla.
Yours,
Axel
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
