<div dir="ltr">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).<div>
<br></div><div>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.)</div>
<div><br></div><div>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.</div>
<div><br></div><div>As Greg mentioned, LunarG does have this stuff working in Mesa, where the current "back end" is the GLSL IR.</div><div><br></div><div>JohnK</div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 3:21 PM, Connor Abbott <span dir="ltr"><<a href="mailto:cwabbott0@gmail.com" target="_blank">cwabbott0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Tue, Aug 26, 2014 at 4:34 PM, Thomas Helland<br>
<<a href="mailto:thomashelland90@gmail.com">thomashelland90@gmail.com</a>> wrote:<br>
> 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>
</div>Before this discussion I think Matt, Ken, and Ian (the main compiler<br>
people still at Intel) had the same view which is why I started on<br>
NIR, but we'll see if someone can make an LLVM-based prototype that<br>
can change their minds. I guess I would be convinced if someone could<br>
make a backend for TGSI or i965 fs that won't be too hard to optimize<br>
in order to not produce extra MOV's, since I still think handling IR's<br>
like those with swizzles and writemasks is going to be painful with<br>
LLVM. Personally, I think the work to get something working with LLVM<br>
won't be much more than the work needed to get NIR to do what we need,<br>
since the optimizations we do need that LLVM would provide are either<br>
straightforward or well-described by a paper that we can pretty much<br>
follow directly, but we'll see - I'm not as sure about that.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> [1] <a 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 href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>>:<br>
>> On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca <<a href="mailto:jfonseca@vmware.com">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 href="https://github.com/wickedchicken/llvm-c-example" target="_blank">https://github.com/wickedchicken/llvm-c-example</a><br>
>> [2] <a href="http://cgit.freedesktop.org/~anholt/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 href="http://cgit.freedesktop.org/~vlj/mesa/" target="_blank">http://cgit.freedesktop.org/~vlj/mesa/</a> (one of the glsl-to-llvm* branches)<br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div>