Re: [PATCH v3] drm: modify drm_global_item_ref to avoid two times of writing ref->object

On Thu, Sep 08, 2016 at 09:43:52AM +0200, Christian König wrote: > Am 08.09.2016 um 09:35 schrieb Chris Wilson: > >On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote: > >>On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote: > >>>On Wed, Sep 07, 2016

Re: [PATCH v3] drm: modify drm_global_item_ref to avoid two times of writing ref->object

al_type]; > > mutex_lock(>mutex); > if (item->refcount == 0) { > - item->object = kzalloc(ref->size, GFP_KERNEL); > - if (unlikely(item->object == NULL)) { > + ref->object = kzalloc(ref->size, GFP_KERNEL); So

Re: [PATCH v3] drm: modify drm_global_item_ref to avoid two times of writing ref->object

On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote: > On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote: > > On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote: > > > In previous drm_global_item_ref, there are two times of writing > > > ref->

Re: [PATCH 1/4] sync_file: add a mutex to protect fence and callback members. (v3)

file). However, if it is empty we also want to delay the dependent execution until the fence is set to match the poll semantics. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/4] sync_file: add a mutex to protect fence and callback members. (v3)

s)) { > + if (dma_fence_add_callback(fence, _file->cb, > + fence_check_cb_func) < 0) > + wake_up_all(_file->wq); > + } > + ret_val = dma_fence_is_signaled(fence) ?

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v3)

hat happens when the fence in the sync object > was changed while we do the CS? Or even worse the handle got > assigned to a new sync object. We either ww_mutex the lot, or regard that as a userspace race where the order between the two concurrent CS emits is undefined and who gets the in-sema

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Wed, Apr 12, 2017 at 12:36:37PM +1000, Dave Airlie wrote: > On 11 April 2017 at 17:50, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote: > >> From: Dave Airlie <airl...@redhat.com> > >> &g

Re: [PATCH 5/8] sync_file: add support for a semaphore object

gt;cb); wake_up(_file->wq); /* only needs the first to redo the add */ } will get the waiter to reset the callback on a new fence, or the old fence replacing itself. Otherwise the waiter will never be woken over the change in fence, not even when the old or new fence is signaled. -Ch

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

g kronos for VkSemaphore https://www.khronos.org/registry/vulkan/specs/1.0/man/html/VkSemaphore.html isn't enlightening... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freede

Re: [PATCH 5/8] sync_file: add support for a semaphore object

ps. Just be sure to leave a breadcrumb behind so that the first person who does try to pass back a syncobj fd is reminded that they need to fill in the fops. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote: > On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote: > > >> > > >> Not sure what the best semantics are there, any opinions on barring > > >> wakeups/polling on semaphore sync_files, and

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Thu, Apr 13, 2017 at 06:51:17AM +1000, Dave Airlie wrote: > On 13 April 2017 at 06:39, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote: > >> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote: >

Re: [PATCH 5/8] sync_file: add support for a semaphore object

}; could be extracted and sync_file become fence_file. Would it not help to avoid any further confusion by treating them as two very distinct classes of fd? And for me to stop calling the user interface sync_file. -Chris -- Chris Wilson, Intel Open Source Technology Centre __

Re: [PATCH 4/7] sync_file: add support for sem_file

t; + ret_fence = sem_file_get_fence_locked(sem_file); > + RCU_INIT_POINTER(sem_file->base.fence, fence); > + mutex_unlock(_file->lock); Is xchg() universal? struct dma_fence *sem_file_replace_fence(struct sem_file *sem_file, stru

Re: [repost] drm sync objects cleaned up

fixups > > My plans are to write some igt tests this week, and try > to get some more review on what the API should allow (should > I lock it down to drm syncobj is just semaphores for now). Having an idr of handles is much, much nicer than fd and I want the same for fences :) -Chris --

Re: [PATCH 1/4] sync_file: add a mutex to protect fence and callback members.

