[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