----- Original Message ----- > Jose Fonseca <jfons...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