st need the following to retrieve the fence: > > while (sync_file->fence && !(fence = fence_get_rcu(sync_file->fence)); We even have a helper for that: fence = dma_fence_get_rcu_safe(_file->fence); (Still going to sug

Re: [PATCH 2/4] sync_file: add replace and export some functionality

d returns the old one. This > also exports the alloc and fdget functionality for the semaphore > wrapper code. Did you think about encapsulating a reservation object? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ a

Re: [repost] drm sync objects cleaned up

On Wed, Apr 19, 2017 at 05:34:52AM +1000, Dave Airlie wrote: > On 14 April 2017 at 19:45, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote: > >> This set of sync object patches should address most of the issu

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

Quoting Dave Airlie (2017-05-12 01:34:55) > @@ -385,6 +434,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, > void *data, > if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ)) > return -ENODEV; > > + if (args->flags & >

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

Quoting Dave Airlie (2017-08-04 00:01:10) > On 4 August 2017 at 02:25, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > Quoting Dave Airlie (2017-05-12 01:34:55) > >> @@ -385,6 +434,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_devic

Re: [PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

Quoting Christian König (2017-08-10 19:19:52) > Am 10.08.2017 um 19:11 schrieb Chris Wilson: > > Quoting Alex Deucher (2017-08-10 18:01:49) > >> From: Christian König <christian.koe...@amd.com> > >> > >> With hardware resets in mind it is possibl

Re: [PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

Quoting Alex Deucher (2017-08-10 18:01:49) > From: Christian König > > With hardware resets in mind it is possible that all shared fences are > signaled, but the exlusive isn't. Fix waiting for everything in this > situation. I'm still puzzling over this one. Setting

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v2)

t_timeout(fence, true, timeout); Doesn't handle -EINTR yet with timeout. If having a drmIoctl() that can't be tricked into turning a short waiting into an indefinite one is a goal. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ amd-gfx

Re: [PATCH 1/5] drm: introduce sync objects

On Tue, May 09, 2017 at 12:26:34PM +1000, Dave Airlie wrote: > On 4 May 2017 at 18:16, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote: > >> +#include > > > > I wonder if Daniel has already spl

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

> return -ENODEV; > > - if (args->pad || args->flags) > + if (args->pad) > + return -EINVAL; > + > + if (args->flags != 0 && > + args->flags != > DRM_SYNCOBJ_HANDLE_TO

Re: [PATCH 1/5] drm: introduce sync objects (v3)

destroy_blob) > > +#define DRM_IOCTL_SYNCOBJ_CREATE DRM_IOWR(0xBF, struct > drm_syncobj_create) > +#define DRM_IOCTL_SYNCOBJ_DESTROYDRM_IOWR(0xC0, struct > drm_syncobj_destroy) These two only need DRM_IOW. > +#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD DRM_IOWR(0x

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

GFP_KERNEL); > + if (handles == NULL) > + return -ENOMEM; > + > + if (copy_from_user(handles, > +(void __user *)(unsigned long)(args->handles), > +sizeof(uint32_t) * args->count_handles)) { > + ret = -EFAULT; > + goto err_free_handles; > + } > + > + if (args->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL) > + ret = drm_syncobj_wait_all_fences(dev, file_private, > + args, handles); > + else > + ret = drm_syncobj_wait_any_fence(dev, file_private, > + args, handles); > +err_free_handles: > + kfree(handles); > + > + return ret; > +} -- Chris Wilson, Intel Open Source Technology Centre ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/5] drm: introduce sync objects (v4)

seem in the end to be cleaner. > > Reviewed-by: Sean Paul <seanp...@chromium.org> > Signed-off-by: Dave Airlie <airl...@redhat.com> Thanks for find/replace, saves me having to export them later :) Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris -- Chris Wilson

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction. (v1.2)

Dave Airlie <airl...@redhat.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/5] drm: introduce sync objects

