similar to: concern about bo "pinned'ness" after gem pushbuf is done

Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_stateobj.h b/src/gallium/drivers/nouveau/nouveau_stateobj.h index 9aee9e4..6c40f64 100644 --- a/src/gallium/drivers/nouveau/nouveau_stateobj.h +++

On Mon, Jun 23, 2014 at 5:17 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > op 21-06-14 14:12, Ilia Mirkin schreef: >> On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst >> <maarten.lankhorst at canonical.com> wrote: >>> nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the >>> entire

- Added flush notify functions for NV30 and NV40. - NV30 and NV40 need testing (check for regressions). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 47 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++-- src/gallium/drivers/nv30/nv30_context.c | 3 ++ src/gallium/drivers/nv30/nv30_context.h | 1 +

- 'joi' on irc pointed out that this triggers a BUG_ON, because kzalloc could sleep. - The irq handler should restore the value NV03_PFIFO_CACHES, but still it's better if this stuff doesn't happen in the middle of fifo create context. I see no reason in spin locking pgraph create context, it isn't activated at that stage. - Move and rename the lock after some discussion with

On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the > entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the

- Currently reloc'ing a user bo to gart will first cause an allocation in vram, which is then cpu written to, then the bo gets moved to gart. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- nouveau/nouveau_reloc.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/nouveau/nouveau_reloc.c b/nouveau/nouveau_reloc.c index 301482b..332dfa0 100644

https://bugs.freedesktop.org/show_bug.cgi?id=93254 Bug ID: 93254 Summary: [NVA5] The Long Dark (game) is very slow because of "kernel rejected pushbuf" messages in log files Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority:

If you're especially unlucky BOs would move around and their kmaps would end up pointing to something else in GART, then ioctl_pushbuf() would use the kmaps again corrupting textures or other pushbufs (the most noticeable symptom was a PFIFO_DMA_PUSHER from time to time). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 ++ 1

Commit "drm/nouveau: port all engines to new engine module format" changed IB size calculation to be less wasteful, but didn't take into account already existing off-by-one bugs :). So: - ib_max is the last entry, so we need to +1 when calculating number of free entries - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1 on nouveau_gem_ioctl_pushbuf

This is primarily targeted at Koala_BR, but if someone happens to have a a fully working nouveay g80 setup, then go ahead. Maarten. (this is attempt 2, as 100 KiB seems to be the maximum allowed size) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-NV50-Merge-crtc-creation.patch Type: text/x-patch Size: 2751 bytes Desc: not available Url :

http://bugs.freedesktop.org/show_bug.cgi?id=14394 Summary: [NV4B] Composite broken on 2nd head Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

Hi, I am getting a crash in nouveau in my application. It's basically a java application, and I am loading a bitmap into an opengl texture and showing it in a panel. Below is a snippet of the console output. Sometimes I will get a lock up instead of a crash. My whole desktop will lock up, but I can still move the mouse pointer around. Please let me know if you need more information. Your

Thanks for your response. I am able to capture a few more lines of the dump (see console-output.txt). dmesg output attached. My bitmap is 720x512. Below is the library versions, and amount of vram. Any feedback is appreciated. Thanks. Steve [steve at localhost ~]$ lspci -nn -d 10de: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) 01:00.1

https://bugs.freedesktop.org/show_bug.cgi?id=107963 Bug ID: 107963 Summary: kernel rejected pushbuf: Invalid argument Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

This patch changes the pushbuffer ABI to: 1. No longer use/expose nouveau_pushbuffer. Everything is directly in nouveau_channel. This saves the extra "pushbuf" pointer dereference. 2. Use cur/end pointers instead of tracking the remaining size. Pushing data now only needs to alter cur and not both cur and remaining. The goal is to make the *_RING macros faster and make the

On Thu, Jul 04, 2019 at 12:17:48PM -0700, Chia-I Wu wrote: > On Thu, Jul 4, 2019 at 4:10 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Hi, > > > > > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > > > Can you elaborate a

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

https://bugs.freedesktop.org/show_bug.cgi?id=33977 Summary: X core font rendering is "laggy" Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

http://bugs.freedesktop.org/show_bug.cgi?id=14174 Summary: nouveau uses symbols from private header exa_priv.h Product: xorg Version: git Platform: All OS/Version: All Status: NEW Severity: minor Priority: low Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org