On 08/20/2014 11:58 AM, Tom Stellard wrote: > On Wed, Aug 20, 2014 at 11:13:13AM -0700, Kenneth Graunke wrote: >> 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 >>>>>> >>>>>> 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. >>> >>> 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). >> >> 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. >> >> 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. >> > > It has been a challenge to match versions of LLVM and Mesa for radeonsi, > but as Michel mention this has been made easier now that we are doing > LLVM point releases. > > However, as I mentioned before if we were using LLVM IR as a common IR > it is unlikely that there would be any new features in Mesa that would > depend on changes in LLVM. The only thing we would need to modify LLVM > for would be: > - Extending the C API > - Bug fixes for optimization passes > - Optimization pass improvements > > And remember all these changes would be for improving common code that > is shared between drivers. All of the important compiler features would > still go into the driver specific backends, which for most drivers are a > part of Mesa. > > Even for a big new feature like geometry shaders you wouldn't need > to make any modifications to LLVM to add it to the GLSL compiler in > Mesa. The only reason radeonsi has such a hard dependency on LLVM > is because the entire compiler is part of LLVM.
Speaking of new shader stages... how would LLVM handle the 'precise' keyword in tesselation shaders? I can envision ways to handle this in an IR that we control, but it's less obvious how we would handle it in LLVM or another external compiler package. > -Tom > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
