On Thu, Jan 12, 2017 at 07:27:03PM +0000, Daniel Stone wrote:
> Hi,
>
> On 12 January 2017 at 18:11, Ville Syrjälä
> <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> > On Thu, Jan 12, 2017 at 05:50:15PM +0000, Daniel Stone wrote:
> >> 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.
>
> It would make sense, but then gbm_surface_create_with_modifiers takes
> a fixed pixel format and a list of acceptable modifiers (which to me
> seems like the right way around as an API), so whenever I was creating
> a surface, I'd have to walk through and create a new list, flipped
> back the other way.
Yeah, for that your original order makes more sense, even if it
potentially uses more memory.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
