On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > 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 :) > >> >> ### >> >> 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 _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
