search for: nv40

...st be converted to a line strip, reemitting the first vertex at the end to close the loop 4. Quad strips are broken because 2 vertices must be repeated, and not 3 This patch rewrites the splitting code to work correctly for all primitives, including those with adjacency. It also rewrites the nv30/nv40 code to make use of the the new splitting code and simplifies it by making more code common between the different emission strategies (vbo, u8/u16/u32 indices, index buffer). Note that the splitting helper is now independent of nouveau and could be moved into gallium/auxiliary. --- src/gallium/dr...

...nd rc8 git. Maybe it's obvious. Sorry about that. Bob -------- Forwarded Message -------- From: Bob Gleitsmann <rjgleits at bellsouth.net> To: bskeggs at redhat.com Cc: nouveau at lists.freedesktop.org, dri-devel at lists.freedesktop.org Subject: [PATCH] Fix null dereference oopses for nv40 cards Date: Mon, 13 Jan 2014 01:45:36 -0500 The problem affects nv40 cards during booting. It comes from there being two places where subdev arrays are maintained. A commit was recently added to make the two equal. However, the struct nouveau_device version ends up being referenced before it is in...

- Added flush notify functions for NV30 and NV40. - NV30 and NV40 need testing. --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 42 ++++++++++++++++++------ src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++-- src/gallium/drivers/nv30/nv30_context.c | 3 ++ src/gallium/drivers/nv30/nv30_context.h | 1 + src/gal...

...t; >> Bob >> -------- Forwarded Message -------- >> From: Bob Gleitsmann <rjgleits at bellsouth.net> >> To: bskeggs at redhat.com >> Cc: nouveau at lists.freedesktop.org, dri-devel at lists.freedesktop.org >> Subject: [PATCH] Fix null dereference oopses for nv40 cards >> Date: Mon, 13 Jan 2014 01:45:36 -0500 >> >> The problem affects nv40 cards during booting. It comes from there being >> two places where subdev arrays are maintained. A commit was recently >> added to make the two equal. However, the struct nouveau_device vers...

...rams); + if (nv50->state.vtxfmt) + so_ref(NULL, &nv50->state.vtxfmt); + if (nv50->state.vtxbuf) + so_ref(NULL, &nv50->state.vtxbuf); + if (nv50->state.vtxattr) + so_ref(NULL, &nv50->state.vtxattr); + draw_destroy(nv50->draw); FREE(nv50); } Index: nv40/nv40_screen.c =================================================================== --- nv40/nv40_screen.c (wersja 32083) +++ nv40/nv40_screen.c (kopia robocza) @@ -140,7 +140,13 @@ nv40_screen_destroy(struct pipe_screen *pscreen) { struct nv40_screen *screen = nv40_screen(pscreen); + unsig...

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

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

- Added flush notify functions for NV30 and NV40. - NV30 and NV40 need testing (check for regressions). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 47 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++-- src/gallium/drivers/nv30/nv30_context.c | 3 ++ src/gallium/drivers/nv30/nv30_context.h...

...gt; Sorry about that. > > Bob > -------- Forwarded Message -------- > From: Bob Gleitsmann <rjgleits at bellsouth.net> > To: bskeggs at redhat.com > Cc: nouveau at lists.freedesktop.org, dri-devel at lists.freedesktop.org > Subject: [PATCH] Fix null dereference oopses for nv40 cards > Date: Mon, 13 Jan 2014 01:45:36 -0500 > > The problem affects nv40 cards during booting. It comes from there being > two places where subdev arrays are maintained. A commit was recently > added to make the two equal. However, the struct nouveau_device version > ends up bei...

The problem affects nv40 cards during booting. It comes from there being two places where subdev arrays are maintained. A commit was recently added to make the two equal. However, the struct nouveau_device version ends up being referenced before it is initialized. The problem arises during the creation of the INSTMEM and T...

Some archs defconfigs have CONFIG_FRAME_WARN set to 1024, which lead to this warning: drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c: warning: the frame size of 1184 bytes is larger than 1024 bytes Reported-by: Geert Uytterhoeven <geert at linux-m68k.org> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c | 12 +++++++++--- drivers/gpu/drm/nouveau/c...

...s not work for me on nv4b and sensor returns crazy values (>190?C). It stabilises later, but it's too late - therm code shutdowns the machine... Let's just reset it on init. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c index accc628..7d90844 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c +++ b/drivers/gpu/drm/nouveau/c...

Hi, I'm trying to find a place where objects held in nv40_context->state.hw[] and nv40_screen->state[] are being unreferenced during pipe_context destruction. Currently I'm observing that these objects are not unreferenced and since they hold reference to buffer objects, the buffer objects themselves are not unreferenced as well (for example...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/graph/nv40.h | 3 +++ drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c | 10 ++-------- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h b/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h index 7da35a4..ad82093 100644 --- a/drivers/gpu/drm/no...

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 13 +++++++++++++

--- src/gallium/drivers/nv40/nv40_fragprog.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nv40/nv40_fragprog.c b/src/gallium/drivers/nv40/nv40_fragprog.c index 1237066..209d211 100644 --- a/src/gallium/drivers/nv40/nv40_fragprog.c +++ b/src/gallium/drivers/nv40/nv40_fragprog.c...

...nv4c, the nv4c mc code is identical to the nv44 mc code except that it does not use msi (it does not define a msi_rearm callback). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90435 Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c index c630136..b4ad791 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine...

Currently the nv30 and nv40 Gallium drivers are very similar, and contain about 5000 lines of essentially duplicate code. I prepared a patchset (which can be found at http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) which gradually unifies the drivers, one file per the commit. A new "nvfx&quo...

nv40_sensor_setup() is never called in atomic context. It calls mdelay() to busily wait, which is not necessary. mdelay() can be replaced with msleep(). This is found by a static analysis tool named DCNS written by myself Signed-off-by: Jia-Ju Bai <baijiaju1990 at gmail.com> --- drivers/gpu/drm...

...fixed by specifying the start of the surface as the surface offset, and using the _POINT registers to program the (x, y) coordinates. This also allows us to avoid computing swizzled addresses on the CPU. This fixes progs/demos/ray and doesn't seem to introduce problems. Patch is for all <=NV40 cards, but tested on NV40 only. -------------- next part -------------- A non-text attachment was scrubbed... Name: texsubimage.patch Type: text/x-diff Size: 17148 bytes Desc: not available Url : http://lists.freedesktop.org/archives/nouveau/attachments/20091230/b54543ad/attachment-0001.patch