[RFC] drm: Introduce max width and height properties for planes

[Daniel Vetter]

On Wed, May 25, 2016 at 7:57 PM, Rob Clark <robdclark at gmail.com> wrote:
>> As far as virtualizing the resources goes. I think that would need a
>> whole new API. Or at least a separate set of objects perhaps. I'm too
>> lazy to dig up all the old arguments now, but I'm pretty sure there
>> were many. If this would be done, I suspect the only sane way to do it
>> would be to just have a hwc implementation in the kernel. As in user
>> space would pass in the desired configuration, and the kernel would
>> assign resources as best it can and return the result back to userspace.
>
> actually, without introducing a completely new/different uapi, it
> should work pretty reasonably with the way weston atomic works,
> incrementally adding planes in TESTONLY steps until it fails.  I
> suspect on some more creative hw (msm is prime candidate) we'll still
> see custom hwc implementations to squeeze out the last bit of
> performance/power.  But with the approach that weston uses a generic
> userspace should still work pretty well on that hw.

So summary from my points on the m-l:
- Whether we do this in all drivers that need this for dual-pipe 4k,
or in all compositors is probably similar amounts of work. The upside
of doing it in drivers is that it's closer to the metal, avoid
midlayer-like mistakes in trying to funnel tons of stuff between the
top and bottom layers through drm core, and still failing in corner
cases. Drivers can simply fix things up if they're in control.

- For a bunch of reasons we (well Ville is really big on those) want
to add clipped_src/dst rectangles to drm_plane_state. That's a bit of
churn, but it's per-driver opt-in churn, so manageable. Once we have
clipped rectangles and so fully decoupled the hw state from the uabi
state it's easy to clip a plane to a sub-pipe instead of the entire
virtual area of the crtc.

- Once we can clip planes we can add a bit of helper magic to steal
additional&unused planes for use as the 2nd/3rd/4th plane scanning out
one logical surface (drm_buffer) attached to a logical plane
(drm_plane). Add a helper on top which splits a 4/5k screen at a
passed in limit, and this boils down to a few lines in drivers. While
still giving the drivers full control over all the details, if they
want to.

- Really assigning resources within the driver while exposing whether
there's enough to userspace using TEST_ONLY is the point of atomic.
Doesn't matter whether it's fifo space, scalers, wizzbang gizmo A, B
or C or this thing called "scanout engine". If your hw needs more than
one of those to get a basic job done (fullscreen primary plane) then
it's imo the drivers job to juggle all the internal resources around.
KMS is supposed to work from workstation gpus down to soc in a
somewhat uniform way, even on crappy hw.

Summary: Still firmly in the "virtualize it!" camp ;-)

Cheers, Daniel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch