FYI, We thought of moving all the format code to src/util to make it independent from everything else. (yeah that directory doesn't exist yet)
Marek On Wed, Jul 23, 2014 at 8:10 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > > > > On Wed, Jul 23, 2014 at 10:31 AM, Marek Olšák <mar...@gmail.com> wrote: >> >> On Fri, Jul 18, 2014 at 5:32 PM, Brian Paul <bri...@vmware.com> wrote: >> > On 07/17/2014 12:04 PM, Jason Ekstrand wrote: >> >> >> >> This is the first installment of some work I've been doing over the >> >> past >> >> couple of weeks to refactor mesa's texture conversion/storage code. >> >> There >> >> is more to be done and more that I have done but have not included in >> >> this >> >> series. This is the first mailing-list-ready fruits of my efforts. >> >> The >> >> important bits here include: >> >> >> >> 1) Using a human-readable CSV file to describe texture formats >> >> similar >> >> to >> >> the way it is currently don in gallium. This is much easier to >> >> read/edit than the structure in formats.c. The guts of formats.c >> >> is >> >> then autogenerated from this CSV file. >> > >> > >> > I'm kind of on the fence about this. Some of us have been hoping that >> > we'd >> > eventually consolidate some of the Mesa and gallium code so we wouldn't >> > have >> > duplicated/parallel code. The format code is a good example. In >> > theory, >> > the MESA_FORMAT_ stuff could be replaced by the gallium PIPE_FORMAT_ >> > code. >> >> I agree and I think this rework brings us closer to sharing the code, >> which is a good thing. In the meantime, it nicely cleans up the code. > > > In that vein, I've taken a slightly different tack that I think will make > the sharing easier. Right now, I'm working on moving a bunch of code into a > new static library called libformat that can be independently developed and > *tested*. One of the problems we had before was that the only > format-conversion testing we did was through piglit which can't actually hit > all of the code-paths. Hopefully, splitting it out will make it easier to > test and easier to combine efforts than gallium depending on mesa or the > other way around. > >> >> >> BTW, this series will conflict with the big endian work that Richard >> Sandiford is doing. > > > Yeah, I'm aware of that. > > --Jason Ekstrand > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