ence. No locks required. > + */ > +static inline void > +drm_syncobj_reference(struct drm_syncobj *obj) > +{ > + kref_get(>refcount); We've been steadily converting to the kref_get style of nomenclature for drm object reference handling (i.e. drm_syncobj_get, drm_syncobj_put) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface.

eeping the maximum waittime intact. > + dma_fence_put(fence); > + if (ret < 0) > + return ret; > + if (ret == 0) > + break; > + } > + > + wait->out_status = (ret > 0); > + wait->first_signaled = 0;

Re: [pull] amdgpu dc drm-next-4.15-dc

Quoting Alex Deucher (2017-09-27 02:36:07) > Hi Dave, > > Initial pull request for DC support. We've completed a substantial amount of > the cleanup and restructuring in our TODO. There are a few additional > cleanups that we are continuing to work on, but I don't think there are any >

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

Quoting Christian König (2017-11-15 18:56:43) > Am 15.11.2017 um 18:43 schrieb Chris Wilson: > > Quoting Christian König (2017-11-15 17:34:07) > >> Am 15.11.2017 um 17:55 schrieb Chris Wilson: > >>> Quoting Chris Wilson (2017-11-14 14:34:05) > >>>>

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

Quoting Christian König (2017-11-15 17:34:07) > Am 15.11.2017 um 17:55 schrieb Chris Wilson: > > Quoting Chris Wilson (2017-11-14 14:34:05) > >> Quoting Christian König (2017-11-14 14:24:44) > >>> Am 06.11.2017 um 17:22 schrieb Chris Wilson: > >>>>

Re: [PATCH 1/3] drm/ttm: add set_pages_wb for handling page order more than zero

Quoting Roger He (2017-11-22 11:44:27) > Change-Id: Idf5ccb579d264b343199d8b8344bddeec2c0019f > Signed-off-by: Roger He > --- > drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c >

Re: [PATCH 3/3] drm/ttm: roundup the shrink request to prevent skip huge pool

Quoting Roger He (2017-11-22 11:44:29) > e.g. shrink reqeust is less than 512, the logic will skip huge pool You should also tell the shrinker that you skipped objects so that it knows to accumulate the request for the next pass. See shrinkctl->nr_scanned. -Chris

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

ian König <christian.koe...@amd.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> Does what you say, but not quite the same patch I've been testing. -Chris ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] dma-buf: keep only not signaled fence in reservation_object_add_shared_replace v3

OINTER(fobj->shared[j++], check); > } > + fobj->shared_count = j; > + RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence); > + fobj->shared_count++; I would keep the INIT_PTR(fobj->shared[j++], fence); fobj->shared_count = j; Reviewed

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

Quoting Christian König (2017-11-14 14:24:44) > Am 06.11.2017 um 17:22 schrieb Chris Wilson: > > Quoting Christian König (2017-10-30 14:59:04) > >> From: Christian König <christian.koe...@amd.com> > >> > >> The amdgpu issue to also need signaled fenc

Re: [PATCH 1/2] dma-buf: keep only not signaled fence in reservation_object_add_shared_replace v3

Quoting Chris Wilson (2017-11-14 14:39:29) > Quoting Christian König (2017-11-14 14:24:35) > > The amdgpu issue to also need signaled fences in the reservation objects > > should be fixed by now. > > > > Optimize the list by keeping only the not signaled yet fences aro

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

Quoting Chris Wilson (2017-11-14 14:34:05) > Quoting Christian König (2017-11-14 14:24:44) > > Am 06.11.2017 um 17:22 schrieb Chris Wilson: > > > Quoting Christian König (2017-10-30 14:59:04) > > >> @@ -126,17 +127,28 @@ reservation_object_add_shared_inplace(struct

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Quoting Michal Hocko (2018-06-22 16:02:42) > Hi, > this is an RFC and not tested at all. I am not very familiar with the > mmu notifiers semantics very much so this is a crude attempt to achieve > what I need basically. It might be completely wrong but I would like > to discuss what would be a

Re: [PATCH] dma-buf: Move BUG_ON from _add_shared_fence to _add_shared_inplace

l > reservation_object_reserve_shared before). > > Cc: sta...@vger.kernel.org > Signed-off-by: Michel Dänzer I've convinced myself (or rather have not found a valid argument against) that being able to call reserve_shared + add_shared multiple times for the same fence is an intended

