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
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.
> B
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 docu
rwise.
>
> v3: Kerneldoc.
>
> 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-...@
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();
> > >
> >
ot;VMware 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
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:
> > >
h calls, defeating the 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:
ists.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
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
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
htt
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 of
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 use
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)")
Signe
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
https://list
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 of t
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 amd c
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.
> >&
://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
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 Kön
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,
>
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;
>
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
> +
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 K
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 +++
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:
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
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 m
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
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.
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
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] genera
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
>
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 vers
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]
> >> S
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 reservation_object_
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)")
Signe
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&qu
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
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 use
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")
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 fi
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/
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
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/
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
t call
> 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
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 bett
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
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 impo
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 o
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 susp
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
> Reviewed-by: Monk Liu
>
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
__
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
> b/drivers/gpu/drm/ttm
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)
> >>>>
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:
> >>>>
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
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
Quoting Christian König (2017-11-14 14:24:36)
> The amdgpu issue to also need signaled fences in the reservation objects
> should
> be fixed by now.
>
> Optimize the handling by replacing a signaled fence when adding a new
> shared one.
>
> Signed-off-by: Christian Kö
);
> }
> + 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;
Review
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
> >>
> >> The amdgpu issue to also need signaled fences in the reservation objec
Quoting Christian König (2017-10-30 14:59:04)
> From: Christian König
>
> The amdgpu issue to also need signaled fences in the reservation objects
> should
> be fixed by now.
>
> Optimize the handling by replacing a signaled fence when adding a new
> shared one.
>
> Signed-off-by: Christian Kö
Quoting Christian König (2017-10-30 14:59:03)
> From: Christian König
>
> 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 around.
>
> v2: temporary put the signaled fences at the
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
> showstopp
Quoting Christian König (2017-08-16 08:49:07)
> Am 16.08.2017 um 04:12 schrieb Chris Mi:
> > Using current TC code, it is very slow to insert a lot of rules.
> >
> > In order to improve the rules update rate in TC,
> > we introduced the following two changes:
> > 1) changed cls_flower to u
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
> >>
> >> With hardware resets in mind it is possible that all shared fences are
> &
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 an exclusive fence will cl
Quoting Dave Airlie (2017-08-04 00:01:10)
> On 4 August 2017 at 02:25, Chris Wilson wrote:
> > 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_co
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 &
> DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPO
> This should only be used to interact with sync files where necessary.
>
> v1.1: fence put fixes (Chris), drop fence from ioctl names (Chris)
> fixup for new fence replace API.
>
> Reviewed-by: Sean Paul
> Signed-off-by: Dave Airlie
Reviewed-by: Chris Wilson
-Chris
--
Chr
> + ret = -EFAULT;
> + goto err_free_handles;
> + }
> +
> + fences = kcalloc(args->count_handles,
> + sizeof(struct dma_fence *), GFP_KERNEL);
if (!fences) /* blah */
> +
> + for (i = 0; i < args->co
> Reviewed-by: Sean Paul
> Signed-off-by: Dave Airlie
Thanks for find/replace, saves me having to export them later :)
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
amd-gfx mailing list
amd-gfx@lis
|| args->flags)
> + if (args->pad)
> + return -EINVAL;
> +
> + if (args->flags != 0 &&
> + args->flags !=
> DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE)
> return -EINVAL;
DRM_SYNCOBJ_HAND
t_handles, sizeof(uint32_t),
> + 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
uct
> 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(0xC1, struct
> drm_syncobj_handle)
> +#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE
ma_fence_wait_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
__
On Tue, May 09, 2017 at 12:26:34PM +1000, Dave Airlie wrote:
> On 4 May 2017 at 18:16, Chris Wilson wrote:
> > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> >> +#include
> >
> > I wonder if Daniel has already split everything used here into its own
INT and keeping
the maximum waittime intact.
> + dma_fence_put(fence);
> + if (ret < 0)
> + return ret;
> + if (ret == 0)
> + break;
> + }
> +
> + wait->out_status = (ret > 0);
> +
gal to call this
> + * without already holding a reference. No locks required.
> + */
> +static inline void
> +drm_syncobj_reference(struct drm_syncobj *obj)
> +{
> + kref_get(&obj->refcount);
We've been steadily converting to the kref_get style of nomenclature fo
On Wed, Apr 19, 2017 at 05:34:52AM +1000, Dave Airlie wrote:
> On 14 April 2017 at 19:45, Chris Wilson 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 issues
> >> raised in review.
>
> 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
--
ret_fence = sem_file_get_fence_locked(sem_file);
> + RCU_INIT_POINTER(sem_file->base.fence, fence);
> + mutex_unlock(&sem_file->lock);
Is xchg() universal?
struct dma_fence *sem_file_replace_fence(struct sem_file *sem_file,
fence *fence;
};
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
_
On Thu, Apr 13, 2017 at 06:51:17AM +1000, Dave Airlie wrote:
> On 13 April 2017 at 06:39, Chris Wilson 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:
> >> > >>
> &
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
to handle it in the fops. 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
On Wed, Apr 12, 2017 at 12:36:37PM +1000, Dave Airlie wrote:
> On 11 April 2017 at 17:50, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This object can be used to implement the Vul
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
ines. Searching 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.o
wake_up(&sync_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 s
fput(sync_file->file);
So poll will wait until the fence is set before the sync_file is
signaled, but here we return NULL. At the moment this is interpretted by
the callers as an error (since we can't distinguish between the lookup
error and the empty sync_file). However, if it is empty we
> + if (!test_and_set_bit(POLL_ENABLED, &fence->flags)) {
> + if (dma_fence_add_callback(fence, &sync_file->cb,
> +fence_check_cb_func) < 0)
> +
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(&sync_file->fence);
(Still going to suggest using a reservation_object rather than an
exclusive-only implementatio
> 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
___
amd-gfx mailing list
amd-gfx@lists.
On Tue, Sep 13, 2016 at 10:44:11AM +0200, Christian König wrote:
> Am 09.09.2016 um 03:15 schrieb Michel Dänzer:
> >On 09/09/16 01:23 AM, Chris Wilson wrote:
> >>On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
> >>>On 09/08/2016 08:30 AM, Chris Wils
; mutex_lock(&item->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 the item
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->
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
99 matches
Mail list logo
