<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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?<br>
<br>
Regards,<br>
Christian.<br>
<br>
Am 29.08.2014 um 17:51 schrieb Greg Fischer:<br>
</div>
<blockquote
cite="mid:CA+NiQowSUL57Hk4YtJCTfm+JQteHaqFGtJ7ffQi7hWOYjr+xbA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class=""><img moz-do-not-send="true" class="" id=":1g0"
src="https://mail.google.com/mail/u/0/images/cleardot.gif"
alt="">Some additional information on GlassyMesa from the
engineer who integrated<br>
</div>
<div class="">
LunarGlass and wrote the LLVM Bottom IR to GLSL IR pass.<br>
<br>
[Begin Steve...]<br>
<br>
</div>
I wasn't subscribed to the mesa-dev list at the time of prior
replies to<br>
this thread, so sending this to the list via Greg.<br>
<br>
Per request from Thomas, here are some results and current
status of the<br>
GlassyMesa project. (And yes, we are still working on it :)
).<br>
<br>
We have integrated gslang, LunarGlass, and LLVM into Mesa, and
are using<br>
it to run many (over 80) gaming workloads with success. This
work isn't<br>
pushed yet to github, but will be shortly. There is a large
compile<br>
time switch to enable the new features, and a runtime .drirc
switch to<br>
select between behaviors on a per workload basis. There are
some<br>
features left to complete before every potential workload can
be run, so<br>
it is enabled via whitelist.<br>
<br>
As Greg mentioned, we don't think the translation to HIR is
the right<br>
long term solution, but it has allowed experimenting with an
LLVM<br>
optimizer in the graphics stack. With more work, LLVM form
could be<br>
consumed by backends, which seems like an architecturally
superior answer.<br>
<br>
Thomas asked for performance numbers. There are many
different domains<br>
in which performance can be measured (timedemos, frame
looping,<br>
scheduler clock estimates, shader_time logging, etc). We
found some<br>
areas of the i965 backend which needed improvement, so our
performance<br>
numbers include both LunarGlass and backend changes. However,
even<br>
before we made i965 BE changes, we saw improvements from the
FE/ME<br>
replacement alone. Our overall (ME+BE changes) timedemo
results are in<br>
the range of 0-14% for several major AAA titles (i.e, no
performance<br>
regressions that I've seen, and multiple progressions). Note
that those<br>
numbers are through actual applications, so exist in a complex<br>
environment of other performance factors such as mixtures of
light and<br>
heavyweight frames, other bottlenecks, and so forth.<br>
<br>
We are statically linking against LLVM and using a locally
built<br>
snapshot, so there have been no ABI stability issues to
contend with; we<br>
haven't changed the LLVM version we're using since the start
of the<br>
project. There was a small PIC build config difference to
sort out<br>
early on, but that's solved and was a one-time thing to figure
out.<br>
<br>
</div>
Steve<br>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Aug 26, 2014 at 6:45 PM,
Greg Fischer <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:greg@lunarg.com"
target="_blank">greg@lunarg.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>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.<br>
<br>
</div>
We agree that translating from LLVM back "up" to
GLSL IR is problematic and that an architecture
that supports LLVM backends would be desirable.<br>
<br>
</div>
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. <br>
<br>
Packaging and ABI stability have not been an issue
for us.<br>
<br>
</div>
Best regards,<br>
</div>
Greg<br>
<div>
<div>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra">
<br>
<br>
<div class="gmail_quote">
On Tue, Aug 26, 2014 at 2:34 PM, Thomas Helland
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:thomashelland90@gmail.com"
target="_blank">thomashelland90@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
While I haven't heard about those projects,
there's also GlassyMesa.<br>
Greg from LunarG (CC'd) posted about this to
the mailing list. [1]<br>
However it looks like the github activity has
stopped,<br>
and there's no new info on the projects
website since its announcement.<br>
<br>
While it's not exactly the same as we're
describing here,<br>
maybe he can share some on their experiences?<br>
Status of the project? Performance numbers?<br>
Packaging issues, ABI stability, etc?<br>
<br>
FWIW, I would prefer a world without LLVM,<br>
as long as there's not a big performance per
man-hour<br>
benefit compared to rolling our own solution.<br>
LLVM brings extra complexity to debugging and
bisecting,<br>
and if we want help from the users to bisect
bugs it<br>
should be as easy as absolutely possible.<br>
<br>
[1] <a moz-do-not-send="true"
href="http://lists.freedesktop.org/archives/mesa-dev/2014-June/060951.html"
target="_blank">http://lists.freedesktop.org/archives/mesa-dev/2014-June/060951.html</a><br>
<br>
<br>
2014-08-26 19:59 GMT+02:00 Matt Turner <<a
moz-do-not-send="true"
href="mailto:mattst88@gmail.com"
target="_blank">mattst88@gmail.com</a>>:<br>
> On Tue, Aug 26, 2014 at 9:00 AM, Jose
Fonseca <<a moz-do-not-send="true"
href="mailto:jfonseca@vmware.com"
target="_blank">jfonseca@vmware.com</a>>
wrote:<br>
>> If LLVM was a useless piece of junk,
we wouldn't have any trouble adding it<br>
>> as a dependency, as we would be the
sole user. But precisely because LLVM<br>
>> is successful in so many use cases,
hence several packages depend on it, we<br>
>> shouldn't depend, so we can avoid the
dealing with the oh-so-hard dependency<br>
>> issue!? I find it ridiculous: it's
precisely because LLVM is potentially<br>
>> that good that it makes sense for
us/distros/everybody to put up with the<br>
>> dependencies issues it may bring, and
worth considering.<br>
><br>
> It sounds like there are enough people in
the Mesa community that are<br>
> familiar with LLVM and interested in
using it in the GLSL compiler<br>
> that there would be someone willing to
start working on it. Hopefully<br>
> that's the case.<br>
><br>
> I tried going through the LLVM language
frontend tutorial on LLVM.org<br>
> and only had to get to chapter 4 (the
first two chapters don't use<br>
> LLVM) before the code didn't compile (and
I couldn't figure out why)<br>
> with LLVM 3.4 on my system. I found this
[1] tiny example (not updated<br>
> for 2 years) using the C API and thought
it'd probably not work<br>
> either, but was happily surprised that it
compiled and worked fine. I<br>
> see that the C API is used in radeonsi
and gallivm in Mesa.<br>
><br>
> Here's what I think would be compelling:
Using the stable C API,<br>
> translate from GLSL IR into LLVM IR. Call
LLVM's optimizations. Give<br>
> backends the option to consume LLVM IR.
From here we can evaluate just<br>
> how significant the improvement from
LLVM's optimizer is. At least two<br>
> people have written GLSL IR -> LLVM
translators in the past -- Luca<br>
> Barbieri (what ever happened to him?!)
and Vincent Lejeune (Cc'd).<br>
> Their code is [2] and [3]. I think this
plan would also fit nicely<br>
> with existing LLVM backends, potentially
avoiding a trip through TGSI.<br>
><br>
> I think this is strictly superior to
other ideas like throwing out the<br>
> GLSL frontend and translating LLVM IR
back "up" to the higher level<br>
> GLSL IR.<br>
><br>
> So, maybe some people experienced with
LLVM from VMware and AMD are<br>
> interested in taking the lead?<br>
><br>
> [1] <a moz-do-not-send="true"
href="https://github.com/wickedchicken/llvm-c-example"
target="_blank">https://github.com/wickedchicken/llvm-c-example</a><br>
> [2] <a moz-do-not-send="true"
href="http://cgit.freedesktop.org/%7Eanholt/mesa/log/?h=llvm-4"
target="_blank">http://cgit.freedesktop.org/~anholt/mesa/log/?h=llvm-4</a>
(Eric's<br>
> branch based on Luca's code)<br>
> [3] <a moz-do-not-send="true"
href="http://cgit.freedesktop.org/%7Evlj/mesa/"
target="_blank">http://cgit.freedesktop.org/~vlj/mesa/</a>
(one of the glsl-to-llvm* branches)<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mesa-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>