similar to: [PATCH] drm/nouveau: Make use of TTM busy_placements.

Dynamically resizing the framebuffer on nv04 was like playing Russian roulette (and it often happened gratuitously) because it seems unable to scan out from buffers above 16MB. This patch splits the mappable VRAM into two chunks when that's the case, and makes the higher one to be used as well when applicable. Signed-off-by: Francisco Jerez <currojerez at riseup.net> ---

On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote: > This flag allows userspace to give the kernel a hint that it should use > a non-snooped resource. To guarantee coherency at all times mappings > into userspace are done write combined, so userspace should avoid > reading back from those resources. Do any other combinations of cached/uncached and

This flag allows userspace to give the kernel a hint that it should use a non-snooped resource. To guarantee coherency at all times mappings into userspace are done write combined, so userspace should avoid reading back from those resources. Signed-off-by: Lucas Stach <dev at lynxeye.de> --- On x86 an optimized userspace can save up on snoop traffic in the system, on ARM the benefits are

https://bugs.freedesktop.org/show_bug.cgi?id=92504 Bug ID: 92504 Summary: [NVA5] Corruption in Plasma 5 on resume after changing screen configuration Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

Drop drm_gem_object from nouveau_bo, use the ttm_buffer_object.base instead. Build tested only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 ----- drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--

Drop drm_gem_object from nouveau_bo, use the ttm_buffer_object.base instead. Build tested only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian König <christian.koenig at amd.com> --- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 ----- drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--

Drop drm_gem_object from nouveau_bo, use the ttm_buffer_object.base instead. Build tested only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian König <christian.koenig at amd.com> --- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 ----- drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--

Drop drm_gem_object from nouveau_bo, use the ttm_buffer_object.base instead. Build tested only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian König <christian.koenig at amd.com> --- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 ----- drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--

Drop drm_gem_object from nouveau_bo, use the ttm_buffer_object.base instead. Build tested only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian König <christian.koenig at amd.com> --- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 ----- drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--

From: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com> Attempting to migrate the bo will break the sharing of the buffer. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com> CC: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_prime.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

VRAM->system is a synchronous operation: it involves scheduling a VRAM->TT DMA transfer and stalling the CPU until it's finished so that we can unbind the new memory from the translation tables. VRAM->TT can always be performed asynchronously, even if TT is already full and we have to move something out of it. Additionally, allowing VRAM->system behaves badly under heavy memory

On 23 January 2015 at 08:53, Alexandre Courbot <acourbot at nvidia.com> wrote: > Having a RAM device does not make sense for chips like GK20A which have > no dedicated video memory. The dummy RAM device that we used so far > works as a temporary band-aid, but in the long-term it is desirable for > the driver to be able to work without any kind of VRAM. > > This patch adds a

Op 22-08-13 02:10, Ilia Mirkin schreef: > The code expects non-VRAM mem nodes to have a pages list. If that's not > set, it will do a null deref down the line. Warn on that condition and > return an error. > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > > Reported-by: Pasi K?rkk?inen <pasik at iki.fi> > Tested-by: Pasi K?rkk?inen <pasik at

On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi K?rkk?inen wrote: > On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > > Op 22-08-13 02:10, Ilia Mirkin schreef: > > > The code expects non-VRAM mem nodes to have a pages list. If that's not > > > set, it will do a null deref down the line. Warn on that condition and > > > return an error. >

On Thu, Sep 26, 2013 at 12:41 AM, Pasi K?rkk?inen <pasik at iki.fi> wrote: > Hello, > > On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote: >> Op 04-09-13 05:41, Ben Skeggs schreef: >> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst >> > <maarten.lankhorst at canonical.com> wrote: >> >> Op 22-08-13 02:10, Ilia Mirkin

Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the long-term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be

Op 04-09-13 05:41, Ben Skeggs schreef: > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> Op 22-08-13 02:10, Ilia Mirkin schreef: >>> The code expects non-VRAM mem nodes to have a pages list. If that's not >>> set, it will do a null deref down the line. Warn on that condition and >>> return an

Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the long-term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be

Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the long-term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be

Hello, On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote: > Op 04-09-13 05:41, Ben Skeggs schreef: > > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst > > <maarten.lankhorst at canonical.com> wrote: > >> Op 22-08-13 02:10, Ilia Mirkin schreef: > >>> The code expects non-VRAM mem nodes to have a pages list. If that's not >