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

[Jose Fonseca]

----- 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
> up
> stored in memory.  This is somewhat orthogonal to the number of
> addressing dimensions of the resource, so you can get raw 2D
> textures,
> 3D textures, etc.
> 
> You're right that CL only uses raw buffers right now, but D3D11 makes
> a
> similar distinction and both raw and non-raw buffers are likely to be
> useful if someone tries to implement ByteAddressBuffers and Buffers,
> respectively.

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
> understand,
> 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
> 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.


> 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
> that
> 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.

Jose