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