[Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

[Ilia Mirkin]

On Mon, Feb 22, 2016 at 11:07 AM, Pierre Moreau <pierre.morrow at free.fr> wrote:
>> On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede <hdegoede at redhat.com>
>> wrote:
>> >> But assuming I'm right, what I'm proposing is that instead of
>> >> passing
>> >> the input in as a global buffer, to instead pass it in as a const
>> >> buffer. As such instead of sticking it into ->set_global_binding,
>> >> you'd stick it into ->set_constant_buffer, and then you'll be able
>> >> to
>> >> refer to it as CONST[0], CONST[1], etc. (Which are, implicitly,
>> >> CONST[0][0], CONST[0][1], etc -- it doesn't print the second dim
>> >> when
>> >> it's 0.) You don't even have to load these, you can use them as
>> >> args
>> >> directly anywhere you like (except as indirect addresses).
>> >>
>> >> The old code would actually take the supplied inputs, stick them
>> >> into
>> >> a constbuf, and then lower RINPUT accesses to load from that
>> >> constbuf.
>> >> I'm suggesting we cut out the middleman.
>> >>
>> >> By the way, another term for "constant buffer" is "uniform
>> >> buffer", on
>> >> the off chance it helps. Basically it's super-cached by the shader
>> >> for
>> >> values that never change across shader invocations. [And there's
>> >> special stuff in the hw to allow running multiple sets of shader
>> >> invocations with different "constant" values... or so we think.]
>> >
>> >
>> > I'm fine with using constant buffers for the input, it is not the
>> > mechanism I'm worried about it is the tgsi syntax to express
>> > things,
>> > I think it would be beneficial for the tgsi syntax to be abstract,
>> > and
>> > not worry about the underlying mechanism, this will i.e. allow us
>> > to use shared memory for input on tesla and const bufs on later
>> > generations
>> > without the part generating the tgsi code needing to worry about
>> > this.
>>
>> Yeah, I think you're right. I didn't realize that tesla had a special
>> form of input for user params, I assumed it was just the usual thing.
>> So forget about constbufs, go with the INPUT thing. Which is great,
>> since we had one value left over in that (future) 2-bit field :)
>
> I can have a try at using constbufs for user inputs on Tesla. It's just
> that the blob was using shared for them, so we kept shared.

I suspect there are hw advantages to doing it the way it was being
done. We should keep doing that.