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 <g...@lunarg.com
<mailto:g...@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
<thomashellan...@gmail.com <mailto:thomashellan...@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 <matts...@gmail.com
<mailto:matts...@gmail.com>>:
> On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca
<jfons...@vmware.com <mailto:jfons...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
