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

Tom Stellard tom at stellard.net
Fri Aug 22 09:32:55 PDT 2014


On Sat, Aug 23, 2014 at 12:17:00AM +1000, Dave Airlie wrote:
> On 23 August 2014 00:15, Tom Stellard <tom at stellard.net> wrote:
> > On Fri, Aug 22, 2014 at 01:08:02PM +1000, Dave Airlie wrote:
> >> On 22 August 2014 12:46, Jason Ekstrand <jason at jlekstrand.net> wrote:
> >> > On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie <airlied at gmail.com> wrote:
> >> >>
> >> >> On 21 August 2014 19:10, Henri Verbeet <hverbeet at gmail.com> wrote:
> >> >> > On 21 August 2014 04:56, Michel Dänzer <michel at daenzer.net> wrote:
> >> >> >> On 21.08.2014 04:29, Henri Verbeet wrote:
> >> >> >>> For whatever it's worth, I have been avoiding radeonsi in part because
> >> >> >>> of the LLVM dependency. Some of the other issues already mentioned
> >> >> >>> aside, I also think it makes it just painful to do bisects over
> >> >> >>> moderate/longer periods of time.
> >> >> >>
> >> >> >> More painful, sure, but not too bad IME. In particular, if you know the
> >> >> >> regression is in Mesa, you can always use a stable release of LLVM for
> >> >> >> the bisect. You only need to change the --with-llvm-prefix= parameter
> >> >> >> to
> >> >> >> Mesa's configure for that. Of course, it could still be mildly painful
> >> >> >> if you need to go so far back that the current stable LLVM release
> >> >> >> wasn't supported yet. But how often does that happen? Very rarely for
> >> >> >> me.
> >> >> >>
> >> >> > Sure, it's not impossible, but is that really the kind of process you
> >> >> > want users to go through when bisecting a regression? Perhaps throw in
> >> >> > building 32-bit versions of both Mesa and LLVM on 64-bit as well if
> >> >> > they want to run 32-bit applications.
> >> >> >
> >> >> >> Without LLVM, I'm not sure there would be a driver you could avoid. :)
> >> >> >>
> >> >> > R600g didn't really exist either, and that one seems to have worked
> >> >> > out fine. I think in a large part because of work done by Jerome and
> >> >> > Dave in the early days, but regardless. From what I've seen from SI, I
> >> >> > don't think radeonsi needed to be a separate driver to start with, and
> >> >> > while its ISA is certainly different from R600-Cayman, it doesn't
> >> >> > particularly strike me as much harder to work with.
> >> >> >
> >> >> > Back to the more immediate topic though, I think think that on
> >> >> > occasion the discussion is framed as "Is there any reason using LLVM
> >> >> > IR wouldn't work?", while it would perhaps be more appropriate to
> >> >> > think of as "Would using LLVM IR provide enough advantages to justify
> >> >> > adding a LLVM dependency to core Mesa?".
> >> >>
> >> >> Could we use an llvm compatible IR? is also a question I'd like to see
> >> >> answered.
> >> >
> >> >
> >> > What do you mean by llvm compatible?  Do you mean forking their IR inside
> >> > mesa or just something that's easy to translate back and forth?
> >> >
> >>
> >> Importing/forking the llvm IR code with a different symbol set, and
> >> trying to not intentionally
> >> be incompatible with their llvm.
> >>
> >
> > What would be the purpose of doing this?  Avoiding a dependency on the LLVM libraries?
> 
> Spltting the problem of using llvm IR from the problem of linking with
> llvm, since people
> appear to be conflating them.
> 
> So yes avoid the direct dep for now.
> 

The main advantage of using LLVM IR is having access to all the
functionality provided by the libraries, so while it would be possible
to use the IR without the library, it would be a lot of work with no
benefit.

-Tom


More information about the mesa-dev mailing list