[Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.

Francisco Jerez currojerez at riseup.net
Wed Apr 18 17:15:31 PDT 2012


Tom Stellard <thomas.stellard at amd.com> writes:

> On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote:
>> Jose Fonseca <jfonseca at vmware.com> writes:
>>[...]
>> > and how would this scheme work, e.g., if a driver wanted to consume
>> > GLSL IR in the future.
>> 
>> Hm, I'm not convinced that letting a driver consume GLSL IR would be a
>> good idea in itself.  It opens the door to a situation where each driver
>> has to provide a compiler front-end for each individual API it aims to
>> support, and it would break with the principle of having API-agnostic
>> drivers running under a hardware-agnostic state tracker.
>
> The target triple and the IR type are two separate issues.  The
> target triple really doesn't say anything about the IR type the driver
> expects.  Really, the only purpose of the target triple is to describe the target
> to help the compiler frontend generate correct code.
>
Hmm, sorry, I'm not following your argument.  Doesn't an exact
specification of the target determine a certain instruction set, and a
certain binary representation of it?  The driver just has to be able to
deal with the format it's asking for.

> I think we should also add a query function like this in order to communicate to
> the state tracker the kind of IR it should pass to the driver:
>
> unsigned get_prefered_ir(unsigned shader_type) {
>     switch(shader_type) {
>     default:
>        return GALLIUM_IR_TGSI;
>     }
> }
>
>> 
[...]
-------------- 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/20120419/be52ce6f/attachment.pgp>


More information about the mesa-dev mailing list