Tom Stellard <thomas.stell...@amd.com> writes: > On Tue, Apr 17, 2012 at 06:27:20PM +0200, Francisco Jerez wrote: >> Jose Fonseca <jfons...@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;
> }
> }
>
>>
[...]
pgpqJYrEY8P7w.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
