similar to: What are the restrictions around loading indirect constbuf values

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(-) diff --git

On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > >> I've noticed that LLVM tends to generate suboptimal code and spill an >> excessive amount of registers in large functions, such as in those >> that are automatically generated by FFTW. >

On Sat, Jul 7, 2012 at 12:25 AM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: >>> [...] >>> movaps 32(%rdi), %xmm3 >>> movaps 48(%rdi), %xmm2 >>>

Hi, I've noticed that LLVM tends to generate suboptimal code and spill an excessive amount of registers in large functions, such as in those that are automatically generated by FFTW. LLVM generates good code for a function that computes an 8-point complex FFT, but from 16-point upwards, icc or gcc generates much better code. Here is an example of a sequence of instructions from a 32-point

On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > I've noticed that LLVM tends to generate suboptimal code and spill an > excessive amount of registers in large functions, such as in those > that are automatically generated by FFTW. One problem might be that we're forcing the 16 stores to the out array to happen in source order, which

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nv50/nv50_context.c | 22 ++++++++++++++++++- src/gallium/drivers/nouveau/nv50/nv50_context.h | 1 + src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 29 ++++++++++++++++++++++++- 3 files changed, 50 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c

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

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

Hi, I seem to have found a bug with seeking in opusfile in some situations, though this might be better directed to the ogg list. I?ve included a short description below and a test case C program that describes it more detail (comments) and reproduces the issue when used with a file which contains packets that have been split over a page boundary (less common than I thought). The test program is

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

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

On Mon, 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

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

Hello, > On 22 Feb 2016, at 15:22, Ilia Mirkin <imirkin at alum.mit.edu> 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: >>>>

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

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

Hi, On 22-02-16 17:13, Ilia Mirkin wrote: > On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> On Mon, 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

----- Mail original ----- > On Mon, 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, >

On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Mon, 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