Re: [PATCH 1/3] drm: add func to get max iomem address v2

Quoting Chunming Zhou (2018-02-09 02:44:08) > it will be used to check if the driver needs swiotlb > v2: Don't use inline, instead, move function to drm_memory.c (Mechel Daenzer > ) > > Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3 > Signed-off-by: Chunming Zhou

Re: [PATCH 1/6] dma-buf: remove shared fence staging in reservation object

Quoting Christian König (2018-08-09 12:37:08) > void reservation_object_add_shared_fence(struct reservation_object *obj, > struct dma_fence *fence) > { > - struct reservation_object_list *old, *fobj = obj->staged; > + struct

[PATCH] drm: Remove defunct dma_buf_kmap stubs

Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers optional"), we no longer need to provide stub no-op functions as the core now provides them directly. References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers optional")

Re: [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

Quoting Christian König (2018-08-07 18:57:16) > Am 07.08.2018 um 18:08 schrieb Chris Wilson: > > amdgpu only uses shared-fences internally, but dmabuf importers rely on > > implicit write hazard tracking via the reservation_object.fence_excl. > > For example, the importer

[PATCH v5] drm/amdgpu: Transfer fences to dmabuf importer

the fence array. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Testcase: igt/amd_prime/amd-to-i915 References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)") Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: "Christian König"

[PATCH v6] drm/amdgpu: Transfer fences to dmabuf importer

the fence array. v4: Drop the fence array ref after assigning to reservation_object Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Testcase: igt/amd_prime/amd-to-i915 References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)") Signed-off

