search for: gart_avail

Displaying 19 results from an estimated 19 matches for "gart_avail".

2013 Jun 17
1
[PATCH] drm/nouveau: remove limit on gart
...ely((mem->num_pages << PAGE_SHIFT) >= 512 * 1024 * 1024)) - return -ENOMEM; - node = kzalloc(sizeof(*node), GFP_KERNEL); if (!node) return -ENOMEM; @@ -406,8 +403,6 @@ nouveau_ttm_init(struct nouveau_drm *drm) /* GART init */ if (drm->agp.stat != ENABLED) { drm->gem.gart_available = nouveau_vmmgr(drm->device)->limit; - if (drm->gem.gart_available > 512 * 1024 * 1024) - drm->gem.gart_available = 512 * 1024 * 1024; } else { drm->gem.gart_available = drm->agp.size; }
2018 Jan 11
0
[PATCH libdrm] nouveau: Support fence FDs
...------------ 3 files changed, 121 insertions(+), 34 deletions(-) diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h index cb077821c43f..e7f1a2aefd22 100644 --- a/include/drm/nouveau_drm.h +++ b/include/drm/nouveau_drm.h @@ -178,6 +178,28 @@ struct drm_nouveau_gem_pushbuf { __u64 gart_available; }; +#define NOUVEAU_GEM_PUSHBUF_FENCE_WAIT (1 << 0) +#define NOUVEAU_GEM_PUSHBUF_FENCE_EMIT (1 << 1) +#define NOUVEAU_GEM_PUSHBUF_FLAGS (NOUVEAU_GEM_PUSHBUF_FENCE_WAIT | \ + NOUVEAU_GEM_PUSHBUF_FENCE_EMIT) + +struct drm_nouveau_gem_pushbuf2 { +...
2012 Nov 25
1
[PATCH] drm/nouveau: unpin pushbuffer bo before destroying it
Fixes GART leak (as accounted by nouveau_drm.gem.gart_available). Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Running glxinfo in a loop is enough to trigger it - after several thousand runs (depending on GART size), X server crashes and does not come back in a correct state (corruptions and crashes). With this patch applied, it&...
2020 Aug 28
8
[PATCH 0/6] drm/nouveau: Support sync FDs and sync objects
From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be
2018 Jan 11
3
[PATCH 0/3] drm/nouveau: Add support for fence FDs
From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the
2020 Jan 24
1
[PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver v2
...> } > > + mutex_init(&drm->ttm.io_reserve_mutex); > + INIT_LIST_HEAD(&drm->ttm.io_reserve_lru); > + > NV_INFO(drm, "VRAM: %d MiB\n", (u32)(drm->gem.vram_available >> 20)); > NV_INFO(drm, "GART: %d MiB\n", (u32)(drm->gem.gart_available >> 20)); > return 0; >
2020 Jan 28
1
[PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver v2
...; + mutex_init(&drm->ttm.io_reserve_mutex); > + INIT_LIST_HEAD(&drm->ttm.io_reserve_lru); > + > NV_INFO(drm, "VRAM: %d MiB\n", (u32)(drm->gem.vram_available >> 20)); > NV_INFO(drm, "GART: %d MiB\n", (u32)(drm->gem.gart_available >> 20)); > return 0; > -- > 2.17.1 > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau
2020 Jan 24
4
TTM/Nouveau cleanups
Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian.
2020 Jan 24
0
[PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver v2
...struct nouveau_drm *drm) return ret; } + mutex_init(&drm->ttm.io_reserve_mutex); + INIT_LIST_HEAD(&drm->ttm.io_reserve_lru); + NV_INFO(drm, "VRAM: %d MiB\n", (u32)(drm->gem.vram_available >> 20)); NV_INFO(drm, "GART: %d MiB\n", (u32)(drm->gem.gart_available >> 20)); return 0; -- 2.17.1
2020 Aug 21
0
[PATCH 2/3] drm/nouveau: move io_reserve_lru handling into the driver v4
...struct nouveau_drm *drm) return ret; } + mutex_init(&drm->ttm.io_reserve_mutex); + INIT_LIST_HEAD(&drm->ttm.io_reserve_lru); + NV_INFO(drm, "VRAM: %d MiB\n", (u32)(drm->gem.vram_available >> 20)); NV_INFO(drm, "GART: %d MiB\n", (u32)(drm->gem.gart_available >> 20)); return 0; -- 2.17.1
2019 Oct 09
0
[PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver
...ret; > } > > + mutex_init(&drm->ttm.io_reserve_mutex); > + INIT_LIST_HEAD(&drm->ttm.io_reserve_lru); > + > NV_INFO(drm, "VRAM: %d MiB\n", (u32)(drm->gem.vram_available >> 20)); > NV_INFO(drm, "GART: %d MiB\n", (u32)(drm->gem.gart_available >> 20)); > return 0; > -- > 2.14.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
2014 Sep 26
14
[RFC] Explicit synchronization for Nouveau
Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes
2019 Sep 30
3
[PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver
...struct nouveau_drm *drm) return ret; } + mutex_init(&drm->ttm.io_reserve_mutex); + INIT_LIST_HEAD(&drm->ttm.io_reserve_lru); + NV_INFO(drm, "VRAM: %d MiB\n", (u32)(drm->gem.vram_available >> 20)); NV_INFO(drm, "GART: %d MiB\n", (u32)(drm->gem.gart_available >> 20)); return 0; -- 2.14.1
2020 Aug 20
3
Moving LRU handling into Nouveau v2
Hi guys, I already tried this a few month ago, but since I don't have NVidia hardware its rather hard to test for me (need to get some ordered). Dave brought up the topic that we should probably try to move the handling into Nouveau once more, so I tried to fix the problem Ben reported and rebased on top of current drm-misc-next. Dave can you test this? At least in theory the approach
2019 Nov 20
2
Move io_reserve_lru handling into the driver
Just a gentle ping on this. Already got the Acked-by from Daniel, but I need some of the nouveau guys to test this since I can only compile test it. Regards, Christian.
2020 May 11
10
[RFC] Remove AGP support from Radeon/Nouveau/TTM
Hi guys, Well let's face it AGP is a total headache to maintain and dead for at least 10+ years. We have a lot of x86 specific stuff in the architecture independent graphics memory management to get the caching right, abusing the DMA API on multiple occasions, need to distinct between AGP and driver specific page tables etc etc... So the idea here is to just go ahead and remove the support
2012 Mar 14
13
[Bug 47306] New: segfault in nouveau_fence_update
https://bugs.freedesktop.org/show_bug.cgi?id=47306 Bug #: 47306 Summary: segfault in nouveau_fence_update Classification: Unclassified Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau
2020 Sep 01
4
[PATCH 1/3] drm/ttm: make sure that we always zero init mem.bus v2
We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index e3931e515906..772c640a6046 100644 ---
2020 Aug 21
5
Moving LRU handling into Nouveau v3
Hi guys, so I got some hardware and tested this and after hammering out tons of typos it now seems to work fine. Could you give it more testing? Thanks in advance, Christian