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 >>> <mic...@daenzer.net> wrote: >>>> On 19.08.2014 01:28, Connor Abbott wrote: >>>>> On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer >>>>> <mic...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
