similar to: [PATCH] nv50: remove vtxbuf stateobject after a referenced vtxbuf is mapped

Displaying 20 results from an estimated 900 matches similar to: "[PATCH] nv50: remove vtxbuf stateobject after a referenced vtxbuf is mapped"

2009 Dec 20
2
[PATCH 1/2] nv50: don't emit reloc markers after a referenced vtxbuf is mapped
- This avoids some 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 | 20 +++++++++++++++++++-
2009 Dec 30
4
[PATCH 1/3] nv50: remove vtxbuf stateobject after a referenced vtxbuf is mapped
- 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 +++++++++++++
2014 Jun 16
2
[PATCH 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4
2014 Jun 17
2
[PATCH try 2 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-
2009 Oct 10
0
[PATCH 1/7] nv50: use SIFC for TIC, TSC upload
Add proper flushes for TIC and TSC and remove the costly 2D.0110 flush in nv50_flush. Correct TIC and TSC bo sizes. --- src/gallium/drivers/nv50/nv50_context.c | 7 --- src/gallium/drivers/nv50/nv50_context.h | 5 ++ src/gallium/drivers/nv50/nv50_screen.c | 25 ++--------- src/gallium/drivers/nv50/nv50_state_validate.c | 53 +++++++++++++++++++++---
2009 Dec 21
2
[PATCH 1/2] Unreference state/buffer objects on context/screen destruction
- unreference state objects so that buffer objects are unreferenced and eventually destroyed - free channel at screen's destruction Index: nv50/nv50_screen.c =================================================================== --- nv50/nv50_screen.c (wersja 32083) +++ nv50/nv50_screen.c (kopia robocza) @@ -162,7 +162,22 @@ nv50_screen_destroy(struct pipe_screen *pscreen) { struct
2009 Dec 05
0
[PATCH] nouveau: avoid running out of relocs (attempt 3)
- NV30 and NV40 need testing. - I'll take better naming suggestions for so_get_push_reloc(). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 49 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++- src/gallium/drivers/nv30/nv30_state_emit.c | 26 ++++++++++++ src/gallium/drivers/nv40/nv40_state_emit.c | 30 ++++++++++++++
2014 Jun 17
0
[PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
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 +
2014 Jun 21
3
[Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
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
2015 Dec 07
2
[mesa v2 5/9] nouveau: fix screen creation failure paths
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? On Thu, Nov 26, 2015 at 8:04 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > From: Ben Skeggs <bskeggs at redhat.com> > > The winsys layer would attempt to cleanup the nouveau_device if screen > init failed, however, in
2010 May 03
2
_mesa_init_texture_s3tc() vs util_format_s3tc_init()
I am trying to understand the s3tc init code as nv50 gallium has a problem with that. It looks like some drivers (r300g and llvmpipe) actually inits s3tc in two places : ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() Here is an extract of the backtrace calls while loading fgfs on llvmpipe : driCreateScreen ->
2015 Dec 07
1
[mesa v2 5/9] nouveau: fix screen creation failure paths
On Sun, Dec 6, 2015 at 10:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > 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
2009 Oct 14
0
[PATCH 3/7] nv50: submit user vbo data through the fifo
Requesting a new real buffer from the kernel and copying all the data is wasteful e.g. if only a few (but widely spread) vertices are accessed. --- src/gallium/drivers/nv50/nv50_context.h | 3 + src/gallium/drivers/nv50/nv50_vbo.c | 409 +++++++++++++++++++++++++++++-- 2 files changed, 394 insertions(+), 18 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_context.h
2014 May 20
14
[PATCH 00/12] Cherry-pick nv50/nvc0 patches from gallium-nine
I went through the gallium-nine tree and picked out nouveau patches that are general bug-fixes. The first bunch I'd like to also get into 10.2. I've reviewed all of them and they make sense to me, but sending them out for public review as well in case there are any objections. Unless I hear objections, I'd like to push this by Friday. Christoph Bumiller (11): nv50,nvc0: always pull
2009 Dec 25
0
[MESA PATCH 5/5] nv50: update after nouveau_class.h update
--- src/gallium/drivers/nv50/nv50_program.c | 2 +- src/gallium/drivers/nv50/nv50_screen.c | 17 ++++++++--------- src/gallium/drivers/nv50/nv50_state_validate.c | 10 +++++----- src/gallium/drivers/nv50/nv50_transfer.c | 8 ++++---- src/gallium/drivers/nv50/nv50_vbo.c | 24 ++++++++++++------------ 5 files changed, 30 insertions(+), 31 deletions(-)
2015 Nov 27
0
[mesa v2 5/9] nouveau: fix screen creation failure paths
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:
2015 Dec 07
0
[mesa v2 5/9] nouveau: fix screen creation failure paths
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
2014 Apr 30
1
[PATCH 1/2] nouveau: remove cb_dirty, it's never used
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 4 +--- src/gallium/drivers/nouveau/nouveau_context.h | 1 - 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c b/src/gallium/drivers/nouveau/nouveau_buffer.c index e308ff4..904e2cc 100644 ---
2014 Jan 13
20
[PATCH 00/19] nv50: add sampler2DMS/GP support to get OpenGL 3.2
OK, so there's a bunch of stuff in here. The geometry stuff is based on the work started by Bryan Cain and Christoph Bumiller. Patches 01-12: Add support for geometry shaders and fix related issues Patches 13-14: Make it possible for fb clears to operate on texture attachments with an explicit layer set (as is allowed in gl 3.2). Patches 15-17: Make ARB_texture_multisample work
2010 May 02
0
nv50 dxt / s3tc
flightgear now dies with : Mesa warning: external dxt library not available: texstore_rgba_dxt3 util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' failed. I don't really understand what these stubs are about, they were introduced by following commit : commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 Author: Jos? Fonseca <jfonseca at vmware.com> Date: Wed Apr 7