On 2019年05月07日 17:03, Christian König wrote:
[CAUTION: External Email]
Ping!
in fact, already address your comments, just wait for Prike test result,
anyway, send v6 first.
-David
Marek is going to need this for its GDS patches as well.
Christina.
Am 30.04.19 um 11:10 schrieb Christian
On 2019年05月07日 18:53, Koenig, Christian wrote:
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run in
On 2019年05月07日 19:13, Koenig, Christian wrote:
Am 07.05.19 um 13:08 schrieb zhoucm1:
On 2019年05月07日 18:53, Koenig, Christian wrote:
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user
fail to get memory.
basically pick up
ping... for patch set.
On 2019年05月13日 17:52, Chunming Zhou wrote:
[CAUTION: External Email]
Signed-off-by: Chunming Zhou
---
include/drm/amdgpu_drm.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index d0701ffc..3d0318e6 10
Thank you, Lionel.
-David
On 2019年05月14日 17:49, Lionel Landwerlin wrote:
[CAUTION: External Email]
With the small nits, patches 2 & 4 are : Reviewed-by: Lionel Landwerlin
The other patches are a bit amdgpu specific so maybe you might want
someone more familiar with amdgpu to review them.
Sti
I was able to push changes to libdrm, but now seems after libdrm is
migrated to gitlab, I cannot yet. What step do I need to get back my
permission? I already can login into gitlab with old freedesktop account.
@Christian, Can you help submit this patch set to libdrm first?
Thanks,
-David
On 2019年05月16日 18:09, Christian König wrote:
[CAUTION: External Email]
Am 16.05.19 um 10:16 schrieb zhoucm1:
I was able to push changes to libdrm, but now seems after libdrm is
migrated to gitlab, I cannot yet. What step do I need to get back my
permission? I already can login into gitlab
ping, Could you help check in patch to gitlab? My connection to gitlab
still has problem.
Thanks,
-David
On 2019年05月16日 19:03, Zhou, David(ChunMing) wrote:
could you help push this patch as well?
Thanks,
-David
Original Message
Subject: Re: [PATCH libdrm] enable syncobj
Sorry for late response.
Although we don't expect that, drm_syncobj_timeline_signal_ioctl already
handle this case I think. Which can handle both (point value > 0) and
(point value = 0).
-David
On 2019年05月21日 16:44, Lionel Landwerlin wrote:
[CAUTION: External Email]
Ping?
On 16/05/2019
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
Signed-off-by: Chri
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start ov
anyone can pick up to gitlab for libdrm?
Thanks,
-David
On 2019年05月22日 18:46, Koenig, Christian wrote:
Am 22.05.19 um 11:07 schrieb Chunming Zhou:
a) delta: only DRM_CAP_SYNCOBJ_TIMELINE
b) Generated using make headers_install.
c) Generated from origin/drm-misc-next commit
9
I made a patch as attached.
I'm not sure how to make patch as your proposal, Could you make a patch
for that if mine isn't enough?
-David
On 2019年04月24日 15:12, Christian König wrote:
how about just adding a wrapper for pin function as below?
I considered this as well and don't think it will
check if you get an -ENOMEM
and then call schedule().
If after the schedule() we see that we have now BOs on the LRU we can
try again and see if pinning the frame buffer now succeeds.
Christian.
Am 24.04.19 um 09:17 schrieb zhoucm1:
I made a patch as attached.
I'm not sure how to
loop.
I already add a timeout for that.
-David
Christian.
Am 24.04.19 um 09:59 schrieb zhoucm1:
how about new attached?
-David
On 2019年04月24日 15:30, Christian König wrote:
That would change the semantics of ttm_bo_mem_space() and so could
change the return code in an IOCTL as well. Not a
OK, Let's drop mine, then Could you draft a solution for that?
-David
On 2019年04月24日 16:59, Koenig, Christian wrote:
Am 24.04.19 um 10:11 schrieb zhoucm1:
On 2019年04月24日 16:07, Christian König wrote:
This is used in a work item, so you don't need to check for signals.
w
On 2019年04月25日 03:22, Eric Anholt wrote:
"Zhou, David(ChunMing)" writes:
Will linux be only mesa-linux? I thought linux is an open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
reject?
2
On 2019年04月26日 16:31, Christian König wrote:
Am 25.04.19 um 09:39 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user
fail to get memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
Any reason you don't
On 2019年04月26日 17:11, Koenig, Christian wrote:
Am 26.04.19 um 11:07 schrieb zhoucm1:
[SNIP]
+ spin_lock(&glob->lru_lock);
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ if (list_empty(&man->lru[i]))
+ continue;
+ bo = list_first_
please ignore v4. Will send v5 instead.
On 2019年04月26日 17:53, Chunming Zhou wrote:
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this E
On 2019年01月11日 21:15, Christian König wrote:
Move the BO on the LRU only when it is actually moved by a DMA
operation.
Signed-off-by: Christian König
Tested-And-Reviewed-by: Chunming Zhou
I just sent lru_notify v2 patches, please review them. With yours and
mine, the OOM issue is fixed w
On 2019年02月17日 03:22, Christian König wrote:
Am 15.02.19 um 20:31 schrieb Lionel Landwerlin via amd-gfx:
On 07/12/2018 09:55, Chunming Zhou wrote:
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container,
Hi Lionel,
I checked your igt test case,
uint64_t points[5] = { 1, 5, 3, 7, 6 };
which is illegal signal order.
I must admit we should handle it gracefully if signal isn't in-order,
and we shouldn't lead to deadlock.
Hi Christian,
Can we just ignore when signal point X <= timeline Y? Or ju
Hi Lionel,
the attached should fix your problem and also messed signal order.
Hi Christian,
Could you have a look if it's reasonable?
btw: I pushed to change to
https://github.com/amingriyue/timeline-syncobj-kernel, which is already
rebased to latest drm-misc(kernel 5.0). You can directly u
bmitted work to the hardware. And just dropping the fence
like you do in the patch is a clearly no-go as well.
Then do you have any idea to skip the messed order signal point?
-David
Regards,
Christian.
Am 19.02.19 um 11:46 schrieb zhoucm1:
Hi Lionel,
the attached should fix your problem
On 2019年02月20日 15:59, Koenig, Christian wrote:
Am 20.02.19 um 05:53 schrieb zhoucm1:
On 2019年02月19日 19:32, Koenig, Christian wrote:
Hi David,
Could you have a look if it's reasonable?
Patch #1 is also something I already fixed on my local branch.
But patch #2 won't work
https://gitlab.freedesktop.org/mesa/drm, Where the merge request button?
-David
On 2019年06月06日 18:20, Michel Dänzer wrote:
On 2019-05-24 7:15 a.m., zhoucm1 wrote:
anyone can pick up to gitlab for libdrm?
Can you create a merge request?
___
dri
On 2019年03月19日 19:54, Lionel Landwerlin wrote:
On 15/03/2019 12:09, Chunming Zhou wrote:
v2: individually allocate chain array, since chain node is free
independently.
v3: all existing points must be already signaled before cpu perform
signal operation,
so add check condition for that.
Hi Lionel and Christian,
Below is robot report for chain->prev, which was added __rcu as you
suggested.
How to fix this line "tmp = cmpxchg(&chain->prev, prev, replacement); "?
I checked kernel header file, seems it has no cmpxchg for rcu.
Any suggestion to fix this robot report?
Thanks,
-Da
quot;
Hi David,
For the cmpxchg() case I of hand don't know either. Looks like so far
nobody has used cmpxchg() with rcu protected structures.
The other cases should be replaced by RCU_INIT_POINTER() or
rcu_dereference_protected(.., true);
Regards,
Christian.
Am 21.03.19 um 07:34 schrieb
On 2019年04月01日 16:19, Lionel Landwerlin wrote:
On 01/04/2019 06:54, Zhou, David(ChunMing) wrote:
-Original Message-
From: Lionel Landwerlin
Sent: Saturday, March 30, 2019 10:09 PM
To: Koenig, Christian ; Zhou, David(ChunMing)
; dri-devel@lists.freedesktop.org; amd-
g...@lists.freede
On 2019年07月19日 16:13, Lionel Landwerlin wrote:
On 18/07/2019 17:33, Chunming Zhou wrote:
在 2019/7/18 22:08, Lionel Landwerlin 写道:
On 18/07/2019 16:02, Chunming Zhou wrote:
在 2019/7/18 19:31, Lionel Landwerlin 写道:
On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in
On 2019年07月22日 16:46, Lionel Landwerlin wrote:
On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
on syncobj,
then return non-block error code to user sapce.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 4 ++-
On 2019年07月24日 03:20, Lionel Landwerlin wrote:
On 23/07/2019 17:21, Chunming Zhou wrote:
user space needs a flexiable query ability.
So that umd can get last signaled or submitted point.
v2:
add sanitizer checking.
Change-Id: I6512b430524ebabe715e602a2bf5abb0a7e780ea
Signed-off-by: Chunming Z
Thank guys. Since I have write permission to libdrm mast, I need your
help to push patch.
-David
On 2019年07月25日 16:11, Chunming Zhou wrote:
v2: nit-picks fix
Signed-off-by: Chunming Zhou
Cc: Lionel Landwerlin
Cc: Christian König
Reviewed-by: Christian König
For the xf86drm.[ch] part : Re
Thanks guys, since I have no write permission to libdrm, I need your
help to push patch.
-David
On 2019年07月25日 16:11, Chunming Zhou wrote:
v2: nit-picks fix
Signed-off-by: Chunming Zhou
Cc: Lionel Landwerlin
Cc: Christian König
Reviewed-by: Christian König
For the xf86drm.[ch] part : Revie
On 2019年07月30日 17:27, Daniel Vetter wrote:
On Mon, Jul 29, 2019 at 04:20:39PM +0800, Chunming Zhou wrote:
It is normal that binary syncobj replaces the underlying fence.
Signed-off-by: Chunming Zhou
Do we hit this with one of the syncobj igts?
Unforturnately, No, It's only hit in AMDGPU pat
On 2019年07月30日 17:40, Lionel Landwerlin wrote:
On 30/07/2019 12:36, Daniel Vetter wrote:
On Tue, Jul 30, 2019 at 05:31:26PM +0800, zhoucm1 wrote:
On 2019年07月30日 17:27, Daniel Vetter wrote:
On Mon, Jul 29, 2019 at 04:20:39PM +0800, Chunming Zhou wrote:
It is normal that binary syncobj
Hi Lionel,
For binary semaphore, I guess every one will think application will
guarantee wait is behind the signal, whenever the semaphore is shared or
used in internal-process.
I think below two options can fix your problem:
a. Can we extend vkWaitForFence so that it can be able to wait on
On 2019年08月02日 17:41, Lionel Landwerlin wrote:
Hey David,
On 02/08/2019 12:11, zhoucm1 wrote:
Hi Lionel,
For binary semaphore, I guess every one will think application will
guarantee wait is behind the signal, whenever the semaphore is shared
or used in internal-process.
I think below
If it is not submitted yet, Reviewed-by: Chunming Zhou
-David
On 2019年08月09日 21:43, Lionel Landwerlin wrote:
The Vulkan timeline semaphores allow signaling to happen on the point
of the timeline without all of the its dependencies to be created.
The current 2 implementations (AMD/Intel) of
On 2016å¹´10æ17æ¥ 21:55, Christian König wrote:
> From: Christian König
>
> Kernel functions taking a timeout usually return 1 on success even
> when they get a zero timeout.
>
> Signen-off-by: Christian König
The series is Reviewed-by: Chunming Zhou
> ---
> drivers/dma-buf/fence.c |
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelle
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelle
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.
Signed-off-b
On 2017年02月15日 18:43, Nicolai Hähnle wrote:
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done
On 2017年02月16日 20:08, Christian König wrote:
Am 16.02.2017 um 12:39 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initiali
+Qiang, who is working on it.
On 2016å¹´11æ27æ¥ 22:07, Christian König wrote:
> Am 27.11.2016 um 15:02 schrieb Haggai Eran:
>> On 11/25/2016 9:32 PM, Jason Gunthorpe wrote:
>>> On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote:
>>>
> Like you say below we have to handle shor
Hi Dave,
Could you tell me why you create your new one patch? I remember I send
out our the whole implementation, Why not directly review our patches?
Thanks,
David Zhou
On 2017年03月14日 08:50, Dave Airlie wrote:
From: Dave Airlie
This adds the corresponding code for libdrm to use the new
ke
On 2017年03月14日 10:52, Dave Airlie wrote:
On 14 March 2017 at 12:00, zhoucm1 wrote:
Hi Dave,
Could you tell me why you create your new one patch? I remember I send out
our the whole implementation, Why not directly review our patches?
This is patch review, I'm not sure what yo
On 2017年03月14日 17:20, Christian König wrote:
Am 14.03.2017 um 09:54 schrieb Daniel Vetter:
On Tue, Mar 14, 2017 at 11:30:40AM +0800, zhoucm1 wrote:
On 2017年03月14日 10:52, Dave Airlie wrote:
On 14 March 2017 at 12:00, zhoucm1 wrote:
Hi Dave,
Could you tell me why you create your new one
1. generally, functions in amdgpu_cs.c should be with amdgpu_cs_ as prefix.
2. If I'm not wrong to your proposal, SYNCOBJ_IN is to semaphore wait
while SYNCOBJ_OUT is to semaphore signal. SYNCOBJ_IN/OUT both are based
on command submission ioctl, that means user space must generate CS when
usin
On 2017年05月12日 12:17, Dave Airlie wrote:
On 12 May 2017 at 13:34, zhoucm1 wrote:
1. generally, functions in amdgpu_cs.c should be with amdgpu_cs_ as prefix.
Okay I've fixed this and previous patch up locally.
2. If I'm not wrong to your proposal, SYNCOBJ_IN is to semaphore
On 2017年05月15日 17:52, kbuild test robot wrote:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
head: c285c73f2213f503a93aa142fff186e160b4a371
commit: 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24 [1061/1085] drm/amd: fix init
order of sched job
config: sparc-allmodconfig (a
On 2017年05月24日 15:06, Dave Airlie wrote:
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> Looks like .last_flush reference is left at teardown.
> Leak reported by CONFIG_SLUB_DEBUG.
>
> Fixes: 41d9eb2c5a2a ("drm/amdgpu: add a fence after the VM flush")
> Signed-off-by: Grazvydas Ignotas
Reviewed-by: Chunming Zhou
> ---
> drive
Acked-by: Chunming Zhou
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> To free fences, call_rcu() is used, which calls amd_sched_fence_free()
> after a grace period. During teardown, there is no guarantee all
> callbacks have finished, so sched_fence_slab may be destroyed before
> all fen
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> It's done in amd_sched_hw_job_reset(), but not in normal job processing.
> Leak reported by CONFIG_SLUB_DEBUG.
>
> Signed-off-by: Grazvydas Ignotas
> ---
> CONFIG_SLUB_DEBUG reports more leaks related to ioctls,
> but I was unable to tra
Acked-by: Chunming Zhou
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> To free fences, call_rcu() is used, which calls amdgpu_fence_free()
> after a grace period. During teardown, there is no guarantee all
> callbacks have finished, so amdgpu_fence_slab may be destroyed before
> all fence
On 2016å¹´09æ08æ¥ 21:41, Christian König wrote:
> From: Christian König
>
> Either never used or not used in quite a while.
No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2.
And you cannot make sure there isn't no one using them in other closed
projects, right?
If you
On 2016å¹´09æ08æ¥ 21:41, Christian König wrote:
> From: Christian König
>
> Makes more sense to keep that together.
>
> Signed-off-by: Christian König
Reviewed-by: Chunming Zhou
> ---
> include/drm/ttm/ttm_bo_api.h| 32 +---
> include/drm/ttm/ttm_placem
On 2016å¹´09æ13æ¥ 05:00, Alex Deucher wrote:
> On Mon, Sep 12, 2016 at 7:46 AM, Christian König
> wrote:
>> From: Christian König
>>
>> Makes more sense to keep that together.
>>
>> Signed-off-by: Christian König
>> Reviewed-by: Chunming Zhou
> For the series:
> Reviewed-by: Alex Deuche
On 2016å¹´09æ21æ¥ 19:36, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> If the fences in the fence_array signal on the fence_array does not have
> signalling enabled num_pending will not be updated accordingly.
>
> So when signaling is disabled check the signal of every fence with
> fence
Thanks for reply, this patch is mainly for performance reason. since TTM
is to clear page for all non-fixed memory (GTT and CPU domains), which
takes much more CPU overhead. The patch is to remove 'clear page' for
GTT domain.
btw: Micheal has rejected this patch.
Regards,
David Zhou (Chunming)
On 2016å¹´01æ10æ¥ 23:10, Thomas Hellstrom wrote:
> On 01/09/2016 11:46 AM, Christian König wrote:
>> It's correct that exported buffers can't be moved to another domain or
>> swapped to disk while another device is using it.
>>
>> But for imports that's a different story:
>>> an imported obje
On 2016å¹´06æ15æ¥ 19:44, Christian König wrote:
> From: Christian König
>
> When we pipeline evictions the page directory could already be
> moving somewhere else when grab_id is called.
Isn't PD bo protected by job fence?
I think before job fence is signalled, the PD bo is safe, there
sho
On 2016å¹´06æ16æ¥ 17:52, Christian König wrote:
> Am 16.06.2016 um 10:33 schrieb zhoucm1:
>>
>>
>> On 2016å¹´06æ15æ¥ 19:44, Christian König wrote:
>>> From: Christian König
>>>
>>> When we pipeline evictions the page directory could alre
On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Signed-off-by: Nicolai Hähnle
Reviewed-by: Chunming Zhou
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_obj
On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This catches evictions of shadow page tables from the GART. Since shadow
> page tables are always stored in system memory, amdgpu_bo_move is never
> called for them.
>
> This fixes a crash during command submission th
On 2016å¹´12æ16æ¥ 01:59, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the
> non-shadow page tables using the new helper function.
>
> This fixes a crash with the stack trace:
>
> amdgpu_gem_va_update_vm
> -> amdgpu_vm_u
On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Skip amdgpu_gem_va_update_vm when shadow the page directory is swapped out.
> Clean up the check for non-shadow BOs as well using the new helper function.
>
> This fixes a crash with the stack trace:
>
> amdgpu_gem_va
On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Ensure that the driver can listen to evictions even when they don't take the
> path through ttm_bo_driver::move.
>
> This is crucial for amdgpu, which relies on an eviction counter to skip
> re-binding page tables whe
On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the
> non-shadow page tables using the new helper function.
>
> This fixes a crash with the stack trace:
>
> amdgpu_gem_va_update_vm
> -> amdgpu_vm_u
On 2016å¹´12æ22æ¥ 02:46, Nicolai Hähnle wrote:
> +static inline bool __sched
> +__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
> +{
> + return a->stamp - b->stamp <= LONG_MAX &&
> +(a->stamp != b->stamp || a > b);
I want to ask a stupid question, why
On 2018年10月16日 20:54, Christian König wrote:
I've added my rb to patch #1 and pushed it to drm-misc-next.
I would really like to get an rb from other people on patch #2 before
proceeding.
Daniel, Dave and all the other usual suspects on the list what is your
opinion on this implementation?
On 2018年10月17日 16:09, Daniel Vetter wrote:
On Mon, Oct 15, 2018 at 04:55:48PM +0800, Chunming Zhou wrote:
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
+Jason as well.
On 2018年10月17日 18:22, Daniel Vetter wrote:
On Wed, Oct 17, 2018 at 11:17 AM zhoucm1 wrote:
On 2018年10月17日 16:09, Daniel Vetter wrote:
On Mon, Oct 15, 2018 at 04:55:48PM +0800, Chunming Zhou wrote:
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
On 2018年10月17日 18:24, Daniel Vetter wrote:
On Wed, Oct 17, 2018 at 11:29 AM Koenig, Christian
wrote:
Am 17.10.18 um 11:17 schrieb zhoucm1:
[SNIP]
+struct drm_syncobj_signal_pt {
+struct dma_fence_array *base;
Out of curiosity, why the pointer and not embedding? base is kinda
On 2018年10月18日 19:50, Christian König wrote:
Am 18.10.18 um 05:11 schrieb zhoucm1:
On 2018年10月17日 18:24, Daniel Vetter wrote:
On Wed, Oct 17, 2018 at 11:29 AM Koenig, Christian
wrote:
Am 17.10.18 um 11:17 schrieb zhoucm1:
[SNIP]
+struct drm_syncobj_signal_pt {
+ struct
On 2018年10月19日 16:55, Daniel Vetter wrote:
On Fri, Oct 19, 2018 at 10:29:55AM +0800, zhoucm1 wrote:
On 2018年10月18日 19:50, Christian König wrote:
Am 18.10.18 um 05:11 schrieb zhoucm1:
On 2018年10月17日 18:24, Daniel Vetter wrote:
On Wed, Oct 17, 2018 at 11:29 AM Koenig, Christian
wrote:
Am
On 2018年10月19日 17:20, zhoucm1 wrote:
On 2018年10月19日 16:55, Daniel Vetter wrote:
On Fri, Oct 19, 2018 at 10:29:55AM +0800, zhoucm1 wrote:
On 2018年10月18日 19:50, Christian König wrote:
Am 18.10.18 um 05:11 schrieb zhoucm1:
On 2018年10月17日 18:24, Daniel Vetter wrote:
On Wed, Oct 17, 2018
[snip]
Went boom:
https://bugs.freedesktop.org/show_bug.cgi?id=108490
Can we revert pls?
Sorry for bug, please.
In fact, the bug is already caught and fixed, just the fix part isn't
in patch#1, but in patch#2:
Have you reverted? If not, I can send that fix in one minute.
Regards,
David Z
On 2018年10月19日 18:50, Chris Wilson wrote:
Quoting Chunming Zhou (2018-10-19 11:26:41)
Signed-off-by: Chunming Zhou
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/
On 2018年10月19日 19:26, zhoucm1 wrote:
On 2018年10月19日 18:50, Chris Wilson wrote:
Quoting Chunming Zhou (2018-10-19 11:26:41)
Signed-off-by: Chunming Zhou
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 7 +--
1 file changed, 5 insertions
On 2018年10月19日 20:08, Koenig, Christian wrote:
Am 19.10.18 um 14:01 schrieb zhoucm1:
On 2018年10月19日 19:26, zhoucm1 wrote:
On 2018年10月19日 18:50, Chris Wilson wrote:
Quoting Chunming Zhou (2018-10-19 11:26:41)
Signed-off-by: Chunming Zhou
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Christian
On 2018年10月22日 16:34, Chris Wilson wrote:
Quoting Chunming Zhou (2018-10-21 12:14:24)
v2:
add a mutex between sync_cb execution and free.
The result would appear to be that syncobj->lock is relegated to
protecting the pt_list and the mutex would only be needed for the
syncobj->cb_list.
The p
On 2018年10月23日 15:51, Chris Wilson wrote:
Quoting Chunming Zhou (2018-10-23 02:50:08)
v2:
add a mutex between sync_cb execution and free.
v3:
clearly separating the roles for pt_lock and cb_mutex (Chris)
v4:
the cb_mutex should be taken outside of the pt_lock around this if() block.
(Chris)
On 2018年10月23日 17:01, Chris Wilson wrote:
Quoting Chunming Zhou (2018-10-23 08:57:54)
v2:
add a mutex between sync_cb execution and free.
v3:
clearly separating the roles for pt_lock and cb_mutex (Chris)
v4:
the cb_mutex should be taken outside of the pt_lock around this if() block.
(Chris)
v
will send a fix soon.
Thanks,
David
On 2018年10月25日 15:57, Koenig, Christian wrote:
Am 25.10.18 um 09:51 schrieb Maarten Lankhorst:
Op 25-10-18 om 08:53 schreef Christian König:
Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing):
Reviewed-by: Chunming Zhou
NAK, GFP_ATOMIC should be avoid
pls ignore this one, please review v2.
On 2018年10月25日 16:36, Chunming Zhou wrote:
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are ca
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static struct dma_fence
uint64_t point)
{
struct drm_syncobj_signal_pt *signal_pt;
+ struct dma_fence *f = NULL;
+ struct drm_syncobj_stub_fence *fence =
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static struct dma_fence
uint64_t point)
{
struct
On 2018年10月25日 17:23, Koenig, Christian wrote:
Am 25.10.18 um 11:20 schrieb zhoucm1:
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -111,15 +111,16 @@ static
On 2018年10月25日 17:30, Koenig, Christian wrote:
Am 25.10.18 um 11:28 schrieb zhoucm1:
On 2018年10月25日 17:23, Koenig, Christian wrote:
Am 25.10.18 um 11:20 schrieb zhoucm1:
On 2018年10月25日 17:11, Koenig, Christian wrote:
Am 25.10.18 um 11:03 schrieb zhoucm1:
On 2018年10月25日 16:56
On 2018年10月25日 17:38, Christian König wrote:
Am 25.10.18 um 11:35 schrieb Daniel Vetter:
On Thu, Oct 25, 2018 at 04:36:34PM +0800, Chunming Zhou wrote:
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock
on line 389 but
Thanks, Could you help to submit to drm-misc again?
-David
On 2018年10月26日 15:43, Christian König wrote:
Am 26.10.18 um 08:20 schrieb Chunming Zhou:
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock
on line 389 but uses
On 2018年10月26日 16:32, Daniel Vetter wrote:
On Fri, Oct 26, 2018 at 5:50 AM Zhou, David(ChunMing)
wrote:
Make igt for cross-driver, I think you should rename it first, not an intel
specific. NO company wants their employee working on other company stuff.
You can rename it to DGT(drm graphics
On 2018年10月31日 20:07, Chris Wilson wrote:
drivers/gpu/drm/drm_syncobj.c:181:6: warning: no previous prototype for
‘drm_syncobj_add_callback’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_syncobj.c:190:6: warning: no previous prototype for
‘drm_syncobj_remove_callback’ [-Wmissing-prototypes]
Fix
On 2018年04月26日 23:06, Michel Dänzer wrote:
From: Michel Dänzer
When it's set, TTM tries to allocate huge pages if possible.
Do you mean original driver doesn't do this?
From the code, driver always try huge pages if
CONFIG_TRANSPARENT_HUGEPAGE is enabled.
Regards,
David Zhou
Drivers
wh
1 - 100 of 170 matches
Mail list logo
