search for: constbufs

...0->constbuf[s][i].user) + continue; + + res = nv50->constbuf[s][i].u.buf; + if (!res) + continue; + + if (res->flags & PIPE_RESOURCE_FLAG_MAP_COHERENT) + nv50->cb_dirty = TRUE; + } + } + + /* If there are any coherent constbufs, flush the cache */ + if (nv50->cb_dirty) { + BEGIN_NV04(push, NV50_3D(CODE_CB_FLUSH), 1); + PUSH_DATA (push, 0); + nv50->cb_dirty = FALSE; + } + if (nv50->vbo_fifo) { nv50_push_vbo(nv50, info); push->kick_notify = nv50_default_kick_notify; -- 1.8.5...

The number of vertex buffers has nothing to do with the number of bound constbufs. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.4 10.3" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_context.c | 5 +++-- src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions...

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

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

The hardware allows multiple simultaneous renders with the same memory-backed constbufs but with each invocation having different values. However in order for that to work, the data has to be streamed in via the right constbuf slot. We weren't doing that for UBOs. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2 10.1" <mesa-stable at lists.freedes...

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

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

Hello, We recently tracked down a bug on Tesla GPUs (i.e. G80-GT218) whereby it appears that instructions like 00000028: b5000409 08000780 add rn f32 $r2 $r2 neg c0[$a1] 00000040: b500060d 08004780 add rn f32 $r3 $r3 neg c0[$a1+0x4] or with nvdisasm: .headerflags @"EF_CUDA_SM12 EF_CUDA_PTX_SM(EF_CUDA_SM12)" /*0000*/ FADD R2, R2, -c[0x0][A1+0x0]; /*

Hi, On 22-02-16 16:24, Ilia Mirkin wrote: > On Mon, Feb 22, 2016 at 9:50 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> >> On 22-02-16 15:22, Ilia Mirkin wrote: >>> >>> On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede <hdegoede at redhat.com> >>> wrote: >>>> >>>> Hi, >>>>

...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 that, and this is what Samuel's patches are doing (at least from what I remember). Regards, Pierre > > You *really* want to be using constbufs here -- they're designed for this. > > -ilia > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau

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

Hi, On 22-02-16 15:22, Ilia Mirkin wrote: > 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

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

On Mon, Oct 27, 2014 at 6:34 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > GK20A does not have dedicated VRAM, therefore allocating in VRAM can be > sub-optimal and sometimes even harmful. Set its VRAM domain to > NOUVEAU_BO_GART so all objects are allocated in system memory. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- >

Since we upload all parameters on every program / constbuf change, we don't have to reserve space and can just use the whole buffer. Doesn't apply to the buffer holding immediates. --- src/gallium/drivers/nv50/nv50_program.c | 39 ++++++++---------------------- src/gallium/drivers/nv50/nv50_program.h | 6 ++-- 2 files changed, 14 insertions(+), 31 deletions(-) diff --git

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

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

So we have been busy implementing the compute engine lately but we have discovered a few issues with Compute Shaders. I hope you guys can answer some questions. 1st How do I determine the size of Compute Shaders/Kernel Local Memory ? In Pipeline shaders the size is included in the header but Compute Kernels don't have a header, so how do I determine how much local memory it uses? In case I

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

Hi, On 22-02-16 14:04, Samuel Pitoiset wrote: > > On 02/22/2016 01:46 PM, Hans de Goede wrote: >> Hi, >> >> On 22-02-16 13:41, Samuel Pitoiset wrote: >>> Hi there, >>> >>> On 02/22/2016 12:26 PM, Hans de Goede wrote: >> >> <snip> >> >>>> So back to the problem of getting OpenCL(ish) code to work again with