Re: [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

Quoting Christian König (2018-08-07 19:18:55) > Am 07.08.2018 um 20:14 schrieb Chris Wilson: > > Quoting Christian König (2018-08-07 18:57:16) > >> Am 07.08.2018 um 18:08 schrieb Chris Wilson: > >>> amdgpu only uses shared-fences internally, but dmabuf importers rely

[PATCH v2] drm/amdgpu: Transfer fences to dmabuf importer

are signaled (ensuring that we can not be signaled before the completion of any earlier write). v2: reservation_object is already locked by amdgpu_bo_reserve() Testcase: igt/amd_prime/amd-to-i915 Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: "Christian König" --- drivers/gpu/drm/

Re: [PATCH] drm/amdgpu: Transfer fences to dmabuf importer

Quoting Huang Rui (2018-08-07 11:56:24) > On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote: > > amdgpu only uses shared-fences internally, but dmabuf importers rely on > > implicit write hazard tracking via the reservation_object.fence_excl. > > For example, the i

[PATCH] drm/amdgpu: Transfer fences to dmabuf importer

are signaled (ensuring that we can not be signaled before the completion of any earlier write). Testcase: igt/amd_prime/amd-to-i915 Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: "Christian König" --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 70 --- 1 file c

[PATCH v3] drm/amdgpu: Transfer fences to dmabuf importer

are signaled (ensuring that we can not be signaled before the completion of any earlier write). v2: reservation_object is already locked by amdgpu_bo_reserve() Testcase: igt/amd_prime/amd-to-i915 Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: "Christian König" --- drivers/gpu/drm/

[PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

mdgpu: Attach exclusive fence to prime exported bo's. (v5)") Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: "Christian König" --- This time, hopefully proofread and references complete. -Chris --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 --- 1 file ch

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

Quoting Christian König (2018-08-09 15:54:31) > Am 09.08.2018 um 16:22 schrieb Daniel Vetter: > > On Thu, Aug 9, 2018 at 3:58 PM, Christian König > > wrote: > >> Am 09.08.2018 um 15:38 schrieb Daniel Vetter: > >>> On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote: > >>> [SNIP] > >>

Re: [PATCH v2 00/12] remove_conflicting_framebuffers() cleanup

Quoting Daniel Vetter (2018-08-31 10:04:39) > On Thu, Aug 30, 2018 at 11:00:01PM +0200, Michał Mirosław wrote: > > This series cleans up duplicated code for replacing firmware FB > > driver with proper DRI driver and adds handover support to > > Tegra driver. > > > > This is a sligtly updated

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Quoting Christian König (2018-03-16 13:20:45) > @@ -326,6 +338,29 @@ struct dma_buf_attachment { > struct device *dev; > struct list_head node; > void *priv; > + > + /** > +* @invalidate_mappings: > +* > +* Optional callback provided by the

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] > This allows for full grown pipelining, e.g. the exporter can say I need > to move the buffer for some operation. Then let the move operation wait > for all existing fences in the reservation object and install

Re: [PATCH 22/22] drm/amdgpu: fix reservation obj shared count bug

Quoting Christian König (2018-02-26 10:44:40) > > We must call reserve_shared before amdgpu_bo_fence > Actually that's not correct. See reservation_object_add_shared_fence() > should replace the fence when it has the same context as a previously > added fence. > > So we call reserve_shared

Re: [PATCH 21/22] dma-buf/reservation: shouldn't kfree staged when slot available

Quoting Christian König (2018-02-26 09:42:15) > Well first of all you need to send that to dri-devel and even lkml, so > that Chris and others can take a look as well. > > Second that patch doesn't looks correct to me, obj->staged should never > be related to obj->fence. Concurred. I would

Re: [PATCH 2/7] drm: add syncobj timeline support v8

Quoting Chunming Zhou (2018-10-15 09:55:48) > This patch is for VK_KHR_timeline_semaphore extension, semaphore is called > syncobj in kernel side: > This extension introduces a new type of syncobj that has an integer payload > identifying a point in a timeline. Such timeline syncobjs support the

Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object

Quoting Chris Wilson (2018-10-25 21:20:21) > Quoting Chris Wilson (2018-10-25 21:15:17) > > Quoting Christian König (2018-10-04 14:12:43) > > > No need for that any more. Just replace the list when there isn't enough > > > room any more for the additional fence. >

Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object

Quoting Christian König (2018-10-04 14:12:43) > No need for that any more. Just replace the list when there isn't enough > room any more for the additional fence. Just a heads up. After this series landed, we started hitting a use-after-free when iterating the shared list. <4> [109.613162]

Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object

Quoting Chris Wilson (2018-10-25 21:15:17) > Quoting Christian König (2018-10-04 14:12:43) > > No need for that any more. Just replace the list when there isn't enough > > room any more for the additional fence. > > Just a heads up. After this series landed, we started hitti

[PATCH] drm/amdgpu: Reorder uvd ring init before uvd resume

d at (133146): [] __do_softirq+0x365/0x47c [5.596748] softirqs last disabled at (133139): [] irq_exit+0x119/0x120 [5.596749] ---[ end trace eaee508abfebccdc ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709 Signed-off-by: Chris Wilson Cc: Alex Deucher --- drivers/gpu/dr

Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3

Quoting Koenig, Christian (2018-12-13 12:11:10) > Am 13.12.18 um 12:37 schrieb Chris Wilson: > > Quoting Chunming Zhou (2018-12-11 10:34:45) > >> From: Christian König > >> > >> Implement finding the right timeline point in drm_syncobj_find_fence. > &g

[PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts

://bugs.freedesktop.org/show_bug.cgi?id=109049 Signed-off-by: Chris Wilson --- tests/amdgpu/amd_prime.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu/amd_prime.c index bda0ce83d..518c88963 100644 --- a/tests/amdgpu/amd_prime.c +++ b/tests

Re: [Intel-gfx] [PATCH 01/10] dma-buf: add new dma_fence_chain container v4

Quoting Chunming Zhou (2018-12-11 10:34:40) > From: Christian König > > Lockless container implementation similar to a dma_fence_array, but with > only two elements per node and automatic garbage collection. > > v2: properly document dma_fence_chain_for_each, add > dma_fence_chain_find_seqno,

Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3

Quoting Chunming Zhou (2018-12-11 10:34:45) > From: Christian König > > Implement finding the right timeline point in drm_syncobj_find_fence. > > v2: return -EINVAL when the point is not submitted yet. > v3: fix reference counting bug, add flags handling as well > > Signed-off-by: Christian

Re: [igt-dev] [PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts

Quoting Chris Wilson (2018-12-13 15:36:43) > Quoting Antonio Argenziano (2018-12-13 15:28:00) > > > > > > On 13/12/18 03:57, Chris Wilson wrote: > > > amdgpu has started to report out of space after creating a few contexts. > > > This is not the scope

Re: [igt-dev] [PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts

Quoting Antonio Argenziano (2018-12-13 15:28:00) > > > On 13/12/18 03:57, Chris Wilson wrote: > > amdgpu has started to report out of space after creating a few contexts. > > This is not the scope of this test as here we just verifying that fences > > created in a

Re: [PATCH] drm/i915_request.h: Remove duplicate header

Quoting Brajeswar Ghosh (2018-12-25 13:23:40) > Remove i915_scheduler.h which is included more than once > > Signed-off-by: Brajeswar Ghosh Thanks for the patch, pushed to dinq. -Chris ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org

Re: [PATCH 01/10] dma-buf: make fence sequence numbers 64 bit v2

Quoting Christian König (2018-12-04 11:59:39) > -static inline bool __dma_fence_is_later(u32 f1, u32 f2) > +static inline bool __dma_fence_is_later(u64 f1, u64 f2) > { > - return (int)(f1 - f2) > 0; > + /* This is for backward compatibility with drivers which can only > handle > +

Re: [PATCH 01/10] dma-buf: make fence sequence numbers 64 bit v2

Quoting Chris Wilson (2018-12-04 12:52:15) > Quoting Christian König (2018-12-04 11:59:39) > > -static inline bool __dma_fence_is_later(u32 f1, u32 f2) > > +static inline bool __dma_fence_is_later(u64 f1, u64 f2) > > { > > - return (int)(f1 - f2) > 0; >

Re: [PATCH 2/3] drm/syncobj: use dma_fence_get_stub

Quoting Christian König (2018-12-03 13:07:58) > Extract of useful code from the timeline work. Let's use just a single > stub fence instance instead of allocating a new one all the time. > > Signed-off-by: Chunming Zhou > Signed-off-by: Christian König Reviewed-by: Chris

Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub

Quoting Christian König (2018-12-03 13:07:57) > Extract of useful code from the timeline work. This provides a function > to return a stub or dummy fence which is always signaled. > > Signed-off-by: Christian König Reviewed-by: Chris Wi

Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub

Quoting Eric Anholt (2018-12-03 16:08:40) > Christian König writes: > > > Extract of useful code from the timeline work. This provides a function > > to return a stub or dummy fence which is always signaled. > > > > Signed-off-by: Christian König > > --- > > drivers/dma-buf/dma-fence.c | 36

Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub

Quoting Christian König (2018-12-03 16:12:14) > Am 03.12.18 um 17:08 schrieb Eric Anholt: > > Christian König writes: > > > >> Extract of useful code from the timeline work. This provides a function > >> to return a stub or dummy fence which is always signaled. > >> > >> Signed-off-by: Christian

Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v2

Quoting Christian König (2018-11-28 14:50:12) > +/** > + * dma_fence_chain_for_each - iterate over all fences in chain > + * @fence: starting point as well as current fence > + * > + * Iterate over all fences in the chain. We keep a reference to the current > + * fence while inside the loop which

Re: [PATCH 2/3] drm: Add basic helper to allow precise pageflip timestamps in vrr.

Quoting Daniel Vetter (2019-02-13 09:50:55) > On Tue, Feb 12, 2019 at 10:32:31PM +0100, Mario Kleiner wrote: > > I think all kms drivers try to call drm_crtc_handle_vblank() at start > > of vblank to give Mesa the most time for frontbuffer rendering for > > classic X. But vblank events are also

[PATCH] drm/amdgpu: Transfer fences to dmabuf importer

the fence array. v4: Drop the fence array ref after assigning to reservation_object Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Testcase: igt/amd_prime/amd-to-i915 References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)") Signed-off

Re: [PATCH] drm: increase drm mmap_range size to 1TB

Quoting Thomas Zimmermann (2019-04-18 08:29:39) > Hi > > Am 18.04.19 um 00:16 schrieb Kuehling, Felix: > > Adding dri-devel > > > > On 2019-04-17 6:15 p.m., Yang, Philip wrote: > >> After patch "drm: Use the same mmap-range offset and size for GEM and > >> TTM", application failed to create bo

Re: [PATCH v2 2/3] drm: plumb attaching dev thru to prime_pin/unpin

Quoting Rob Clark (2019-07-16 18:43:22) > From: Rob Clark > > Needed in the following patch for cache operations. What's the base for this patch? (I'm missing the ancestor for drm_gem.c) -Chris ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org

Re: [RFC 02/17] dma-fence: basic lockdep annotations

Quoting Daniel Vetter (2020-05-12 10:08:47) > On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-05-12 09:59:29) > > > Design is similar to the lockdep annotations for workers, but with > > > some twists: > &

Re: [RFC 01/17] dma-fence: add might_sleep annotation to _wait()

linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-gfx@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian König > Signed-off-by: Daniel Vetter > --- > drivers/dma-buf/dma-fence.c | 3 +++ > 1 file

Re: [RFC 02/17] dma-fence: basic lockdep annotations

he point. Therefore these annotations > cannot be sprinkled over the code entirely mindless to avoid false > positives. > > v2: handle soft/hardirq ctx better against write side and dont forget > EXPORT_SYMBOL, drivers can't use this otherwise. > > Cc: linux-me...@vger.kernel.

Re: [PATCH 0/6] RFC Support hot device unplug in amdgpu

Quoting Daniel Vetter (2020-05-11 10:54:33) > - worse, neither vk nor gl (to my knowledge) have a concept of events > for when the gpu died. The only stuff you have is things like > arb_robustness which says a) everything continues as if nothing > happened b) there's a function where

Re: [PATCH] dma-fence: add might_sleep annotation to _wait()

ware Graphics" > Cc: Oded Gabbay > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-gfx@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian König >

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

Quoting Daniel Stone (2020-06-11 10:01:46) > Hi, > > On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote: > > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > > Introducing a global lockmap that cannot capture the rules correctly, > > > > Can you d

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

Quoting Daniel Vetter (2020-06-19 09:51:59) > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson > wrote: > > Forcing a generic primitive to always be part of the same global map is > > horrible. > > And no concrete example or reason for why that's not possible. > Becaus

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

Quoting Daniel Vetter (2020-06-19 10:43:09) > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-06-19 09:51:59) > > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson > > > wrote: > > > > Forcing a generic primiti

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

neldoc. > > v4: Some spelling fixes from Mika > > Cc: Mika Kuoppala > Cc: Thomas Hellstrom > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-gfx@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org >

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

Quoting Daniel Vetter (2020-06-04 10:21:46) > On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel) > wrote: > > > > > > On 6/4/20 10:12 AM, Daniel Vetter wrote: > > ... > > > Thread A: > > > > > > mutex_lock(A); > > > mutex_unlock(A); > > > > > > dma_fence_signal(); > > > >