----- Mail original ----- > On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede <hdego...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau > _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau