similar to: [PATCH] drm/nouveau: require contiguous bo for framebuffer

Unpinning wasn't always handled correctly. The crtc_disable and nouveau_fbcon_destroy calls needed to unpin but didn't, resulting in a pin leak. While debugging this I found some leaks in the error paths of nouveau_user_framebuffer_create, so I fixed those too. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_display.c |

On Thu, May 9, 2024 at 3:44?PM Mohamed Ahmed < mohamedahmedegypt2001 at gmail.com> wrote: > Allows PTE kind and tile mode on BO create with VM_BIND, > and adds a GETPARAM to indicate this change. This is needed to support > modifiers in NVK and ensure correctness when dealing with the nouveau > GL driver. > > The userspace modifiers implementation this is for can be found

On Wed, May 8, 2024 at 6:06?PM Mohamed Ahmed < mohamedahmedegypt2001 at gmail.com> wrote: > Allows PTE kind and tile mode on BO create with VM_BIND, > and adds a GETPARAM to indicate this change. This is needed to support > modifiers in NVK and ensure correctness when dealing with the nouveau > GL driver. > > The userspace modifiers implementation this is for can be found

Do not attach fences automatically to buffers that are marked for explicit synchronization. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drm/nouveau_bo.c | 8 ++++---- drm/nouveau_bo.h | 4 ++-- drm/nouveau_drm.c | 1 + drm/nouveau_gem.c | 47 +++++++++++++++++++++++++++++++++++++++------- drm/nouveau_gem.h | 6 ++++--

Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot <acourbot

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

Doesn't this require a kernel version that has your other patch? What happens when this runs on an older kernel? Does it get silently ignored, or does it end up erroring out? If it errors out, that's fine. Otherwise some sort of version check should be put in, no? On Fri, Mar 13, 2015 at 2:27 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add a flag allowing Nouveau to

Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot <acourbot

op 11-11-13 17:05, Jerry Cooperstein schreef: > On 11/11/2013 09:57 AM, Maarten Lankhorst wrote: >> op 11-11-13 16:31, Jerry Cooperstein schreef: >>> Hi: >>> >>> commit bd9c5a2016307164c419c5e24a46921c10e620a0 >>> >>> (drm/nouveau: require contiguous bo for framebuffer) >>> produces about 2000 lines of >>> >>> nouveau

On 11/11/2013 09:57 AM, Maarten Lankhorst wrote: > op 11-11-13 16:31, Jerry Cooperstein schreef: >> Hi: >> >> commit bd9c5a2016307164c419c5e24a46921c10e620a0 >> >> (drm/nouveau: require contiguous bo for framebuffer) >> produces about 2000 lines of >> >> nouveau E[ DRM] framebuffer requires contiguous bo >> >> on system boot and

op 11-11-13 16:31, Jerry Cooperstein schreef: > Hi: > > commit bd9c5a2016307164c419c5e24a46921c10e620a0 > > (drm/nouveau: require contiguous bo for framebuffer) > produces about 2000 lines of > > nouveau E[ DRM] framebuffer requires contiguous bo > > on system boot and more on shutdown, but I don't see other > negative effects. I tried deploying a trivial

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

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

The buffer object stored in nvbo is also available GEM object in obj[0] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouveau_user_framebuffer_create_handle() with generic GEM helpers. Calls to nouveau_framebuffer_new()

On Tue, Feb 17, 2015 at 5:47 PM, 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

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

Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. Signed-off-by: James Jones <jajones at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++++++++++++++++++++++ 1 file changed, 93 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c

Drop vma_node from ttm_buffer_object, use the gem struct (base.vma_node) instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h

Drop vma_node from ttm_buffer_object, use the gem struct (base.vma_node) instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h