search for: ttm

...MENT] ch 3 [00118000 supertuxkart[1074]] subc 7 class 4097 mthd 0208 data 02000248 [ 121.769931] nouveau 0000:08:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 3 [00118000 supertuxkart[1074]] subc 7 class 4097 mthd 0208 data 020 [ 124.918095] [TTM] Failed to find memory space for buffer 0xffff97a0c738dc00 eviction [ 124.925842] [TTM] No space for ffff97a0c738dc00 (1366 pages, 5464K, 5M) [ 124.932458] [TTM] placement[0]=0x00070002 (1) [ 124.936978] [TTM] has_type: 1 [ 124.940283] [TTM] use_type: 1 [ 124.943590] [TTM] flags:...

Hi guys, at least on amdgpu and radeon the page array allocated by ttm_dma_tt_init is completely unused in the case of DMA-buf sharing. So I'm trying to get rid of that by only allocating the DMA address array. Now the only other user of DMA-buf together with ttm_dma_tt_init is Nouveau. So my question is are you guys using the page array anywhere in your kerne...

Ping? Am 27.02.2018 um 13:07 schrieb Christian König: > Hi guys, > > at least on amdgpu and radeon the page array allocated by > ttm_dma_tt_init is completely unused in the case of DMA-buf sharing. > So I'm trying to get rid of that by only allocating the DMA address > array. > > Now the only other user of DMA-buf together with ttm_dma_tt_init is > Nouveau. So my question is are you guys using the page arra...

...oduct: xorg kernel 3.7 rc2 [ 7128.389874] nouveau E[ PGRAPH][0000:08:00.0] DATA_ERROR XY_OUT_OF_BOUNDS [ 7128.389880] nouveau [ PGRAPH][0000:08:00.0] DATA_ERROR [ 7128.389884] nouveau E[ PGRAPH][0000:08:00.0] ch 13 [0x001ecb0000] subc 5 class 0x5039 mthd 0x0328 data 0x00000000 [ 7128.631253] [TTM] Illegal buffer object size [ 7128.631570] nouveau E[ PGRAPH][0000:08:00.0] DATA_ERROR XY_OUT_OF_BOUNDS [ 7128.631574] nouveau [ PGRAPH][0000:08:00.0] DATA_ERROR [ 7128.631578] nouveau E[ PGRAPH][0000:08:00.0] ch 13 [0x001ecb0000] subc 5 class 0x5039 mthd 0x0328 data 0x00000000 [ 7128.636579]...

The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's location ani/or writecombine flags. On top TTM's functi...

Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel > address space. The mapping's address is returned as struct dma_buf_map. > Each function is a simplified version of TTM's existing kmap code. Both > functions respect the memory's location ani/or writecombine flags. > >...

The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's location ani/or writecombine flags. On top TTM's functi...

Drop the dummy ttm backend implementation, add a real one for TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call virtio_gpu_object_{attach,detach}, to update the object state on the host side, instead of invoking those calls from the move_notify() callback. With that in place the move and move_notify callba...

...it for now and only enable it if > there is a good reason to do so. > > Signed-off-by: Christian K?nig <christian.koenig at amd.com> So a lot more work, and more risk (but hey it's agp, how busted can it get) could be to demidlayer this. I.e. a small set of helpers to create a TTM_PL_TT manager, backed by agp. With zero agp code remaining in ttm itself, and all the ttm agp code moved out to a ttm-agp-helper.ko module that drivers would call. But again a lot of work, so really only an option if we can't sunset agp directly. -Daniel > --- > drivers/gpu/drm/Kconfig...

Drop the dummy ttm backend implementation, add a real one for TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call virtio_gpu_object_{attach,detach}, to update the object state on the host side, instead of invoking those calls from the move_notify() callback. With that in place the move and move_notify callba...

Hi On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian K?nig wrote: > > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > > > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in > > > kernel address space. The mapping's address is returned as struct > > > dma_buf_map. Each function is a simplified version of TTM's existing > > > kmap code. Both functions respect the memory's location ani/or...

...;> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>> GPU address handling is device specific and should be handle by its >>> device >>> driver. >>> >>> Signed-off-by: Nirmoy Das <nirmoy.das at amd.com> >>> --- >>> ? drivers/gpu/drm/ttm/ttm_bo.c??? | 7 ------- >>> ? include/drm/ttm/ttm_bo_api.h??? | 2 -- >>> ? include/drm/ttm/ttm_bo_driver.h | 1 - >>> ? 3 files changed, 10 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c >>> b/drivers/gpu/drm/ttm/ttm_bo.c >&gt...

On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian K?nig wrote: > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel > > address space. The mapping's address is returned as struct dma_buf_map. > > Each function is a simplified version of TTM's existing kmap code. Both > > functions respect the memory's location ani/or writecombine f...

...U cache after each write (http://lists.freedesktop.org/archives/dri-devel/2014-May/059893.html ) but it did not trigger a lot of approval. Instead, it has been suggested to map such BOs write-combined. This would break the "one mapping type only" rule, but I gave it a try by changing the TTM_PL_TT manager's authorized caching to WC. This immediatly resulted in breakage of applications using the GPU. Digging a little further, I noticed that kernel mappings could be performed WC or uncached without any problem, but that user-space mappings *must* be cached under all circumstances. Fa...

Hi Christian On 15.10.20 16:08, Christian K?nig wrote: > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: >> The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel >> address space. The mapping's address is returned as struct dma_buf_map. >> Each function is a simplified version of TTM's existing kmap code. Both >> functions respect the memory's location ani/or writecombine flag...

From: Lucas Stach <dev at lynxeye.de> On arches with non-coherent PCI, we need to flush caches ourselfes at the appropriate places. Introduce two small helpers to make things easy for TTM based drivers. Signed-off-by: Lucas Stach <dev at lynxeye.de> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/ttm/ttm_tt.c | 25 +++++++++++++++++++++++++ include/drm/ttm/ttm_bo_driver.h | 28 ++++++++++++++++++++++++++++ 2 files changed, 53 insertions...

From: Lucas Stach <dev at lynxeye.de> On architectures for which access to GPU memory is non-coherent, caches need to be flushed and invalidated explicitly at the appropriate places. Introduce two small helpers to make things easy for TTM-based drivers. Signed-off-by: Lucas Stach <dev at lynxeye.de> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/ttm/ttm_tt.c | 25 +++++++++++++++++++++++++ include/drm/ttm/ttm_bo_driver.h | 28 ++++++++++++++++++++++++++++ 2 files changed, 53 insertions...

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: Christian K?nig <ckoenig.leichtzumerken at gmail.com> That is not used any more. v2: keep the NULL checks in TTM. Signed-off-by: Christian K?nig <christian.koenig at amd.com> Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/ttm/ttm_bo.c | 34 +-------- drivers/gpu/drm/ttm/ttm_bo_util.c | 113 +++-------------------------- drivers/gpu/drm/ttm/ttm_bo_vm.c | 39 ++...

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 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -650,6 +650,9 @@ static int ttm_bo_evict(struct ttm_buff...