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

[Jose Fonseca]

----- Original Message -----
> 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.

Fair enough. I agree start_slot is useful (even DX10 has is it in several places), and if the plan is to add them shortly elsewhere, then it's fine by me to start with compute already.

Jose