It's been discussed in a bunch of other threads, but the 10,000 foot view is "it's too early to tell". There are probably a half dozen different IRs that are or will be on the table in the next year.
TGSI is probably the safest bet, particularly if Francisco's additions for compute are accepted and work out generally OK. LLVM IR is up there as well, but is a more natural fit for (scalar) compute than for (short vector) graphics, particularly when dealing with short vector or vliw hardware.
The original Gallium3D proposal envisioned using TGSI as the IR but then converting it to LLVM IR for optimization by LLVM before generating hardware instructions. That made sense to everyone but got a bit awkward when most of the OpenCL front ends *above* TGSI ended up using LLVM IR as well.
Try the thread around :
It starts as Intel-bashing for not using Gallium3D and TGSI then shifts more to a generic IR discussion.
Announcement
Collapse
No announcement yet.
The OpenCL State Tracker Nears Working State
Collapse
X
-
Originally posted by bridgman View PostThe clang front end generates LLVM IR and clover was written around LLVM IR (it used LLVM to generate x86 code to run the OpenCL kernels). I don't know if Francisco kept all the LLVM to x86 functionality but if not I guess we'll need to hook into the LLVM IR before it gets converted to TGSI. Tom and Francisco talk frequently so hopefully one isn't demolishing what the other is building on.
We could go c99 => LLVM IR => TGSI => LLVM IR => ISA rather than C99 => LLVM IR => ISA but that seems like something we should avoid if possible.
Leave a comment:
-
Originally posted by cwabbott View PostSo, how does this fit in with the work that AMD is doing to support OpenCL through LLVM? Will there be two seperate OpenCL state trackers - one that emits LLVM, and another that emits TGSI?
We could go c99 => LLVM IR => TGSI => LLVM IR => ISA rather than C99 => LLVM IR => ISA but that seems like something we should avoid if possible.Last edited by bridgman; 29 January 2012, 12:26 AM.
Leave a comment:
-
So, how does this fit in with the work that AMD is doing to support OpenCL through LLVM? Will there be two seperate OpenCL state trackers - one that emits LLVM, and another that emits TGSI?
On a related note - LLVM has already started to support VLIW with the MachineInstrBundle, and they say there will be a generic VLIW scheduler in the future - so my 2 cents is that LLVM is looking better and better as a GPU IR. So, what exactly is missing from the backend then to prevent everybody from just switching over now? Are there some vector instructions missing?
Leave a comment:
-
Originally posted by FourDMusic View PostWith Francisco's and Tom's work, will it be possible to run OpenCL programs on both my graphics cards with this state tracker and the open source driver? Or would you need crossfire do to this? AFAIK, I thought crossfire was more of sharing a graphics load and not a compute load.
AFAIK the OpenCL support for multiple devices uses an "expose both devices to the application and let it decide what to do" model rather than "pretend to be a single device and invisibly split/reassemble the work" so support for multiple devices with OpenCL should be a lot less work than a full Crossfire implementation.Last edited by bridgman; 28 January 2012, 11:33 AM.
Leave a comment:
-
With Francisco's and Tom's work, will it be possible to run OpenCL programs on both my graphics cards with this state tracker and the open source driver? Or would you need crossfire do to this? AFAIK, I thought crossfire was more of sharing a graphics load and not a compute load.
Leave a comment:
-
Originally posted by alanc View Post
Leave a comment:
Leave a comment: