Am 22.08.2014 um 17:13 schrieb Connor Abbott:
On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie <airl...@gmail.com> wrote:
On 22 August 2014 12:46, Jason Ekstrand <ja...@jlekstrand.net> wrote:
On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie <airl...@gmail.com> wrote:
On 21 August 2014 19:10, Henri Verbeet <hverb...@gmail.com> wrote:
On 21 August 2014 04:56, Michel Dänzer <mic...@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.
That sounds like a huge amount of work, possibly even more work than
going it on our own because the LLVM project moves really quickly and
we'd have to import all of the changes. Also, it seems pretty ugly and
I'm sure distro maintainers would just looooooove a solution like that
/s. Just look at the situation with Chromium and Fedora now (or at
least last I checked).
Actually the LLVM IR is considered stable and as Dave explained we
wouldn't depend on LLVM, but rather just use the same concept for the IR.
This actually sounds like a pretty good idea to me. And I would say we
should just continue moving the GLSL IR towards SSA and all the
specialized GL opcodes into something similar to LLVM intrinsics.
Christian.
Connor
Dave.
_______________________________________________
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
