Tom Stellard <tstel...@gmail.com> writes: > On Sun, May 27, 2012 at 02:25:05PM +0200, Francisco Jerez wrote: >> Tom Stellard <tstel...@gmail.com> writes: >> >[...] >> > +* ``PIPE_COMPUTE_CAP_IR_TARGET``: A description of the target as a target >> > + triple specification of the form ``processor-manufacturer-os`` that will >> > + be passed on to the compiler. If a driver accepts compute programs in >> > + the common TGSI representation, then it should specify ``tgsi`` as the >> > + processor. Value type: null-terminated string. >> >> This param doesn't even make sense for drivers that aren't using LLVM as >> IR, do you think it's going to be useful to force them to return "tgsi" >> here? > > We have to pass a triple to Clang somehow and since clover is passing > the value of this CAP directly to Clang I thought it would be necessary > for drivers using TGSI to return the TGSI triple here. > IMO the fact that we're going through clang and its "tgsi" back-end to emit TGSI is an implementation detail of the state tracker that pipe drivers don't have to know about: the pipe driver can use PREFERRED_IR to select the shader IR, and then, when applicable, IR_TARGET to select a specific dialect of it, that's all.
> The other way to handle this would be to have TGSI drivers return an
> empty string here and then let clover pass the TGSI triple
> for targets with a preferred IR of PIPE_SHADER_IR_TGSI, for example:
>
> std::string _cl_device_id::ir_target() const {
>
> std::vector<char> target;
> if (ir_format() == PIPE_SHADER_IR_TGSI) {
> target = "TGSI--";
> } else {
> target = get_compute_param<char>(pipe, PIPE_COMPUTE_CAP_IR_TARGET);
> }
> return { target.data() };
> }
>
> Would you prefer to do it this way?
>
Perhaps... I'll look into this more closely once the TGSI back-end is
mature enough.
>[...]
pgp8W3d3kuQcu.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
