On Fri, Dec 12, 2014 at 10:56:21AM -0500, Rob Clark wrote: > On Fri, Dec 12, 2014 at 10:11 AM, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > Hi, > > > > On 12 December 2014 at 14:56, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > wrote: > >> > >> On Fri, Dec 12, 2014 at 08:50:18AM -0500, Rob Clark wrote: > >> > >> > It does make me briefly think of just letting us set properties on fb > >> > >> > objects :-P (but maybe that is a bit overkill) > >> > >> Yeah I had the same idea at some point. But then I decided that we could > >> just have these as properties on the plane. > > > > > > Mm, it does seem a bit weird. Yes, they are relative to how the plane > > interprets things, but then again so is the format surely. Not to mention > > another thing to go wrong, if someone forgets to set and/or clear it when > > changing the plane. Keeping it in the fb eliminates that possibility. > > > > yeah.. logically it seems nicer for them to be prop's on fb's. The > drawback is having to invent some bit of infrastructure to support > that. Avoidance of inheriting someone else's plane prop's might be > enough justification to invent that infrastructure. But fb prop's > don't really help w/ the whole not-all-planes-are-the-same thing.. The nice thing with fbs currently is that all the metadata is invariant. Imo we should keep that for any prop extension, since it massively simplifies things for everyone. But I'm not sure that's so important since we already have (and probably always will have) a mess between plane and fb props. E.g. the rotation thing actually affects the pte ordering on skl. So would be nice to have as an invariant fb prop, but since it's now on the plane we can't change it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
