XDC allocator workshop and Wayland dmabuf hints
Pekka Paalanen
ppaalanen at gmail.com
Thu Oct 17 09:09:44 UTC 2019
On Mon, 14 Oct 2019 06:02:59 -0700
James Jones <jajones at nvidia.com> wrote:
> On 10/13/19 2:05 PM, Scott Anderson wrote:
> > (Sorry to CCs for spam, I made an error in my first posting)
> >
> > Hi,
> >
> > There were certainly some interesting changes discussed at the allocator
> > workshop during XDC this year, and I'd like to just summarise my
> > thoughts on it and make sure everybody is on the same page.
Hi Scott and James,
thanks for the write-up, it all sounds good to me FWI'mW.
> -As you note, this limits things to formats/layouts that can be
> composited (basically, things that can be textures). "Things that can
> be textures" is a superset of "Things that can be scanned out" for these
> purposes on our HW, so that's fine for NVIDIA. Does that hold up
> elsewhere? A secondary motivation for me was that the compositor could
> transition back to compositing from overlay compositing without
> requiring a blit or a new frame from the client in cases where that
> didn't hold up, but I don't know if that's interesting or not.
It is interesting.
The compositor transitioning back from overlay to compositing without
requiring a new frame from the client is a minimum requirement under
normal circumstances in Wayland architecture. If a compositor cannot do
that because of a buffer format, how could a conversion blit be
possible either?
In Wayland architecture, having the compositor (display server) wait
for any client before it is able to update the screen is unacceptable
because it has a high risk of disturbing visual glitches.
OTOH, I have heard of special use cases, where all buffers should
always go on overlays and falling back to composition would be
considered a bug. For such cases, there are some ideas towards that at
https://gitlab.freedesktop.org/wayland/weston/issues/244 .
Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20191017/0b2d1cf1/attachment.sig>
More information about the dri-devel
mailing list