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

[Marek Olšák]

On Fri, Apr 13, 2012 at 8:24 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> 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.
>
> ----- Original Message -----
>> 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.
>>
>> [1] http://cgit.freedesktop.org/~tstellar/mesa/
>> [2] https://github.com/curro/mesa
>>
>> Francisco Jerez (11):
>>       gallium: Basic compute interface.
>
> Is the
>
>  unsigned start_slot
>
> parameter in bind_compute_sampler_states/set_compute_sampler_views methods really necessary? I rather have these methods consistent with the non-compute ones.  If/when we add such parameter, it should be done for all methods.

Hi José!

Now that you are mentioning start_slot, I'd like to discuss it with
you a little bit more. I plan to add the start_slot parameter to all
gallium functions where it makes sense. Changing resources is not
free, and having to change N resources when I only need to change just
one is a waste of CPU cycles that can be avoided with a proper
interface. The same applies to sampler states where we can very easily
eliminate redudant state changes per state slot. However it will be a
lot of refactoring and it'll take me some time. I asked Francisco to
add the start_slot parameter to the compute functions sooner rather
than later, so that we don't have to do heavy refactoring after people
start writing a lot of code around it.

Marek