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

[Ilia Mirkin]

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 :)

>
> ###
>
> Somewhat unrelated to the input problem, I'm also somewhat worried
> about the addressing method for MEMORY type registers.
>
> Looking at the old RES stuff then the "index" passed into say a LOAD
> was not as much an index as it was simply a 32 bit GPU virtual memory
> address, which fits well with the OpenCL ways of doing things (the
> register number as in the 55 in RES[55] was more or less ignored).
>
> Where as, e.g. the new BUFFER style "registers" the index really
> is an index, e.g. doing:
> LOAD TEMP[0].x, BUFFER[0], IMM[0]
> resp.
> LOAD TEMP[0].x, BUFFER[1], IMM[0]
>
> Will read from a different memory address, correct ?

Correct -- BUFFER[0] refers to the buffer at binding point 0, and
BUFFER[1] refers to the buffer at binding point 1. They might, in
fact, overlap, or even be the same buffer. But the code doesn't know
about that.

>
> So how will this work for MEMORY type registers ? For OpenCL having the
> 1-dimensional behavior of RES really is quite useful, and having the
> address be composed of a hidden base address which gets determined under
> the hood from the register number, and then adding an index on top of
> it does not fit so well.

Not sure what the question is... you have code like

int *foo = [pointer value from user input];
*foo = *(foo + 5);

right?

So that'd just become

MOV TEMP[0].x, <val from user input, whereever it is>
ADD TEMP[0].y, TEMP[0].x, 5 * 4
LOAD TEMP[1].x, MEMORY[0] (which is global), TEMP[0].y
STORE MEMORY[0], TEMP[0].x, TEMP[1].x

or perhaps I'm misunderstanding something?

MEMORY, GLOBAL == the global virtual memory address space, not some
specific buffer. Trying to load address 0 from it will likely lead to
sadness, unless you happen to have something mapped there. BUFFER has
an implied base address, based on the binding point, but MEMORY has no
such thing.

  -ilia