On 18/11/14 17:10, Jason Ekstrand wrote:
Jose,
I haven't had time to fully review Iago and Samuel's code, so I can't
100% comment on it right now.  However, let me make a few comments on
the "overarching plan" as it were.

On Tue, Nov 18, 2014 at 2:36 AM, Jose Fonseca <jfons...@vmware.com
<mailto:jfons...@vmware.com>> wrote:

    > The idea is that we have a lot of format conversion code scattered through
    > different files in the repository, a lot of that is redundant / 
duplicated,
    > so this intends to address that issue.

    First, I think this is a great goal.  And while I haven't reviewed
    them in detail, just from skimming through them, these patch series
    seem to be a great cleanup and a lot of work went into it.  I
    certainly don't object to any of this.



    But I have to say I find a bit unfortunate that so much effort is
    being put on implementing something specific to Mesa formats instead
    of taking this opportunity to devise a solution that would work both
    for gallium and Mesa formats.


That is the end goal.  Unfortunately, getting there requires a lot of
work.  Probably more work on the mesa side than on the gallium side.  A
big part of the problem was that there was a lot of code for format
conversion and it was scattered all over mesa/main directory.  A lot of
stuff needs to be cleaned up an unified inside mesa/main before things
can be unified with gallium.  Much of that work is now done.
>
One of the things that I would like to see happen after this stuff lands
is to convert the mesa pack/unpack functions to take a width, height,
and stride.  Then they would have exactly the same function signature as
the gallium conversion functions and merging will be much easier.  Then
we can work on moving the format handling code into a helper library
which, for the moment, I'll call libmesaformat.  Then both gallium and
mesa classic can pull from libmesaformat and we can kill all of the
redundant code.  Whose autogenerator framework we end up keeping is kind
of immaterial, they're not that hard to write.

Oh, got it now. Sounds great then.

One of the decisions that has to be made there (probably a topic for
another thread) is how we would want to structure the format metadata.
Mesa and gallium both have completely different ways of structuring it
and we need to unify that if we're going to unify the conversion code.
Personally, I think gallium's is cleaner and more expressive, but it
lacks the GL information that core mesa needs.  But, like I said, that's
a topic for another thread.

    Furthermore I see there is some interest speeding mesa using SSE2
    intrinsics, and of course format conversion is precisely one of the
    code paths that can great benefit from SIMD, but I have no doubt:
    the most efficient and sane way of leveraging SIMD with all these
    formats conversion is to JIT compile format conversion code tailored
    to the CPU in runtime.  There are just too many CPU variations to
    statically generate C code for every one of them.  And lot of the
    code to do this already exists in src/gallium/auxiliary/gallivm.  We
    should consider using it from src/mesa/*.


Yes, there were some patches.  However, given my experiments in the
past, I'm skeptical as to how much of a real benefit it would be to
SSE-accelerate all the format conversion.  When I did my first major
rework a couple of months ago, I experimented with using the SSSE3
shuffle operation for doing swizzling of the C implementation.  The net
result of that experiment is that using SSSE3 had a very marginal
benefit over a good C implementation such as the one we now have.  The
real problem we had was that the current format conversion stuff was
doing the pessimal thing in a lot of cases;  a lot of that stupid is now
gone.  So, if someone wants to work on that, I'm curious to see their
results, but I'm not holding out for it.

As far as doing a JIT compile, I've thought of it.  Daniel Stone
recently mentioned the idea of using ORC for doing things like this and
it might be a good fit.

I never heard of ORC, and I didn't get any relevant hits from google. What is it?

However, be fore we can do that, we need a
framework for these things (which we now have, thanks to this series).
How is that done in gallivm?  Is it done using LLVM?  If so, it might be
a non-starter.  I don't want to rekindle any debates, but you're going
to have trouble convincing some people that format conversion is a good
enough reason for a hard dependency on LLVM.

Yes, it's done with LLVM.

But note that when using LLVM as a JIT for CPU the we practically only use the LLVM C API, whose ABI is stable across any LLVM version. (We use a bit of C++ in gallivm/llvmpipe just for a few minor omissions of the LLVM C API but that's something we can and should fix. Just a matter of upstreaming that functionality.)

In other words, I'm not aware of any technical/logistic argument against using LLVM C API as a CPU JIT. (Using LLVM for GPU backend and/or optimization is a different story, as that can only be done via LLVM C++ interfaces which are not stable.)

Anyway, I admit that having a solid C implementation of these things is way more important than a JIT one.


Another idea that has been put forward would be to, whenever possible,
push the unconverted data to the GPU as a linear texture and use the GPU
to do the format conversion.  This would quite possibly be better than
either a straight CPU path or an optimized JIT'ed path.

Yes, good point. Specially if the pixels are not in user memory but already in PBO. If they are in user memory the conversion cost might be partially hidden with the copy to GPU accessible memory.

    This gallium helper code was written outside mesa to avoid the GL
    dependency (there was one point some of this stuff had to run in XP
    kernel mode! thankfully not anymore), and because when gallium was
    written the idea was that all Mesa drivers would eventually migrate
    into it.  Alas, that didn't happen, and might never happen.  That's
    OK.  But in that case, I do believe we should find a way of sharing
    more of the stuff in src/gallium/auxiliary with all Mesa drivers,
    non-gallium classic drivers included.


    In particular, we really should have a format conversion module that
    is capable of handling a superset of all Mesa and Gallium formats
    somwhere in src/util/  .  One might even leverage the auto-generated
    pack/unpack functions in src/gallium/auxiliary/u_format* though I
    wouldn't care if not, as long as the functionality is the same.


Absolutely!  That's 100% the end goal here.  One of the additions of
this series is a new pseudo-enum type called MESA_ARRAY_FORMAT.  Between
that and the MESA_FORMAT enum you can, with a single 32-bit integer,
represent all of the mesa formats, gallium formats, and the entire
combinatorial explosion of GL formats.  The "master conversion function"
mentioned several times in this series is capable of converting between
any of these formats.  Also, this is a mesa enum, not a GL enum.  The
only knowledge the conversion functions have of GL is a single function
that converts a GL format/type pair into a MESA_FORMAT or
MESA_ARRAY_FORMAT.  From there on, it's entirely GL agnostic.

I hope this clears up some of your reservations.
--Jason

Yep, it does! I see this series in a whole new light. Thanks.

    In short, we can't change the past, but I wish we could have more
    synergy in the future.


    Jose


Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to