[Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

[John Kessenich]

Note that it is easy to add swizzle, saturate, clamp, etc. intrinsics to
LLVM IR.  Going a step further, LunarGLASS adds these, and then asks the
current back end what it would like to see (back-end queries).

If a back end says it likes a particular form, then LunarGLASS can
transform the LLVM IR into that form. This can include turning a clamp into
a saturate, turning component inserts into swizzles, etc., so that it
matches the back end's architecture.  This does not make the tool set
platform specific:  it simply adapts to what the current back end wants.
 (It is a key LunarGLASS principle to have platform independent mechanisms
while allowing back-end selected policies.)

That also means if there is a match in an such an idiom between the shader
source and the back-end's native architecture, that the information never
need be lost:  it is simply directly translated from GLSL to the right LLVM
IR intrinsic, and then the back end translates directly from the intrinsic
to it's native architecture support of the idiom.

As Greg mentioned, LunarG does have this stuff working in Mesa, where the
current "back end" is the GLSL IR.

JohnK




On Tue, Aug 26, 2014 at 3:21 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:

> On Tue, Aug 26, 2014 at 4:34 PM, Thomas Helland
> <thomashelland90 at gmail.com> wrote:
> > While I haven't heard about those projects, there's also GlassyMesa.
> > Greg from LunarG (CC'd) posted about this to the mailing list. [1]
> > However it looks like the github activity has stopped,
> > and there's no new info on the projects website since its announcement.
> >
> > While it's not exactly the same as we're describing here,
> > maybe he can share some on their experiences?
> > Status of the project? Performance numbers?
> > Packaging issues, ABI stability, etc?
> >
> > FWIW, I would prefer a world without LLVM,
> > as long as there's not a big performance per man-hour
> > benefit compared to rolling our own solution.
> > LLVM brings extra complexity to debugging and bisecting,
> > and if we want help from the users to bisect bugs it
> > should be as easy as absolutely possible.
>
> Before this discussion I think Matt, Ken, and Ian (the main compiler
> people still at Intel) had the same view which is why I started on
> NIR, but we'll see if someone can make an LLVM-based prototype that
> can change their minds. I guess I would be convinced if someone could
> make a backend for TGSI or i965 fs that won't be too hard to optimize
> in order to not produce extra MOV's, since I still think handling IR's
> like those with swizzles and writemasks is going to be painful with
> LLVM. Personally, I think the work to get something working with LLVM
> won't be much more than the work needed to get NIR to do what we need,
> since the optimizations we do need that LLVM would provide are either
> straightforward or well-described by a paper that we can pretty much
> follow directly, but we'll see - I'm not as sure about that.
>
> >
> > [1] http://lists.freedesktop.org/archives/mesa-dev/2014-June/060951.html
> >
> >
> > 2014-08-26 19:59 GMT+02:00 Matt Turner <mattst88 at gmail.com>:
> >> On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca <jfonseca at vmware.com>
> wrote:
> >>> If LLVM was a useless piece of junk, we wouldn't have any trouble
> adding it
> >>> as a dependency, as we would be the sole user.  But precisely because
> LLVM
> >>> is successful in so many use cases, hence several packages depend on
> it, we
> >>> shouldn't depend, so we can avoid the dealing with the oh-so-hard
> dependency
> >>> issue!?  I find it ridiculous: it's precisely because LLVM is
> potentially
> >>> that good that it makes sense for us/distros/everybody to put up with
> the
> >>> dependencies issues it may bring, and worth considering.
> >>
> >> It sounds like there are enough people in the Mesa community that are
> >> familiar with LLVM and interested in using it in the GLSL compiler
> >> that there would be someone willing to start working on it. Hopefully
> >> that's the case.
> >>
> >> I tried going through the LLVM language frontend tutorial on LLVM.org
> >> and only had to get to chapter 4 (the first two chapters don't use
> >> LLVM) before the code didn't compile (and I couldn't figure out why)
> >> with LLVM 3.4 on my system. I found this [1] tiny example (not updated
> >> for 2 years) using the C API and thought it'd probably not work
> >> either, but was happily surprised that it compiled and worked fine. I
> >> see that the C API is used in radeonsi and gallivm in Mesa.
> >>
> >> Here's what I think would be compelling: Using the stable C API,
> >> translate from GLSL IR into LLVM IR. Call LLVM's optimizations. Give
> >> backends the option to consume LLVM IR. From here we can evaluate just
> >> how significant the improvement from LLVM's optimizer is. At least two
> >> people have written GLSL IR -> LLVM translators in the past -- Luca
> >> Barbieri (what ever happened to him?!) and Vincent Lejeune (Cc'd).
> >> Their code is [2] and [3]. I think this plan would also fit nicely
> >> with existing LLVM backends, potentially avoiding a trip through TGSI.
> >>
> >> I think this is strictly superior to other ideas like throwing out the
> >> GLSL frontend and translating LLVM IR back "up" to the higher level
> >> GLSL IR.
> >>
> >> So, maybe some people experienced with LLVM from VMware and AMD are
> >> interested in taking the lead?
> >>
> >> [1] https://github.com/wickedchicken/llvm-c-example
> >> [2] http://cgit.freedesktop.org/~anholt/mesa/log/?h=llvm-4 (Eric's
> >> branch based on Luca's code)
> >> [3] http://cgit.freedesktop.org/~vlj/mesa/ (one of the glsl-to-llvm*
> branches)
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140827/01194abb/attachment.html>