similar to: [PATCH 01/19] fence: add debugging lines to fence_is_signaled for the callback

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers are converted to the fence api, fence_lock is removed and rcu is used in its place. qxl is the first

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. :-) I've done at least basic

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

Only one type was ever used. This is needed to simplify the fence support in the next commit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 5 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 ++------- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 50

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

--- drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +------- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +--- drivers/gpu/drm/nouveau/nouveau_fence.h | 2 drivers/gpu/drm/nouveau/nouveau_gem.c | 16 ++- drivers/gpu/drm/qxl/qxl_debugfs.c | 6 + drivers/gpu/drm/qxl/qxl_drv.h | 2 drivers/gpu/drm/qxl/qxl_kms.c | 1

Hi all, First thing first: It works, I now no longer have a few dropped frames every 10s on my testbox here with the pageflip i-g-t tests. Random notes: - New design has per-crtc locks to protect the crtc input-side (pageflip, cursor) for r/w and the output state of the crtc (mode, dpms) as read-only. It also required completely revamped fb lifecycle management, those are now refcounted

--- drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +------- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +--- drivers/gpu/drm/nouveau/nouveau_fence.h | 2 drivers/gpu/drm/nouveau/nouveau_gem.c | 16 ++- drivers/gpu/drm/qxl/qxl_debugfs.c | 6 + drivers/gpu/drm/qxl/qxl_drv.h | 2 drivers/gpu/drm/qxl/qxl_kms.c | 1

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

Am 19.05.2014 15:35, schrieb Maarten Lankhorst: > op 19-05-14 14:30, Christian K?nig schreef: >> Am 19.05.2014 12:10, schrieb Maarten Lankhorst: >>> op 19-05-14 10:27, Christian K?nig schreef: >>>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst: >>>> [SNIP] >>>> The problem here is that the whole approach collides with the way >>>>

> -----Original Message----- > From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com] > Sent: Wednesday, July 09, 2014 8:30 AM > To: airlied at linux.ie > Cc: thellstrom at vmware.com; nouveau at lists.freedesktop.org; linux- > kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; > bskeggs at redhat.com; Deucher, Alexander; Koenig, Christian >

Am 02.06.2014 12:09, schrieb Maarten Lankhorst: > Changes since v1: > - Fixed interaction with reset handling. > + Use exclusive_lock, either with trylock or blocking. > + Bump sw irq refcount in the recovery function to prevent fiddling > with irq registers during gpu recovery. > - Add radeon lockup detection to the default fence wait function. First of all please

Am 19.05.2014 10:00, schrieb Maarten Lankhorst: > op 15-05-14 18:13, Christian K?nig schreef: >> Am 15.05.2014 17:58, schrieb Maarten Lankhorst: >>> op 15-05-14 17:48, Christian K?nig schreef: >>>> Am 15.05.2014 16:18, schrieb Maarten Lankhorst: >>>>> op 15-05-14 15:19, Christian K?nig schreef: >>>>>> Am 15.05.2014 15:04, schrieb

Am 15.05.2014 11:38, schrieb Maarten Lankhorst: > op 15-05-14 11:21, Christian K?nig schreef: >> Am 15.05.2014 03:06, schrieb Maarten Lankhorst: >>> op 14-05-14 17:29, Christian K?nig schreef: >>>>> + /* did fence get signaled after we enabled the sw irq? */ >>>>> + if >>>>>

Am 02.06.2014 15:14, schrieb Maarten Lankhorst: > This makes it possible to wait for a specific amount of time, > rather than wait until infinity. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > Splitted out version, I've noticed that I forgot to convert > radeon_fence_wait_empty to long r, fixed. >

From: Dave Airlie <airlied at redhat.com> fences are signalled on nvidia hw using non-stall interrupts. non-stall interrupts are not latched from my reading. When nouveau emits a fence, it requests a NON_STALL signalling, but it only calls the interface to allow the non-stall irq to happen after it has already emitted the fence. A recent change eacabb546271 ("nouveau: push event

On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote: > From: Dave Airlie <airlied at redhat.com> > > fences are signalled on nvidia hw using non-stall interrupts. > > non-stall interrupts are not latched from my reading. > > When nouveau emits a fence, it requests a NON_STALL signalling, > but it only calls the interface to allow the non-stall irq to happen

Am 23.07.2014 12:52, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >>> And the dma-buf would still have fences belonging to both drivers, and it >>> would still call from outside the driver. >> >> Calling from outside the driver is fine as long as the driver can do >> everything

nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68 ++++++++++++++++++++++++++++++-

Wait loop can be interrupted by signal, so if signals are raised periodically (e.g. SIGALRM) this loop may never finish. Use emission time as a base for fence timeout. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c