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