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

[Ben Widawsky]

On 17-05-03 18:30:07, Liviu Dudau wrote:
>On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote:
>> 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 ...).
>
><tongue_in_cheek>
>Don't know about open _mail_ drivers but there are plenty of open mail apps that one can use
></tongue_in_cheek>
>
>Joke aside, the Mali GPU *kernel* driver *is* open source. Just not in the mainline and
>not enough for what you want. But I'm not the right person to fix all that.
>
>And GPU is not the only IP capable of producing AFBC data, so there might be another driver
>in the making that will be open source.
>
>Best regards,
>Liviu
>
>> But besides that, it works
>> perfectly fine for arm render compression format too.
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>
>-- 

So are we good with patch 1, sorry if I missed any real valid changes I need to
make, but can we please capture that here.

-- 
Ben Widawsky, Intel Open Source Technology Center