On Thu, Jan 12, 2017 at 05:04:46PM +0000, Daniel Stone wrote: > Hi, > > On 12 January 2017 at 14:56, Rob Clark <robdclark@xxxxxxxxx> wrote: > > On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä > > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> Isn't an implicit offset enough? As in first mask for a specific > >> modifier is for format indexes 0-63, second mask for the same modifier > >> is for 64-127, and so on. > > > > hmm, hadn't thought of that approach. Definitely if we go w/ implicit > > then we want to have userspace support from the get-go. For explicit, > > I guess userspace could complain and ignore if it saw a non-zero > > offset similar to what we do w/ pad and unknown flags in the other > > direction? > > 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. 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 :) -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
