Introduction and updates from NVIDIA

[Daniel Vetter]

On Fri, Apr 29, 2016 at 02:16:28PM -0700, James Jones wrote:
> Streams could provide a way to express that the compositor picked the wrong
> plane, but they don't solve the optimal configuration problem. Configuration
> is a tricky mix of policy and capabilities that something like HWComposer or
> a wayland compositor with access to HW-specific knowledge needs to solve.  I
> agree with other statements here that encapsulating direct HW knowledge
> within individual Wayland compositors is probably not a great idea, but some
> separate standard or shared library taking input from hardware-specific
> modules and wrangling scene graphs is probably needed to get optimal
> behavior.
> 
> What streams do is allow allocating the most optimal set of buffers and
> using the most optimal method to present them possible given a
> configuration.  So, streams would kick in after the scene graph thing
> generated a config.

Daniel's reply cut out this crucial bit somehow, and he replied somewhere
else that he agrees that eglstreams solves at least the "optimal
allocation once scene graph is fixed" problem. I disagree since this
entire thing is highly dynamic - at least on SoC chips how you allocate
your buffers has big impacts on what the display engine can do, and the
other way round:
- depending upon tiling layout fifo space requirements change drastically,
  and going for the "optimal" tiling might push some other plane over the
  edge
- there's simpler stuff like some planes can only do some features like
  render compression, which is why even for a TEST_ONLY atomic commit you
  must supply all the buffers already
- other fun stuff happens around rotation/scaling/planar vs. single-plane
  yuv buffers. All these tend to need special hw resources, which means
  your choice in how to use it on the kms side has effects on what kind of
  buffer you need to allocate. And the other way round.

I don't think there's any way at all, at least for a generic system that
wants to support embedded/mobile SoCs to solve the kms config and buffer
alloc problems as 2 separate steps. You absolutely need these two pieces
to talk to each another, and talk the same language. Either some vendor
horror show (what most of android bsp end up doing behind the back) or
something standardized (what we're trying to pull off around kms+gbm).

Hiding half of the story behind eglstreams doesn't help anyone afaict. If
you do that, you also need to hide the other half. Which means proprietary
hw composer driver (or similar), which can understand/change the metadata
you internally attach to eglstreams/buffers. And once you've decided to go
the fully hidden route hw composer seems to be the best choice really.
SurfaceFlinger isn't really great for multi-screen, but the hwc interface
itself is already fixed and handles that properly. But even with hwc you
don't have eglstreams, because once both ends are proprietary there's
really no need for any standard any more ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch