[Mesa-dev] [PATCH 10/11] clover: Add function for building a clover::module for non-TGSI targets

[Francisco Jerez]

Tom Stellard <tstellar at gmail.com> writes:

> On Sun, May 13, 2012 at 12:40:43AM +0200, Francisco Jerez wrote:
>>[...]
>> I can think of two different ways this could work (your solution would
>> be somewhere in between):
>> 
>>  - The r600g LLVM back-end could support some well-defined output object
>>    format (e.g. the one implemented by the clover::module classes), like
>>    most of the other LLVM back-ends.  You probably want to do this
>>    anyway if you want to be able to compile CL programs off-line.  If
>>    you do it this way, the state tracker will just call clang to
>>    completion using the appropriate target and pass the generated
>>    machine code to the pipe driver.
>> 
>>    If you think supporting different hardware versions with different
>>    ISAs would be a problem under this scheme, we could have another
>>    compute cap that would determine a specific variant of the ISA.
>>
>
> I think this is the most practical of these two options.  However, the
> biggest draw back of this solution is that if a target uses a backend that
> is not a part of the LLVM tree (the r600 backend is not in the LLVM tree,
> but I'm working on getting it in), the backend would have to be included
> as a part of clover and drivers using LLVM for other state tracker would
> end up with one copy of their LLVM backend in clover and another in the
> driver.

Apparently it's already standard practice in LLVM to build back-ends as
separate object files.  I don't see why you couldn't build the r600
back-end as a shared library.  There's no reason for it to be duplicated
in the source tree or the address space of the process it's running in.

> I guess this might be able to work, but I'm not really sure why doing
> it this way would be better than what is implemented in this patch.
>
I just think it would be useful by itself to have the r600 back-end able
to emit machine code in a specific object file format, and at the same
time, by doing so you avoid driver-specific code in the state tracker
that does one thing or another depending on the hardware it's running
on, which seems like a layering violation to me.

>>  - Another option would be to forget about driver-specific IRs in the
>>    compute API.  The pipe driver would have the choice between TGSI and
>>    LLVM, if it wants LLVM, the state tracker would do roughly what
>>    you're doing here using some sort of "identity" LLVM target that
>>    would do nothing but describing the peculiarities of the hardware
>>    (e.g. endianness, widths of the supported primitive types), which in
>>    turn would be queried from the pipe driver using compute caps.
>>
>
> This is the way I thought it would work initially, but the only way to
> describe a target to Clang is by using the target triple, so passing a
> list of caps into Clang is not going to work.
>
Why not?  You're in control of the back-end, maybe I'm missing something
but I don't see why the state tracker couldn't provide all the required
parameters to the back-end as it's instantiated.

If this is impossible for some reason, can't we encode these parameters
in the processor variant part of the target triple?  Aren't these
parameters supposed to be encoded as a target description string at some
point anyway?

>> Personally I think the latter would be closer to ideal, but I guess it
>> would also involve more work...
>
> My preference is to keep this patch as is.  At this point, I'm not
> really sure why the proposed alternate solutions would be better than
> the current implementation, and I think if we want to support out of
> tree backends, we will need to at least have the option of doing it this
> way.
>
What bothers me of this solution is that you're pumping bytecode using a
generic representation, but in a non-generic way, that isn't going to be
useful for drivers other than r600 that want compute programs in the
same representation -- at least not without a number of driver-specific
ad-hoc changes in both LLVM and the CL state tracker.

I'm fine with the CL state tracker giving out code in LLVM IR, but, if
it does, I really think it makes no sense for it to even know it's
running on r600.

> Even though I prefer this solution, ultimately I want to come up with
> something that works for everyone even if it isn't exactly what I
> proposed.  So, I hope we will be able to work something out.
>
> -Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120513/109ec813/attachment-0001.pgp>