[Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
jfonseca at vmware.com
Wed Apr 18 10:05:58 PDT 2012
----- Original Message -----
> Jose Fonseca <jfonseca at vmware.com> writes:
> > Francisco,
> > Sorry for the delay reviewing this, but I haven't been able to
> > dedicate some time until now.
> > Overall, it's a great piece of work! Just a few relatively minor
> > comments/requests.
> Hi Jose, thanks for the comments.
> >> gallium/tgsi: Add support for raw resources.
> > What's the difference between raw resources and buffers? Shouldn't
> > all
> > buffers be raw, and non-buffers resources non-row?
> The difference is that raw resources have no associated data type, so
> there's no type conversion between what the shader sees and what ends
> stored in memory. This is somewhat orthogonal to the number of
> addressing dimensions of the resource, so you can get raw 2D
> 3D textures, etc.
> You're right that CL only uses raw buffers right now, but D3D11 makes
> similar distinction and both raw and non-raw buffers are likely to be
> useful if someone tries to implement ByteAddressBuffers and Buffers,
Ok. Sounds good.
> >> gallium/compute: Drop TGSI dependency.
> > This fine in principle, but I don't understand what
> > PIPE_COMPUTE_CAP_IR_TARGET's triplets are supposed to be (a
> > string?),
> Yes, it's supposed to be a null-terminated string containing a target
> triple specification in the "standard" form many compilers
> as documented in "screen.rst".
> > 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
> good idea in itself. It opens the door to a situation where each
> has to provide a compiler front-end for each individual API it aims
> support, and it would break with the principle of having API-agnostic
> drivers running under a hardware-agnostic state tracker.
> IMHO, in an ideal world we'd have one common transport IR all drivers
> would be comfortable with, otherwise you get a matrix of code paths
> is likely to get more and more painful to debug and maintain as the
> number of drivers and state trackers grows.
I agree entirely.
This idea of passing GLSL IR assumes that GLSL IR would grow to be generic enough to represent any shader, and not just GLSL derived ones.
More information about the mesa-dev