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

[Roland Scheidegger]

Am 20.08.2014 20:13, schrieb Kenneth Graunke:
> On Wednesday, August 20, 2014 06:41:08 PM Michel Dänzer wrote:
>> On 20.08.2014 00:04, Connor Abbott wrote:
>>> 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?
>>>>> 
>>>>> Yes. See
>>>>> 
>>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=JXdMJqLxDMsEjr3omF4b2U8%2F8eZQQmATYywWCcLRst4%3D%0A&s=f9f6f3190c2d8c98b183a74dc5d326e78974981e050eb5587820c19299e31ddd
>>>>>
>>>>>
>>>>> 
and
>>>>> 
>>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=JXdMJqLxDMsEjr3omF4b2U8%2F8eZQQmATYywWCcLRst4%3D%0A&s=b718382a00ad2a3cd458377a7bed9c477c76bdbde52f6c7a3e914c88b28d4156
>>>>
>>>>
>>>>> 
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.
>> 
>> First of all, thank you for sharing more specific information than 
>> 'table-flipping rage'.
>> 
>> 
>>> * 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...
>> 
>> This has indeed been frustrating at times, but it's better now for 
>> backend changes since Tom has been making LLVM point releases.
> 
> Yeah - absolutely.
> 
>> As for the GLSL frontend, I agree with Tom that it shouldn't
>> require that much direct interaction with the LLVM project.
>> 
>> 
>>> 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, [...]
>> 
>> That's news to me, can you be more specific?
>> 
>> That sounds like basically a distro issue though, since different
>> LLVM versions can be installed in parallel (and the one used by
>> default doesn't have to be the newest one). And it even works if
>> another part of the same process uses a different version of LLVM.
> 
> Yes, one can argue that it's a distribution issue - but it's an
> extremely painful problem for distributions.
> 
> For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08
> to 2014-03-22), and I was told this was because of LLVM versioning
> changes in the other drivers (primarily radeon, I believe, but
> probably also llvmpipe).
llvmpipe generally runs on pretty old llvm versions, though I didn't
check the specifics here...

> 
> Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we
> fixed that in Mesa 9.2.3.  But we couldn't get people to actually
> ship it, and had to field tons of bug reports from upset users for
> several months.
I think this also begs the question if changes requiring new external
libraries to compile really should be in a point release.

> 
> Gentoo has also had trouble updating for similar reasons; Matt (the
> Gentoo Mesa package mantainer) can probably comment more.
> 
> I've also heard stories from friends of mine who use radeonsi that
> they couldn't get new GL features or compiler fixes unless they
> upgrade both Mesa /and/ LLVM, and that LLVM was usually either not
> released or not available in their distribution for a few months.
> 
> Those are the sorts of things I'd like to avoid.  The compiler is
> easily the most crucial part of a modern graphics stack; splitting it
> out into a separate repository and project seems like a nightmare for
> people who care about getting new drivers released and shipped in
> distributions in a timely fashion.
> 
> Or, looking at it the other way: today, everything you need as an
> Intel or (AFAIK) Nouveau 3D user is nicely contained within Mesa.
> Our community has complete control over when we do those releases.
> New important bug fixes, performance improvements, or features?  Ship
> a new Mesa, and you're done.  That's a really nice feature I'd hate
> to lose.
> 
> --Ken

Couldn't build scripts download and use an appropriate llvm version
automatically if the one installed isn't sufficient? Though maybe the
idea is crazy I usually try to avoid to deal with such problems ;-).

Roland