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

[Pierre Moreau]

----- Mail original -----
> 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.

Pierre

> 
> >
> > ###
> >
> > 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
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>