search for: set_constant_buff

...s, which > nouveau can then just treat as CONST. That doesn't make sense... MEMORY is for... memory. Perhaps there's something I don't understand about kernel inputs that would make my suggestion unworkable? The way I see it is that you stick them into a user constbuf (i.e. pipe->set_constant_buffer({cb.user = pointer to your thing})), and then launch the grid. Your TGSI would have been composed such that it would expect the user params to show up in the first constbuf. You *really* want to be using constbufs here -- they're designed for this. -ilia

...gt;> >> >> That doesn't make sense... MEMORY is for... memory. Perhaps there's >> something I don't understand about kernel inputs that would make my >> suggestion unworkable? The way I see it is that you stick them into a >> user constbuf (i.e. pipe->set_constant_buffer({cb.user = pointer to >> your thing})), and then launch the grid. Your TGSI would have been >> composed such that it would expect the user params to show up in the >> first constbuf. > > > Keep in mind the flat address space issue opencl has, there is no > such thing...

...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 anywh...

...>>> That doesn't make sense... MEMORY is for... memory. Perhaps there's >>> something I don't understand about kernel inputs that would make my >>> suggestion unworkable? The way I see it is that you stick them into a >>> user constbuf (i.e. pipe->set_constant_buffer({cb.user = pointer to >>> your thing})), and then launch the grid. Your TGSI would have been >>> composed such that it would expect the user params to show up in the >>> first constbuf. >> >> >> Keep in mind the flat address space issue opencl has, the...

...then just treat as CONST. > > That doesn't make sense... MEMORY is for... memory. Perhaps there's > something I don't understand about kernel inputs that would make my > suggestion unworkable? The way I see it is that you stick them into a > user constbuf (i.e. pipe->set_constant_buffer({cb.user = pointer to > your thing})), and then launch the grid. Your TGSI would have been > composed such that it would expect the user params to show up in the > first constbuf. Apart from Tesla which uses shared memory for passing the OpenCL user params, Fermi+ use const memory for t...

...t;> 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...

On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > INPUT is for shader inputs which come from fixed function loaders. > This is not what you want. You want CONST. Stick the input params into > a constbuf, and you're done. Oh, and in case it's not clear, I think this should be done by the st, not by the driver. Not a big fan of the current

...; 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 c...

...rote: >>> 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 >>&gt...

...n then just treat as CONST. > > That doesn't make sense... MEMORY is for... memory. Perhaps there's > something I don't understand about kernel inputs that would make my > suggestion unworkable? The way I see it is that you stick them into a > user constbuf (i.e. pipe->set_constant_buffer({cb.user = pointer to > your thing})), and then launch the grid. Your TGSI would have been > composed such that it would expect the user params to show up in the > first constbuf. Keep in mind the flat address space issue opencl has, there is no such thing as the first constbuf, there i...

...ssuming 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...

...9;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,...

...e(struct pipe_context *pcontext, > + void *so) > +{ > + struct tegra_context *context = to_tegra_context(pcontext); > + > + context->gpu->delete_vertex_elements_state(context->gpu, so); > +} > + > +static void > +tegra_set_constant_buffer(struct pipe_context *pcontext, > + uint shader, > + uint index, > + struct pipe_constant_buffer *buf) > +{ > + struct tegra_context *context = to_tegra_context(pcontext); > + struct pipe_constant...

...nts_state(context->gpu, so); +} + +static void +tegra_delete_vertex_elements_state(struct pipe_context *pcontext, + void *so) +{ + struct tegra_context *context = to_tegra_context(pcontext); + + context->gpu->delete_vertex_elements_state(context->gpu, so); +} + +static void +tegra_set_constant_buffer(struct pipe_context *pcontext, + uint shader, + uint index, + struct pipe_constant_buffer *buf) +{ + struct tegra_context *context = to_tegra_context(pcontext); + struct pipe_constant_buffer buffer; + + if (buf && buf->buffer) { + memcpy(&buffer, buf, sizeof(buffer));...

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for