On 2018-02-28 12:53:01, Francisco Jerez wrote: > Jordan Justen <jordan.l.jus...@intel.com> writes: > > > On 2018-02-28 01:58:24, Samuel Iglesias Gonsálvez wrote: > >> What is the idea for src/intel/dev/ ? > >> > >> I'm not against this patch, just asking. > > > > Ken noticed a lot of duplicate lines in the xml for surface formats. > > (Patch 4). But, then we noticed that removing them makes aubinator > > fail to nicely print out the surface format name. > > > > Isn't it a bit of a misfeature for the surface formats not to be > represented in the XML anymore? Why should one need to depend on isl in > order to decode a batchbuffer?
I think we've sort of decided to make isl the focus for surface related info. It is also a lot of duplicated entries in the xml. (See patch 4) > > I thought maybe we could have isl help get the format name, but then > > Jason pointed out that isl depends on intel/common (for device info), > > so we couldn't make the decoder code in intel/common depend on isl. > > > > Did you consider splitting off the decoder code from common if it really > needs to depend on isl? I think we should try to keep isl having minimal dependencies. Rather than isl depending on the common/kitchen-sink library, which is likely to continue growing in scope, I thought it would be better to split out the small item that it depends on. I am also considering adding something else to intel/common in the future, but that item would depend on isl, so once again raising the issue. -Jordan > > > My idea is to split out the device info so isl wouldn't have to depend > > on intel/common, and now it will depend on the newer intel/dev device > > info lib. This should allow the decoder in intel/common to use isl, > > and then we can remove the genxml duplication. > > > > -Jordan _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
