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

[Ilia Mirkin]

On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> 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 :)
>
>>
>> ###
>>
>> 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.

Another way of looking at it is that instead of having the hacky
RES[12345] being hardcoded to mean something special, you now have a
dedicated file called 'MEMORY', which has identical semantics.

  -ilia