Re: [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Ben Widawsky <ben@bwidawsk.net>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2
Date: Thu, 12 Jan 2017 20:11:28 +0200	[thread overview]
Message-ID: <20170112181128.GB31595@intel.com> (raw)
In-Reply-To: <CAPj87rN5Dre4S5giyEQWak9YC-oU=RkyFGTnGA10ubPjoX55Dw@mail.gmail.com>

On Thu, Jan 12, 2017 at 05:50:15PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 12 January 2017 at 17:45, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Thu, Jan 12, 2017 at 05:04:46PM +0000, Daniel Stone wrote:
> >> Implicit is clever but horrible. AFAICT, the only way to do it
> >> properly would be to have a nested forwards loop walk when you first
> >> hit a modifier, searching for further occurrences of that modifier to
> >> collect the complete set of formats that modifier applies to.
> >
> > Not sure for what that is the "only way". In fact I can't right now
> > think of any operation that would require an extra loop necessarily.
> > For some things you might just want to look for a specific
> > format+modifier combo, for that it doesn't matter how many blocks there
> > are.
> 
> Right, that just needs a local variable to act as a counter.
> 
> > And if you want to transform the reply into some less convoluted
> > form, well then you'd just need some modifier+dynamic format list thing,
> > or if you want to keep to bitmasks you'd either need a bitmask that can
> > grow when running out of bits or just make it big enough to handle a
> > sufficiently large worst case number of bits.
> >
> > Dunno, maybe I just lack imagination. Then again, I'm not even sure if
> > we're talking about userspace of kernel code here, which might explain
> > my general confusion :)
> 
> I'm talking about userspace, where I want to have:
> struct drm_plane {
>     struct {
>         uint32_t format;
>         uint64_t modifiers[];
>     } formats[];
> }

Flipping formats[] vs. modifiers[] here would seem like it should make
this easier with the proposed kernel API. And if the kernel will also
uarantee that multiple instances of the same modifier must be returned
contiguously, then it should be even easier.

Oh and flipping formats[] and modifiers[] should also save a quite a
bit of space since each format takes twice as much space as each
modifier. But I suppose that might come at a runtime cost if you have
to look for a specific format in each modifier's format list instead
of having to look at just the modifier list of a specific format. So
I suppose not flipping might be better after all, which I guess would
complicate populating the infromation somewhat.

Anyways, that's all a bit unrelated to the matter at hand, so I'll stop
now and just state that I don't mind having an explicit offset if
people really want it.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx