[Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Daniel Vetter]

On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote:
> On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau at arm.com> wrote:
> > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> > >> It does deserve a much better commit message than what it has, but as
> > >> he is on holiday for the rest of the week, I can answer. Currently, we
> > >> advertise which formats each plane is capable of displaying. In order
> > >> for userspace to be able to allocate tiled/compressed buffers for
> > >> scanout, we want userspace to be able to discover which modifiers each
> > >> plane supports as well.
> > >
> > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers.
> > > What I don't understand is the current aproach (but I've found from Brian that somehow
> > > I've missed the long discussion(s) around the subject). I was hoping to learn
> > > from the commit message why he thinks the introduction of this code is the right
> > > way of doing it. And the IRC logs seem to imply that he is mostly doing something
> > > that others have agreed upon and he doesn't really care about the approach as long
> > > as it ticks the "supported by intel driver" box.
> > 
> > Or, with another interpretation, he thinks the various approaches of
> > doing it are all equally good. He took guidance from a couple of
> > userspace developers (Weston, ChromeOS), a Freedreno developer and
> > also I believe an AFBC developer, to end up where he is now, which he
> > still thinks is fine. In doing so, he's been through several
> > iterations, always modifying the driver to suit. I think that's a
> > pretty good way to do development of new uABI, if you ask me. (And
> > again, I have trouble reading your last sentence as anything other
> > than hostile.)
> 
> I am getting the message. You think I am too strong here, so I'm going to back off.
> Also look forward to see the next version where he takes into account the technical
> comments that I have sent.

Just to make it really clear: Google has an implementation for AFBC using
exactly this scheme for cros. The only reasons it's not floating around
here in upstream is that one of the critical pieces is missing (*hint*,
*hint* you really want an open mail driver ...). But besides that, it works
perfectly fine for arm render compression format too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch