search for: vram_available

...NOUVEAU_GEM_PUSHBUF_FENCE_EMIT) + +struct drm_nouveau_gem_pushbuf2 { + uint32_t channel; + uint32_t nr_buffers; + uint64_t buffers; + uint32_t nr_relocs; + uint32_t nr_push; + uint64_t relocs; + uint64_t push; + uint32_t suffix0; + uint32_t suffix1; + uint64_t vram_available; + uint64_t gart_available; + uint32_t flags; + int32_t fence; + uint64_t reserved; +}; + #define NOUVEAU_GEM_CPU_PREP_NOWAIT 0x00000001 #define NOUVEAU_GEM_CPU_PREP_NOBLOCK 0x00000002 #define NOUVEAU_GEM_CPU_PREP_WRITE...

...471331b5..6ec745873bc5 100644 --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c @@ -214,6 +214,7 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS) WARN_ON(1); break; } + break; case NOUVEAU_GETPARAM_FB_SIZE: getparam->value = drm->gem.vram_available; break; -- 2.17.1

...return ret; + + vma->vm_ops = &nouveau_ttm_vm_ops; + return 0; } static int @@ -173,7 +211,6 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm) } man->func = &nouveau_vram_manager; - man->use_io_reserve_lru = true; ttm_resource_manager_init(man, drm->gem.vram_available >> PAGE_SHIFT); @@ -339,6 +376,9 @@ nouveau_ttm_init(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));...

...6.c >> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c >> @@ -214,6 +214,7 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS) >> WARN_ON(1); >> break; >> } >> + break; >> case NOUVEAU_GETPARAM_FB_SIZE: >> getparam->value = drm->gem.vram_available; >> break; >>

...dac8f3a2..a95ec3783f39 100644 --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c @@ -214,6 +214,7 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS) WARN_ON(1); break; } + break; case NOUVEAU_GETPARAM_FB_SIZE: getparam->value = drm->gem.vram_available; break; -- 2.20.1

...471331b5..6ec745873bc5 100644 --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c @@ -214,6 +214,7 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS) WARN_ON(1); break; } + break; case NOUVEAU_GETPARAM_FB_SIZE: getparam->value = drm->gem.vram_available; break; -- 2.20.1

...ers/gpu/drm/nouveau/nouveau_abi16.c > +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c > @@ -214,6 +214,7 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS) > WARN_ON(1); > break; > } > + break; > case NOUVEAU_GETPARAM_FB_SIZE: > getparam->value = drm->gem.vram_available; > break; >

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

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

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

...tatic int > @@ -273,6 +311,9 @@ nouveau_ttm_init(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; >

...@@ nouveau_ttm_init(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 > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > https://list...

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.

...&nouveau_ttm_vm_ops; + return 0; } static int @@ -273,6 +311,9 @@ nouveau_ttm_init(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

...; static int > @@ -272,6 +310,9 @@ nouveau_ttm_init(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 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

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

...&nouveau_ttm_vm_ops; + return 0; } static int @@ -272,6 +310,9 @@ nouveau_ttm_init(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

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

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

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.