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

[Christoph Bumiller]

On 10.04.2012 14:50, Francisco Jerez wrote:
> Francisco Jerez <currojerez at riseup.net> writes:
>
>> This patch series is part of the ongoing work to put together a
>> compute stack on top of Gallium3D.  What we have been doing until now
>> to that end could be divided in 6 building blocks:
>>
>> 1/ Gallium API and TGSI changes (this patch series).
>> 2/ Other fixes and additions to the gallium helper libraries that the
>>    state tracker needs to function.
>> 3/ OpenCL state tracker.
>> 4/ Implementation of this API for the r600g driver, and work on AMD's
>>    LLVM back-end.
>> 5/ Implementation of this API for the nv50 driver, and related
>>    compiler changes based on Christoph's nv50/nvc0 codegen code.
>> 6/ LLVM back-end that will be used along with clang to translate
>>    compute programs from the OpenCL language into TGSI.
>>
>> Block 2 will be sent for review as a separate patch series soon.  I'm
>> not sending block 3 in patch form because it's probably too bulky for
>> this mailing list, and it's quite self-contained anyway, so, I've
>> pushed it together with the other changes it depends on to the new
>> 'gallium-compute' branch.
>>
>> Blocks 4-6 are still rather immature, but, for the curious: The
>> radeon-specific bits can be found in the 'clover-r600-master' branch
>> of Tom's mesa tree [1], and some of the work done for nouveau can be
>> found in the 'nv50-compute' branch of my tree [2].
>>
>> About this patch series: patches 1 and 11 are API changes that give
>> compute powers to pipe_context and pipe_screen, patches 3-10 are the
>> extensions to the TGSI language that will be used by the state tracker
>> to represent compute programs, patch 2 is a refactoring required by
>> patch 10.
>>
>> Comments, questions and r-b's are much appreciated.
>>
> I'm merging the gallium-compute branch to master in a couple of days if
> nobody has anything else against it.
>

I see we have PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE but I think we'll also
need PIPE_CAP_MAX_THREADS_PER_BLOCK.
For instance, you have have 512 threads per block on nv50, but the block
size limits are 512x512x64 individually.

And one more concern about lumping in UAVs/images/surfaces/RATs with
textures in set_*_sampler_views: for graphics, they're not per-shader
type but global, so if the interface allows for them to be specified
individually for each shader type that will get rather ugly.


>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev