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

[Francisco Jerez]

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.

>[...]
>>       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.

As AMD didn't seem to be willing to use TGSI directly in their compute
stack, the purpose of this change was to simplify the driver code in
cases where the front-end compiler already happens to support the native
binary format required by the pipe driver, so, right now
PIPE_COMPUTE_CAP_IR_TARGET can be either "tgsi" or the hardware's native
binary format.

> I think that an enum would be preferrable.
>
I'm OK with changing it to an enum if you think it would be preferable.

What made me decide for a string was that if it were to be an enum, we
would need to have hardware-specific enum values
(e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state trackers would
need driver-specific code to make a proper interpretation of it.  If
it's a string in some standard form the state tracker can just pass it
on to the compiler without looking inside.

> Jose
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120417/eace2a56/attachment.pgp>