> > > + * Users see modifiers as opaque tokens they can check for equality and > > > + * intersect. Users musn't need to know to reason about the modifier value > > > + * (i.e. users are not expected to extract information out of the modifier). > > > + * > > Doesn't this conflict with "implicit minimal requirements" above? Ah, when I wrote "users", I meant "non-driver users": programs like compositors and user-space applications. Of course kernel and user-space drivers can extract information out of the modifiers. Is this why there's some confusion here? > Certainly for a bunch of different AFBC modifiers, the allocator would > need to understand some fields in order to properly align-up the > buffer size. It's probably a little early to speculate on the future allocator design. For instance, instead of having a monolithic allocator, the kernel driver (and other buffer consumers) could advertise a list of constraints for each format/modifier. That way no-one would need to extract information out of modifiers to figure out alignment (but maybe drivers would still want to, to reject bad imports for instance). But again, I'm just throwing ideas around at this point. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
