[Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
Christian König
christian.koenig at amd.com
Fri Aug 29 09:49:13 PDT 2014
Maybe a heretical thought, but how close are you guys to shortcut the
front end compiler with let's say the LLVM back end in radeonsi?
Regards,
Christian.
Am 29.08.2014 um 17:51 schrieb Greg Fischer:
> Some additional information on GlassyMesa from the engineer who integrated
> LunarGlass and wrote the LLVM Bottom IR to GLSL IR pass.
>
> [Begin Steve...]
>
> I wasn't subscribed to the mesa-dev list at the time of prior replies to
> this thread, so sending this to the list via Greg.
>
> Per request from Thomas, here are some results and current status of the
> GlassyMesa project. (And yes, we are still working on it :) ).
>
> We have integrated gslang, LunarGlass, and LLVM into Mesa, and are using
> it to run many (over 80) gaming workloads with success. This work isn't
> pushed yet to github, but will be shortly. There is a large compile
> time switch to enable the new features, and a runtime .drirc switch to
> select between behaviors on a per workload basis. There are some
> features left to complete before every potential workload can be run, so
> it is enabled via whitelist.
>
> As Greg mentioned, we don't think the translation to HIR is the right
> long term solution, but it has allowed experimenting with an LLVM
> optimizer in the graphics stack. With more work, LLVM form could be
> consumed by backends, which seems like an architecturally superior answer.
>
> Thomas asked for performance numbers. There are many different domains
> in which performance can be measured (timedemos, frame looping,
> scheduler clock estimates, shader_time logging, etc). We found some
> areas of the i965 backend which needed improvement, so our performance
> numbers include both LunarGlass and backend changes. However, even
> before we made i965 BE changes, we saw improvements from the FE/ME
> replacement alone. Our overall (ME+BE changes) timedemo results are in
> the range of 0-14% for several major AAA titles (i.e, no performance
> regressions that I've seen, and multiple progressions). Note that those
> numbers are through actual applications, so exist in a complex
> environment of other performance factors such as mixtures of light and
> heavyweight frames, other bottlenecks, and so forth.
>
> We are statically linking against LLVM and using a locally built
> snapshot, so there have been no ABI stability issues to contend with; we
> haven't changed the LLVM version we're using since the start of the
> project. There was a small PIC build config difference to sort out
> early on, but that's solved and was a one-time thing to figure out.
>
> Steve
>
>
> On Tue, Aug 26, 2014 at 6:45 PM, Greg Fischer <greg at lunarg.com
> <mailto:greg at lunarg.com>> wrote:
>
> The GlassyMesa effort is ongoing despite the lack of recent
> activity. We continue to embrace LLVM as a basis for shader
> compilation in Mesa and elsewhere.
>
> We agree that translating from LLVM back "up" to GLSL IR is
> problematic and that an architecture that supports LLVM backends
> would be desirable.
>
> The current published code is a work-in-progress. We are currently
> working on tuning of compilation time and code generation quality,
> and some of that work will likely be appearing soon. There have
> also been recent improvements in glslang, the parser for this stack.
>
> Packaging and ABI stability have not been an issue for us.
>
> Best regards,
> Greg
>
>
>
>
> On Tue, Aug 26, 2014 at 2:34 PM, Thomas Helland
> <thomashelland90 at gmail.com <mailto: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.
>
> [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
> <mailto:mattst88 at gmail.com>>:
> > On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca
> <jfonseca at vmware.com <mailto: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
> <http://cgit.freedesktop.org/%7Eanholt/mesa/log/?h=llvm-4> (Eric's
> > branch based on Luca's code)
> > [3] http://cgit.freedesktop.org/~vlj/mesa/
> <http://cgit.freedesktop.org/%7Evlj/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140829/a33c6545/attachment-0001.html>
More information about the mesa-dev
mailing list