XDC allocator workshop and Wayland dmabuf hints

[Carsten Haitzler (The Rasterman)]

On Thu, 17 Oct 2019 12:09:44 +0300 Pekka Paalanen <ppaalanen at gmail.com> said:

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

Or it has the result of a single non-responsive client holding the compositor
hostage, unable to update the screen until that client responds. This also
would be unacceptable.

This requires there be a hardware accelerated conversion "blitter" somewhere
that is able to convert between such displayable and non displayable formats,
and/or that all such formats be clearly specified and documented and such
conversions need to be done on the CPU as a fallback.

Unless of course we're dealing with the kinds of content that are "secure" or
"encrypted" etc. with some kind of DRM (digital rights management) scheme in
place where the whole point is to have that buffer only ever displayable as a
hardware plane. In these cases The compositor can replace such buffers with a
picture of a horse to indicate that that buffer is not intended to be visible
when it has to fall back to a composited path, but it needs to know that this is
intended vs. a bug.

> 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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com