search for: set_global_bind

...ers. I'm not saying that this cannot work with your suggestion, > but it is something to keep in mind. > > I've not yet looked closely at const bufs, I've only been working with > global buffers so far, here is how I understand those to work: > > -clover calls pipe->set_global_binding() before calling launch_grid() > -clover has set up the uint32_t **handles pointer array to point to > one uint32_t in the buffer which it is going to pass as "input" to > launch_grid for each global buffer > -In the tgsi code for the kernel I can get to the global buffer...

On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > On 22-02-16 14:47, Ilia Mirkin wrote: >> >> 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

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

...to find different const buffers. I'm not saying that this cannot work with your suggestion, but it is something to keep in mind. I've not yet looked closely at const bufs, I've only been working with global buffers so far, here is how I understand those to work: -clover calls pipe->set_global_binding() before calling launch_grid() -clover has set up the uint32_t **handles pointer array to point to one uint32_t in the buffer which it is going to pass as "input" to launch_grid for each global buffer -In the tgsi code for the kernel I can get to the global buffer pointed to by t...

...that this cannot work with your suggestion, >> but it is something to keep in mind. >> >> I've not yet looked closely at const bufs, I've only been working with >> global buffers so far, here is how I understand those to work: >> >> -clover calls pipe->set_global_binding() before calling launch_grid() >> -clover has set up the uint32_t **handles pointer array to point to >> one uint32_t in the buffer which it is going to pass as "input" to >> launch_grid for each global buffer >> -In the tgsi code for the kernel I can get to...

...ers/nouveau/nvc0/nvc0_state.c b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c index 4b8632a..0213a8e 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c @@ -1229,4 +1229,6 @@ nvc0_init_state_functions(struct nvc0_context *nvc0) pipe->set_global_binding = nvc0_set_global_bindings; pipe->set_compute_resources = nvc0_set_compute_resources; pipe->set_shader_resources = nvc0_set_shader_resources; + + nvc0->sample_mask = ~0; } -- 1.8.3.2

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

...e 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 > &...

...16 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; >>> 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 >>>&...

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