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

[Henri Verbeet]

I'd like to say up front that while I could imagine that perhaps some
of my comments on radeonsi could be perceived as harsh, it's not my
intention to pick on radeonsi or anyone working on radeonsi in
particular. I just think radeonsi / r600g is probably the best
comparison inside Mesa for a driver done with and without a hard LLVM
dependency.

I think it's perhaps also useful to point out that my comments in this
thread are at least in part as advice from a Wine developer, where I
think we've had our fair share of experience with external
dependencies, rather than in my much more limited role as a Mesa
developer. We also briefly evaluated using LLVM for vbscript, jscript
and a HLSL compiler in Wine a couple of years ago, but decided it
wasn't worth it.

On 28 August 2014 05:21, Michel Dänzer <michel at daenzer.net> wrote:
>> Sure, it's not impossible, but is that really the kind of process you
>> want users to go through when bisecting a regression?
>
> I appreciate your theoretical concern, but in practice, people don't seem to
> have trouble bisecting radeonsi regressions in general.
>
I suspect you may be getting some selection bias there.
As far as Wine users are concerned, we certainly seem to have more
r600g users than radeonsi ones. For Wine developers that comparison is
even worse; as far as I'm aware none of the regular developers
regularly develop on radeonsi. I've seen a couple more casual
developers try, but I suspect they essentially gave up once they
realized how much work would be required to make the Wine tests pass
on radeonsi.

>>> 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.
>
> That's getting off-topic, but most of the code that can be shared between
> radeonsi and r600g is shared now.
>
I've seen Marek in particular put a lot of effort into that, yeah. I
just think that effort could have been avoided. But my point was
mostly that while I'd estimate most of the work in radeonsi to be in
supporting the new ISA, I don't think that work would have been
considerably harder than the work to support the R600-Cayman ISA was.
And by implication, that I seriously doubt using LLVM there really
saved any effort at all.

Perhaps more concretely, I think the r600-sb backend works at least as
well as the r600-llvm one, and not for lack of effort put into the
latter.

>> 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?".
>
> Unless you can show me anyone who would prefer swrast or softpipe over
> llvmpipe for software rendering tests, I'd argue that there effectively
As a user, I currently have no reason to build any software renderer
at all. But yes, as a developer I generally test against softpipe
because it's easier to work with.

The bottom line is that today I can build r600g without worrying about
LLVM, and have a driver that I can use for Wine development. So yes,
using LLVM in core Mesa would add an extra dependency.