Displaying 14 results from an estimated 14 matches for "sysmem_bind".
2014 Oct 29
3
[PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain
...chipset) {
> + /* GK20A */
> + case 0xea:
> + screen->base.vram_domain = NOUVEAU_BO_GART;
I think you also want to set vidmem_bindings = 0... although
potentially after the |= that's done below. Although I guess that
constbuf + command args buf need to be |='d into the sysmem_bindings
for this to work out well. That said, we don't really handle explicit
migration well right now, and those PIPE_BIND_* are *incredibly*
misleading and don't actually necessarily reflect the current usage.
[I have some patches to improve the situation, but you don't really
have to wor...
2015 Jun 19
5
[PATCH v3 0/2] nouveau: support for custom VRAM domains
New revision of this patchset that prevents VRAM objects from being
allocated on VRAM-less systems like Tegra. This is required for Mesa
to work on such systems.
Changes since v2:
- Use vram_size to detect systems without VRAM and set the correct
domain instead of expecting each chip to set its domain explicitly.
Alexandre Courbot (2):
nouveau: support for custom VRAM domains
nvc0: use
2014 Nov 19
5
[PATCH v2 0/3] nouveau: support for custom VRAM domains
This series is to allow NVIDIA chips with shared memory to operate more
efficiently (and to operate at all once we disable VRAM from the kernel
driver) by allowing nouveau_screen to specify a domain to use for objects
originally allocated into VRAM. If the domain is not overridden, the default
NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be
used in place of
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 Nov 05
0
[PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain
...A */
>> + case 0xea:
>> + screen->base.vram_domain = NOUVEAU_BO_GART;
>
> I think you also want to set vidmem_bindings = 0... although
> potentially after the |= that's done below. Although I guess that
> constbuf + command args buf need to be |='d into the sysmem_bindings
> for this to work out well.
Thanks for pointing this out ; I didn't know about vidmem_bindings to be
honest. Will update and resend.
Apart from this detail, are you ok with the changes brought by these
patches?
Cheers,
Alex.
2014 Nov 19
1
[PATCH v2 2/3] nvc0: use NV_VRAM_DOMAIN() macro
...reen *pscreen,
> }
> } else {
> if (buffer->base.bind & screen->vidmem_bindings)
> - buffer->domain = NOUVEAU_BO_VRAM;
> + buffer->domain = NV_VRAM_DOMAIN(screen);
> else
> if (buffer->base.bind & screen->sysmem_bindings)
> buffer->domain = NOUVEAU_BO_GART;
Both of these changes should be unnecessary if vidmem_bindings is
cleared out, right?
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> index 1aacaec89acf..ddff508c475c...
2014 Oct 27
4
[PATCH 0/3] nouveau: support for custom VRAM domains
This series is to allow NVIDIA chips with shared memory to operate more
efficiently (and to operate at all once we disable VRAM from the kernel
driver) by allowing nouveau_screen to specify a domain to use for objects
originally allocated into VRAM. If the domain is not overridden, the default
NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be
used in place of
2014 Jul 10
3
[PATCH 0/3] nvc0: ARB_(multi_)draw_indirect support
The main patches are from Christoph. Unfortunately they're a little beyond my
understanding of all the vertex-related details, but they generally seemed
fine. I'm just going to push these unless someone steps up to review them.
Christoph Bumiller (2):
nvc0: add support for indirect drawing
nvc0: fix translate path for PRIM_RESTART_WITH_DRAW_ARRAYS
Ilia Mirkin (1):
nouveau: check if
2014 Nov 19
0
[PATCH v2 2/3] nvc0: use NV_VRAM_DOMAIN() macro
...ouveau_buffer_create(struct pipe_screen *pscreen,
}
} else {
if (buffer->base.bind & screen->vidmem_bindings)
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
else
if (buffer->base.bind & screen->sysmem_bindings)
buffer->domain = NOUVEAU_BO_GART;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
index 1aacaec89acf..ddff508c475c 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nouveau/nv50/nv5...
2014 Nov 19
1
[PATCH v2 2/3] nvc0: use NV_VRAM_DOMAIN() macro
...*pscreen,
> }
> } else {
> if (buffer->base.bind & screen->vidmem_bindings)
> - buffer->domain = NOUVEAU_BO_VRAM;
> + buffer->domain = NV_VRAM_DOMAIN(screen);
> else
> if (buffer->base.bind & screen->sysmem_bindings)
> buffer->domain = NOUVEAU_BO_GART;
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> index 1aacaec89acf..ddff508c475c 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> +++ b/src/galliu...
2014 Jun 17
0
[PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
...ce)
{
- struct nouveau_pushbuf *push = screen->base.pushbuf;
+ struct nouveau_pushbuf *push = nv50->base.pushbuf;
+ struct nv50_screen *screen = nv50->screen;
int ret;
uint64_t tls_size;
@@ -685,9 +637,6 @@ nv50_screen_create(struct nouveau_device *dev)
screen->base.sysmem_bindings |=
PIPE_BIND_VERTEX_BUFFER | PIPE_BIND_INDEX_BUFFER;
- screen->base.pushbuf->user_priv = screen;
- screen->base.pushbuf->rsvd_kick = 5;
-
chan = screen->base.channel;
pscreen->destroy = nv50_screen_destroy;
@@ -714,20 +663,6 @@ nv50_screen_create(struct...
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 +-
2014 Jun 21
3
[Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
...*push = screen->base.pushbuf;
> + struct nouveau_pushbuf *push = nv50->base.pushbuf;
> + struct nv50_screen *screen = nv50->screen;
> int ret;
> uint64_t tls_size;
>
> @@ -685,9 +637,6 @@ nv50_screen_create(struct nouveau_device *dev)
> screen->base.sysmem_bindings |=
> PIPE_BIND_VERTEX_BUFFER | PIPE_BIND_INDEX_BUFFER;
>
> - screen->base.pushbuf->user_priv = screen;
> - screen->base.pushbuf->rsvd_kick = 5;
> -
> chan = screen->base.channel;
>
> pscreen->destroy = nv50_screen_destroy;
> @@ -71...
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