similar to: [PATCH] nv30: report the correct max varying limit

First off, nv50_program only has 16 in/out varyings. However reporting 16 makes 'm' become 68 in nv50_fp_linkage_validate with the varying-packing-simple piglit test. (Subverting the assert makes it compile but fail.) With this patch, varying-packing-simple passes. See: https://bugs.freedesktop.org/show_bug.cgi?id=69155 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc:

On 26.05.2015 02:49, Ilia Mirkin wrote: > On Mon, May 25, 2015 at 8:37 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 25.05.2015 21:29, Ilia Mirkin wrote: >>> Commit 8acaf862dfe switched things over to use TEXCOORD instead of >>> GENERIC, but did not update the nv30 swtnl draw paths. This teaches the >>> draw

On 25.05.2015 21:29, Ilia Mirkin wrote: > Commit 8acaf862dfe switched things over to use TEXCOORD instead of > GENERIC, but did not update the nv30 swtnl draw paths. This teaches the > draw logic about TEXCOORD. > > Among other things, this fixes a crash in demos/arbocclude when using > swtnl. Curiously enough, the point-sprite piglit works without this. > > Signed-off-by:

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote: > On nv3x we will likely end up using the cpu to do color resolving for msaa > blits. Disable msaa on these cards so that we do not end up using the cpu. Actually the CPU fallback won't do scaled, so it's stuck with SIFM or assert(false). Which isn't great, but... it's what the HW does. I

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Perhaps there was a day when those were different, but that day is not today. src/gallium/drivers/nouveau/nv30/nv30_context.c | 1 - src/gallium/drivers/nouveau/nv30/nv30_context.h | 1 - src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 20 ++++++++++---------- src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c | 8 ++++---- 4

https://bugs.freedesktop.org/show_bug.cgi?id=69155 Priority: medium Bug ID: 69155 Assignee: nouveau at lists.freedesktop.org Summary: codegen/nv50_ir_emit_nv50.cpp:169:srcAddr8: Assertion `(offset <= 0x1fc || offset == 0x3fc) && !(offset & 0x3)' failed. Severity: critical

May I ask why you're doing 512x512 instead of 1024x1024? These are already scaled up coordinates, so 1024x1024 should work no? Or is it because of the seams on the edges? Do those not also appear with 512x512 or does it sample outside of the box? Separately, why not use this approach on nv40 as well? I can't imagine the blitter would be faster... does this result in lower quality? On

A reworked version of 3 out of 4 patches mentioned earlier. [1/4]: Fixes nearly all piglit vertprog testcases, due to now being able to pass the results on to the fragment shader. V2: rename samplers to texcoords. [2/4]: Fixes shader compiler assertion errors, as some source registers do not exist for certain operations. Fixes several piglit tests when mesa is compiled with --enable-debug [3/4]:

Add missing PIPE_SHADER_CAP_INTEGERS for frag shaders to nv30_screen_get_shader_param(). Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index db7c2d1..ece8af7 100644 ---

nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 14 +- src/gallium/drivers/nouveau/nouveau_context.h | 5 +

On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the > entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the

From: Ben Skeggs <bskeggs at redhat.com> The winsys layer would attempt to cleanup the nouveau_device if screen init failed, however, in most paths the pipe driver would have already destroyed it, resulting in accesses to freed memory etc. This commit fixes the problem by allowing the winsys to detect whether the pipe driver's destroy function needs to be called or not. Signed-off-by:

On 12/07/2015 01:40 PM, Ilia Mirkin wrote: > This all seems very roundabout... Can't we do this in a somewhat > consistent way with the device being cleaned up in one place or > another but not both? That would be lovely, but not possible. It has to be cleaned up by the pipe screen destroy() function, as that's the normal exit path. If the pipe driver creation path fails before

Errrr.... are you sure? nv30_screen_create starts with a bunch of stuff init'ing objects, and then does: BEGIN_NV04(push, NV01_SUBC(3D, OBJECT), 1); PUSH_DATA (push, screen->eng3d->handle); And as you can see in nv30_winsys.h: static inline void BEGIN_NV04(struct nouveau_pushbuf *push, int subc, int mthd, int size) { PUSH_SPACE(push, size + 1); PUSH_DATA (push, 0x00000000

Currently on NV30/NV40 an assert will be triggered once 32 queries are outstanding. This violates the OpenGL/Gallium interface, which requires support for an unlimited number of fences. This patch fixes the problem by putting queries in a linked list and waiting on the oldest one if allocation fails. nVidia seems to use a similar strategy, but with 1024 instead of 32 fences. The next patch will

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Silences a warning about unrecognized param when in debug mode. src/gallium/drivers/nv30/nv30_screen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nv30/nv30_screen.c b/src/gallium/drivers/nv30/nv30_screen.c index 40e8b5f..39e64ce 100644 --- a/src/gallium/drivers/nv30/nv30_screen.c +++

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 6 ++++++ src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 1 + 2 files changed, 7 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index

It should be possible to make this be 16 on nvc0. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not touching nv50 since I have a patch that actually impelents support for multiple viewports there. src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++ 2 files changed, 4 insertions(+) diff --git

Currently on NV30/NV40 an assert will be triggered once 32 queries are outstanding. This violates the OpenGL/Gallium interface, which requires support for an unlimited number of fences. This patch fixes the problem by putting queries in a linked list and waiting on the oldest one if allocation fails. nVidia seems to use a similar strategy, but with 1024 instead of 32 fences. The next patch will

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 33 +++++++++++++------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 4baabaf..5c3d783 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++