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

[Tom Stellard]

On Fri, Aug 22, 2014 at 02:35:02PM -0700, Ian Romanick wrote:
> On 08/22/2014 02:17 PM, Tom Stellard wrote:
> > On Fri, Aug 22, 2014 at 02:10:03PM -0700, Ian Romanick wrote:
> >> 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 <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
> >>>>>>>>
> >>>>>>>> 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.
> >>
> > 
> > What exactly does precise do? LLVM has fast-math flags you can apply to
> > instructions and also some global flags.
> 
> Through various means, you can tag a calculation (and expression tree)
> so that the same calculation in different shaders will produce the exact
> same result.  This generally limits a lot of optimizations on such
> calculations.  For example:
> 
>     // shader A
>     precise o = a * b + c;
> 
>     // shader B
>     x = a * b;
>     precise o = a * b + c;
> 
> If shader A generates a MAD for the expression, shader B must also
> generate a MAD... even if that means being less efficient.  This is also
> why ARB_gpu_shader5 adds the fma function: many fma instructions have
> extra precision vs MUL+ADD.
> 
> This is often used in tesselation shaders so that neighboring patches
> with different materials won't have cracks between them.

Is it correct to say that precise disables fast-math optimizations for the
tagged expression?

-Tom