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

[Connor Abbott]

On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer <michel at daenzer.net> wrote:
> On 19.08.2014 01:28, Connor Abbott wrote:
>> On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>> On 16.08.2014 09:12, Connor Abbott wrote:
>>>> I know what you might be thinking right now. "Wait, *another* IR? Don't
>>>> we already have like 5 of those, not counting all the driver-specific
>>>> ones? Isn't this stuff complicated enough already?" Well, there are some
>>>> pretty good reasons to start afresh (again...). In the years we've been
>>>> using GLSL IR, we've come to realize that, in fact, it's not what we
>>>> want *at all* to do optimizations on.
>>>
>>> Did you evaluate using LLVM IR instead of inventing yet another one?
>>>
>>>
>>> --
>>> Earthling Michel Dänzer            |                  http://www.amd.com
>>> Libre software enthusiast          |                Mesa and X developer
>>
>> Yes. See
>>
>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html
>>
>> and
>>
>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html
>
> I know Ian can't deal with LLVM for some reason. I was wondering if
> *you* evaluated it, and if so, why you rejected it.
>
>
> --
> Earthling Michel Dänzer            |                  http://www.amd.com
> Libre software enthusiast          |                Mesa and X developer


Well, first of all, the fact that Ian and Ken don't want to use it
means that any plan to use LLVM for the Intel driver is dead in the
water anyways - you can translate NIR into LLVM if you want, but for
i965 we want to share optimizations between our 2 backends (FS and
vec4) that we can't do today in GLSL IR so this is what we want to use
for that, and since nobody else does anything with the core GLSL
compiler except when they have to, when we start moving things out of
GLSL IR this will probably replace GLSL IR as the infrastructure that
all Mesa drivers use. But with that in mind, here are a few reasons
why we wouldn't want to use LLVM:

* LLVM wasn't built to understand structured CFG's, meaning that you
need to re-structurize it using a pass that's fragile and prone to
break if some other pass "optimizes" the shader in a way that makes it
non-structured (i.e. not expressible in terms of loops and if
statements). This loss of information also means that passes that need
to know things like, for example, the loop nesting depth need to do an
analysis pass whereas with NIR you can just walk up the control flow
tree and count the number of loops we hit.

* LLVM doesn't do modifiers, meaning that we can't do optimizations
like "clamp(x, 0.0, 1.0) => mov.sat x" and "clamp(x, 0.25, 1.0) =>
max.sat(x, .25)" in a generic fashion.

* LLVM is hard to embed into other projects, especially if it's used
as anything but a command-line tool that only runs once. See, for
example, http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html
under "Linking WebKit with LLVM" - most of those problems would also
apply to us.

* LLVM is on a different release schedule (6 months vs. 3 months), has
a different review process, etc., which means that to add support for
new functionality that involves shaders, we now have to submit patches
to two separate projects, and then 2 months later when we ship Mesa it
turns out that nobody can actually use the new feature because it
depends upon an unreleased version of LLVM that won't be released for
another 3 months and then packaged by distros even later... we've
already had problems where distros refused to ship newer Mesa releases
because radeon depended on a version of LLVM newer than the one they
were shipping, and if we started using LLVM in core Mesa it would get
even worse. Proprietary drivers solve this problem by just forking
LLVM, building it with the rest of their driver, and linking it in as
a static library, but distro packagers would hate us if we did that.

I wouldn't completely rule out LLVM, and I do think they do a lot of
things right, but for now it seems like it's not the path that the
Intel team wants to take.

Connor