On Tue, Nov 18, 2014 at 1:42 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> 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? > It stands for "oil runtime compiler". The homepage, which seems to be down at the moment, can be found here: http://code.entropywave.com/orc/ ORC is a JIT designed for producing highly optimized streaming code that takes full advantage of CPU features such as SSE. It's designed for fairly small kernels that need to be run fast on arrays of data. I haven't taken more than a very cursory look at it, so I can't say much more. Aparently, the gstreamer people use it for all of their software filters and video transformations. > 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
