Introduction and updates from NVIDIA

[Daniel Stone]

Hi,

On 28 March 2016 at 19:12, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Mar 24, 2016 at 10:06:04AM -0700, Andy Ritger wrote:
>> eglstreams or gbm or any other implementation aside, is it always _only_
>> the KMS driver that knows what the optimal configuration would be?
>> It seems like part of the decision could require knowledge of the graphics
>> hardware, which presumably the OpenGL/EGL driver is best positioned
>> to have.
>
> Android agrees with that and stuffs all these decisions into hwc. And I
> agree that there's cases with combinations of display block, 2d engined
> and 3d engine where that full-system overview is definitely necessary. But
> OpenGL still doesn't look like the right place to me. Something in-between
> everything else, like hwc+gralloc on android (which has its own issues)
> makes a lot more sense imo in a world where you can combine things widly.

Right. Samsung decided that answer was correct, and Tizen has the
Tizen Buffer Manager, which started off life as GBM with the copyright
notices filed off[0] and the addition of separate allocation
intended-use flags for 2D/blit and media decode engines. So for them,
GBM has mutated from the thing that knows about the intersection of
GPU + display, to the gralloc-like thing that can determine optimal
allocation strategies.

Unfortunately I don't expect to ever get meaningful input there, as I
only discovered its existence by semi-accident, back when you needed a
Tizen login to access it as well. It's only ever really been mentioned
in passing, and has no users outside Tizen (and I still don't know
what exactly uses their 'surface queue'). Oh well.

> I do believe though that with just kms + sensible heuristics to allocate
> surfaces to hw planes + some semi-clever fallback mechanism/hints (which
> is what we currently lack) it should be possible to pull something off
> without special-case vendor magic in hwc for every combination. That's
> purely a conjecture though on my part, otoh no one has ever really tried
> all that hard yet.

Another fun suggestion that came back would be feedback from the
atomic ioctl: when rejecting a configuration, optionally return a list
of property changes with which a future configuration would have a
larger chance of success (e.g. wider stride, different tiling mode).
Plumbing that back through to clients isn't without the realm of
reason, though would require more user-visible API. This is something
that would fit in quite nicely with the Weston atomic KMS
implementation, where we attempt to enlarge the configuration one
plane at a time: start with the primary plane, and attempt to place
every other scanout target on a plane, seeing at every turn if they
succeed or need to be punted down to GPU composition.

Cheers,
Daniel

[0]: tbm_bo_handle must be copied from gbm_bo_handle, beacuse to write
that even once makes no sense; to write it independently is so
improbable as to be impossible.
https://review.tizen.org/git/?p=platform/core/uifw/libtbm.git;a=blob;f=src/tbm_bufmgr.h;h=7bf2597f3fee53d3b00ca7ba760675c977ba4435;hb=ecc409c142cd77b1d92cb35f444099e2c782b6ad