Re: [Mesa3d-dev] Gallium + llvm integration

[Stephane M. <mar...@ic...>]

On Sun, Sep 28, 2008 at 8:46 PM, Zack Rusin <za...@tu...> wrote:
> On Sunday 28 September 2008 14:34:53 Stephane Marchesin wrote:
>> Hi,
>>
>> I'm working on llvm integration in gallium,
>
> Ah, that's great.
>
>> but I have a small problem
>> with the current design. Basically, the tgsi to llvm translator
>> currently generates calls to library functions (abs(), exp(), log(),
>> ...) at translation time, and now I want to be able to regarget llvm
>> to GPUs.
>
> Yea, that's not its design, just an implementation bug :)
> The design is that gallivm_ir was supposed to be completely target
> independent. During the gallivm_ir_compile call we wanted to have a hook that
> allows the driver to figure out how the target-independent representation is
> handled.

Ok, I'm going to do this then.

>
>> As you can imagine library calls won't work on a GPU, so I
>> think I'm going to change the tgsi to llvm translator to generate new
>> ops for what used to be library calls (i.e. for all the call* methods
>> of the Instructions class) and then have the gallium_cpu turn those
>> new ops into calls.
>> Does anyone object that ?
>
> No! That's exactly how it was always supposed to work =) The gallivm_ir was
> supposed to be populated with just tokens that were then either lowered or
> used as intrinsics (as required by the driver). (In general I think it might
> be easiest to treat all tgsi opcodes as intrinsics since that would make it
> easier to handle them. Maybe just add some helper function to lower some of
> them, e.g. driver could request to automatically lower 'lit' instead of
> treating is as an opcode).

Oh, I'm thinking about doing driver-specific llvm backends here. I've
realised that the difference between GPUs really didn't allow common
intermediate representation. Furthermore, the llvm tablegen format is
very powerful and I don't think it'll be much more work.

So basically instead of doing
TGSI -> LLVM -> TGSI -> driver
I think we should be doing
TGSI -> LLVM -> driver

That way we'd allow things like support for both vector (r300,
nv30/40, sse...) backends and scalar (nv50, x87 ...) backends.
Otherwise the scalar backends have to lower the vectors into scalars
at the last minute and this could be suboptimal. I also want to
support fixed pipe that way, by describing the fixed pipe
functionality in llvm DAGs and letting the DAG matcher from llvm do
the actual work. This is a cleaner approach to fixed pipe in gallium
than what I tried before.

Stephane