[Mesa-dev] [PATCH 00/12] Rework texture upload code

[Marek Olšák]

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 <jason at jlekstrand.net> wrote:
>
>
>
> On Wed, Jul 23, 2014 at 10:31 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>
>> On Fri, Jul 18, 2014 at 5:32 PM, Brian Paul <brianp at 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
>