Am 05.11.19 um 14:50 schrieb Daniel Vetter:
> On Tue, Nov 5, 2019 at 2:39 PM Christian König
> wrote:
>> Am 05.11.19 um 11:52 schrieb Daniel Vetter:
>>> On Tue, Oct 29, 2019 at 11:40:49AM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>really no business holding struct_mutex while doing copy_*_user. But
>I haven't
Am 16.10.19 um 16:23 schrieb Daniel Vetter:
> On Wed, Oct 16, 2019 at 3:46 PM Koenig, Christian
> wrote:
>> Am 08.10.19 um 10:55 schrieb Daniel Vetter:
>>> On Wed, Oct 02, 2019 at 08:37:50AM +0000, Koenig, Christian wrote:
>>>> Hi Daniel,
>>>>
>
Am 08.10.19 um 10:55 schrieb Daniel Vetter:
> On Wed, Oct 02, 2019 at 08:37:50AM +0000, Koenig, Christian wrote:
>> Hi Daniel,
>>
>> once more a ping on this. Any more comments or can we get it comitted?
> Sorry got a bit smashed past weeks, but should be resurrected now b
Hi Daniel,
once more a ping on this. Any more comments or can we get it comitted?
Thanks,
Christian.
Am 24.09.19 um 11:50 schrieb Christian König:
> Am 17.09.19 um 16:56 schrieb Daniel Vetter:
>> [SNIP]
+ /* When either the importer or the exporter
can't
Am 27.09.19 um 13:15 schrieb Anna Karas:
> Update references to reservation.c and reservation.h since these files
> have been renamed to dma-resv.c and dma-resv.h respectively.
>
> Cc: Christian König
> Link: https://patchwork.freedesktop.org/patch/323401/?series=65037=1
> Signed-off-by: Anna
Am 26.09.19 um 16:32 schrieb Anna Karas:
> Update references to reservation.c and reservation.h since these files
> have been renamed to dma-resv.c and dma-resv.h respectively.
The subject line is wrong since this isn't a i915 related patch, but
apart from that it looks good to me.
Regards,
Am 17.09.19 um 16:56 schrieb Daniel Vetter:
> [SNIP]
>>> +/* When either the importer or the exporter can't handle
>>> dynamic
>>> + * mappings we cache the mapping here to avoid issues with the
>>> + * reservation object lock.
>>> +
Am 17.09.19 um 15:45 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 01:24:10PM +0000, Koenig, Christian wrote:
>> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
>>> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
>>>> Am 17.09.19 um 14:31 schrieb Da
Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 12:40:51PM +0000, Koenig, Christian wrote:
>> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
>>> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>>>> Ping? Any further comment on t
Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>> Ping? Any further comment on this or can't we merge at least the locking
>> change?
> I was at plumbers ...
>> Christian.
>>
>> Am 11.09.19 um 12:53 schrieb Christian König:
>>> Am
Am 03.09.19 um 10:16 schrieb Daniel Vetter:
> On Thu, Aug 22, 2019 at 07:53:53AM +0000, Koenig, Christian wrote:
>> Am 22.08.19 um 08:54 schrieb Daniel Vetter:
>>> Full audit of everyone:
>>>
>>> - i915, radeon, amdgpu should be clean per their maintainers.
&
Am 24.08.19 um 21:12 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-24 20:04:43)
>> Am 24.08.19 um 15:58 schrieb Chris Wilson:
>>> In order to allow dma-fence-array as a generic container for fences, we
>>> need to allow for it to contain other dma-fence-arr
Am 24.08.19 um 15:58 schrieb Chris Wilson:
> In order to allow dma-fence-array as a generic container for fences, we
> need to allow for it to contain other dma-fence-arrays. By giving each
> dma-fence-array construction their own lockclass, we allow different
> types of dma-fence-array to nest,
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
> On Thu, Aug 22, 2019 at 07:56:56AM +0000, Koenig, Christian wrote:
>> Am 22.08.19 um 08:49 schrieb Daniel Vetter:
>>> With nouveau fixed all ttm-using drives have the correct nesting of
>>> mmap_sem vs dma_resv, and
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
> With nouveau fixed all ttm-using drives have the correct nesting of
> mmap_sem vs dma_resv, and we can just lock the buffer.
>
> Assuming I didn't screw up anything with my audit of course.
>
> v2:
> - Dont forget wu_mutex (Christian König)
> - Keep
Am 22.08.19 um 08:54 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>really no business holding struct_mutex while doing copy_*_user. But
>I haven't
Am 21.08.2019 20:28 schrieb "Thomas Hellström (VMware)"
:
On 8/21/19 8:11 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> wrote:
>> On 8/21/19 6:34 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
Am 21.08.19 um 16:47 schrieb Daniel Vetter:
> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> wrote:
>> On 8/21/19 4:09 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
>>> wrote:
On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> On
Am 20.08.19 um 17:41 schrieb Daniel Vetter:
> On Tue, Aug 20, 2019 at 5:34 PM Koenig, Christian
> wrote:
>> Am 20.08.19 um 17:21 schrieb Daniel Vetter:
>>> On Tue, Aug 20, 2019 at 5:16 PM Koenig, Christian
>>> wrote:
>>>> Am 20.08.19 um 16:53 schrieb D
Am 20.08.19 um 17:21 schrieb Daniel Vetter:
> On Tue, Aug 20, 2019 at 5:16 PM Koenig, Christian
> wrote:
>> Am 20.08.19 um 16:53 schrieb Daniel Vetter:
>>> With nouveau fixed all ttm-using drives have the correct nesting of
>>> mmap_sem vs dma_resv, a
Am 20.08.19 um 16:53 schrieb Daniel Vetter:
> With nouveau fixed all ttm-using drives have the correct nesting of
> mmap_sem vs dma_resv, and we can just lock the buffer.
>
> Assuming I didn't screw up anything with my audit of course.
>
> Signed-off-by: Daniel Vetter
> Cc: Christian Koenig
>
Am 20.08.19 um 16:53 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>really no business holding struct_mutex while doing copy_*_user. But
>I haven't
Am 17.08.19 um 17:30 schrieb Chris Wilson:
> The timestamp and the cb_list are mutually exclusive, the cb_list can
> only be added to prior to being signaled (and once signaled we drain),
> while the timestamp is only valid upon being signaled. Both the
> timestamp and the cb_list are only valid
Am 17.08.19 um 17:27 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-17 16:20:12)
>> Am 17.08.19 um 16:47 schrieb Chris Wilson:
>>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>>> index 89d96e3e6df6..2c21115b1a37 100644
>>&g
Am 17.08.19 um 17:23 schrieb Chris Wilson:
> Currently dma_fence_signal() tries to avoid the spinlock and only takes
> it if absolutely required to walk the callback list. However, to allow
> for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the
Am 17.08.19 um 16:47 schrieb Chris Wilson:
> The timestamp and the cb_list are mutually exclusive, the cb_list can
> only be added to prior to being signaled (and once signaled we drain),
> while the timestamp is only valid upon being signaled. Both the
> timestamp and the cb_list are only valid
Am 17.08.19 um 16:47 schrieb Chris Wilson:
> Currently dma_fence_signal() tries to avoid the spinlock and only takes
> it if absolutely required to walk the callback list. However, to allow
> for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the
Am 17.08.19 um 13:39 schrieb Chris Wilson:
> Rearrange the couple of 32-bit atomics hidden amongst the field of
> pointers that unnecessarily caused the compiler to insert some padding,
> shrinks the size of the base struct dma_fence from 80 to 72 bytes on
> x86-64.
>
> Signed-off-by: Chris Wilson
Am 15.08.19 um 21:29 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-15 20:03:13)
>> Quoting Daniel Vetter (2019-08-15 19:48:42)
>>> On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson
>>> wrote:
Quoting Daniel Vetter (2019-08-14 18:20:53)
> On Sun, Aug 11, 2019 at 10:15:23AM +0100,
Am 14.08.19 um 22:07 schrieb Daniel Vetter:
> On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote:
>> Quoting Chris Wilson (2019-08-14 19:24:01)
>>> This reverts
>>> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
>>> dd7a7d1ff2f1 ("drm/i915: use new
Am 14.08.19 um 20:26 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-14 19:24:01)
>> This reverts
>> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
>> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
>> 0e1d8083bddb ("dma-buf: further relax
Am 14.08.19 um 19:48 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-14 18:38:20)
>> Quoting Chris Wilson (2019-08-14 18:22:53)
>>> Quoting Chris Wilson (2019-08-14 18:06:18)
Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> + }
Am 14.08.19 um 04:54 schrieb Stephen Rothwell:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
>drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>drivers/gpu/drm/i915/i915_vma.c
>drivers/gpu/drm/i915/i915_gem_batch_pool.c
>
Am 13.08.19 um 10:25 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-13 07:59:28)
>> Am 12.08.19 um 16:53 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2019-08-12 15:50:59)
>>>> Am 12.08.19 um 16:43 schrieb Chris Wilson:
>>>>> Q
Am 12.08.19 um 16:53 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-12 15:50:59)
>> Am 12.08.19 um 16:43 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2019-08-12 15:34:32)
>>>> Am 10.08.19 um 17:34 schrieb Chris Wilson:
>>>>>
Am 12.08.19 um 17:42 schrieb Chris Wilson:
> During release of the syncpt, we remove it from the list of syncpt and
> the tree, but only if it is not already been removed. However, during
> signaling, we first remove the syncpt from the list. So, if we
> concurrently free and signal the syncpt,
Am 12.08.19 um 16:43 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-12 15:34:32)
>> Am 10.08.19 um 17:34 schrieb Chris Wilson:
>>> Move the duplicated code within dma-fence.c into the header for wider
>>> reuse. In the process apply a small micro
Am 10.08.19 um 17:34 schrieb Chris Wilson:
> Move the duplicated code within dma-fence.c into the header for wider
> reuse. In the process apply a small micro-optimisation to only prune the
> fence->cb_list once rather than use list_del on every entry.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko
Am 11.08.19 um 18:25 schrieb Chris Wilson:
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
> v3: Be careful not to flag an error if we race against
Am 11.08.19 um 11:15 schrieb Chris Wilson:
> Now that dma_fence_signal always takes the spinlock to flush the
> cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> avoid code repetition.
>
> Suggested-by: Christian König
> Signed-off-by: Chris Wilson
> Cc: Christian König
How about this instead:
Setting array->base.error = 1 during initialization.
Then cmpxchg(array->base.error, 1, error) whenever a fence in the array
signals.
And then finally cmpxchg(array->base.error, 1, 0) when the array itself
signals.
Christian.
Am 11.08.19 um 14:21 schrieb Chris
Am 10.08.19 um 17:34 schrieb Chris Wilson:
> Allow for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the signaling mechanism around every fence.
> (The cost of interrupts is too darn high, to revive an old meme.)
> This means that we may have a cb_list
Am 10.08.19 um 17:34 schrieb Chris Wilson:
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc:
Am 08.08.19 um 09:29 schrieb Daniel Vetter:
> On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
> wrote:
>> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
>>> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
>>>> On Thu, Jun 27, 2019 at 09:28:11AM +0200
Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
>> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
>>> Hi Daniel,
>>>
>>> those fails look like something random to me and not related to my patch
>>> set. Correct?
>>
Am 07.08.19 um 14:19 schrieb Chris Wilson:
> Quoting Christian König (2019-08-07 13:08:38)
>> Am 06.08.19 um 21:57 schrieb Chris Wilson:
>>> If we add to shared-list during the read, ... Hmm, actually we should
>>> return num_list, i.e.
>>>
>>> do {
>>>*list = rcu_dereference(obj->fence);
Am 31.07.19 um 02:51 schrieb Brian Welty:
[SNIP]
>> +/*
>> + * Memory types for drm_mem_region
>> + */
> #define DRM_MEM_SWAP?
btw what did you have in mind for this? Since we use shmem we kinda don't
know whether the BO is actually swapped out or not, at least on the
Am 30.07.19 um 11:38 schrieb Daniel Vetter:
> On Tue, Jul 30, 2019 at 08:45:57AM +0000, Koenig, Christian wrote:
>> Yeah, that looks like a good start. Just a couple of random design
>> comments/requirements.
>>
>> First of all please restructure the changes so th
Yeah, that looks like a good start. Just a couple of random design
comments/requirements.
First of all please restructure the changes so that you more or less
have the following:
1. Adding of the new structures and functionality without any change to
existing code.
2. Replacing the existing
Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
Even then it so useless (which drm driver is this message for???) that I
want to remove them all :(
>>> Yeah, agree. I mean it is nice if the core drm functions use a prefix
>>> for debug output.
>>>
>>> But I actually don't see the point for
Am 19.07.19 um 11:31 schrieb Daniel Vetter:
> On Fri, Jul 19, 2019 at 09:14:05AM +0000, Koenig, Christian wrote:
>> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
>>> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
>>>> Am 26.06.19 um 14:29 schrieb Danie
Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
>> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
>>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
>>> [SNIP]
>>> Also I looked at CI results and stuff, I guess you
Am 18.07.19 um 18:15 schrieb Sam Ravnborg:
> drm_file used drm_magic_t from uapi/drm/drm.h.
> This is a simple unsigned int.
> Just opencode it as such to break the dependency from this header file
> to uapi.
Mhm, why do you want to remove UAPI dependency here in the first place?
I mean the type
Am 18.07.19 um 18:46 schrieb Chris Wilson:
> Quoting Sam Ravnborg (2019-07-18 17:14:58)
>> drm_print.h used DRM_NAME - thus adding a dependency from
>> include/drm/drm_print.h => uapi/drm/drm.h
>>
>> Hardcode the name "drm" to break this dependency.
>> The idea is that there shall be a minimal
Am 16.07.19 um 23:37 schrieb Rob Clark:
> From: Rob Clark
>
> Needed in the following patch for cache operations.
Well have you seen that those callbacks are deprecated?
>* Deprecated hook in favour of _gem_object_funcs.pin.
>* Deprecated hook in favour of
Hi Lionel,
sorry for the delayed response, I'm just back from vacation.
Am 03.07.19 um 11:17 schrieb Lionel Landwerlin:
> On 03/07/2019 11:56, Chris Wilson wrote:
>> Quoting Lionel Landwerlin (2019-07-01 12:34:33)
>>> + syncobj = drm_syncobj_find(eb->file,
>>> user_fence.handle);
Am 12.07.19 um 10:03 schrieb Chris Wilson:
> Since kmalloc() will round up the allocation to the next slab size or
> page, it will normally return a pointer to a memory block bigger than we
> asked for. We can query for the actual size of the allocated block using
> ksize() and expand our variable
Am 26.06.19 um 10:17 schrieb Daniel Vetter:
> On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
>> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
>>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks.
Am 24.06.19 um 16:41 schrieb Daniel Vetter:
> On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote:
>> Am 24.06.19 um 13:23 schrieb Koenig, Christian:
>>> Am 21.06.19 um 18:27 schrieb Daniel Vetter:
>>>
>>>> So I pondered a few ideas
Am 21.06.19 um 18:27 schrieb Daniel Vetter:
>>> Your scenario here is new, and iirc my suggestion back then was to
>>> count the number of pending mappings so you don't go around calling
>>> ->invalidate on mappings that don't exist.
>> Well the key point is we don't call invalidate on mappings,
Am 14.06.19 um 22:35 schrieb Daniel Vetter:
> The idea is that gem_prime_export is deprecated in favor of
> obj_funcs.export. That's much easier to do if both have matching
> function signatures.
>
> Signed-off-by: Daniel Vetter
> Cc: Russell King
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
>
Am 04.06.19 um 14:39 schrieb Chris Wilson:
> If we have to drop the seqcount & rcu lock to perform a krealloc, we
> have to restart the loop. In doing so, be careful not to lose track of
> the already acquired exclusive fence.
>
> Fixes: fedf54132d24 ("dma-buf: Restart
Am 27.05.19 um 14:10 schrieb Emil Velikov:
> On 2019/05/27, Christian König wrote:
>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
>>> From: Emil Velikov
>>>
>>> There are cases (in mesa and applications) where one would open the
>>> primary node without properly authenticating the client.
>>>
>>>
Am 03.05.19 um 14:09 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote:
>> Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
>>> On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
Add a structure for
Am 13.03.19 um 18:33 schrieb Michel Dänzer:
> [SNIP]
>>> Copy how? Using a GPU engine?
>> CPU maybe? Though I suppose that won't work if the buffer isn't CPU
>> accesible :/
> Well we do have a debug path for accessing invisible memory with the
> CPU.
>
> E.g. three
Am 13.03.19 um 17:16 schrieb Kazlauskas, Nicholas:
> On 3/13/19 11:54 AM, Christian König wrote:
>> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>>> On 2019-03-13 2:37 p.m., Christian König wrote:
Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
> On Wed, Mar 13, 2019 at 10:35:08AM +0100,
Adding Andrey who looked into cleaning this up a while ago as well.
Christian.
Am 03.02.19 um 16:41 schrieb Noralf Trønnes:
> This series removes drm_dev_unplug() and moves the unplugged state
> setting to drm_dev_unregister(). All drivers will now have access to the
> unplugged state if they so
Am 22.01.19 um 00:20 schrieb Chris Wilson:
> Rather than every backend and GPU driver reinventing the same wheel for
> user level debugging of HW execution, the common dma-fence framework
> should include the tracing infrastructure required for most client API
> level flow visualisation.
>
> With
Am 13.12.18 um 18:26 schrieb Daniel Vetter:
>>> Code sharing just because the code looks similar is imo a really
>>> bad idea, when the semantics are entirely different (that was also the
>>> reason behind not reusing all the cpu event stuff for dma_fence, they're
>>> not normal cpu events).
>>
Am 13.12.18 um 17:01 schrieb Daniel Vetter:
> On Thu, Dec 13, 2018 at 12:24:57PM +0000, Koenig, Christian wrote:
>> Am 13.12.18 um 13:21 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2018-12-13 12:11:10)
>>>> Am 13.12.18 um 12:37 schrieb Chris Wilson:
>>&
Am 13.12.18 um 13:21 schrieb Chris Wilson:
> 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 find
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.
>>
>> v2: return -EINVAL when the point is not submitted yet.
>> v3: fix reference counting bug, add flags
plementation has to also be
> able to support such dependencies.
> "
>
> Btw, we already add test case to igt, and tested by many existing test, like
> libdrm unit test, igt related test, vulkan cts, and steam games.
>
> -David
>> -Original Message-
>
Am 12.12.18 um 11:49 schrieb Daniel Vetter:
> On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote:
>> From: Christian König
>>
>> Use the dma_fence_chain object to create a timeline of fence objects
>> instead of just replacing the existing fence.
>>
>> v2: rebase and cleanup
>>
>>
Patches #1 and #3 are Reviewed-by: Christian König
Patch #2 is Acked-by: Christian König because
I can't judge if adding the counter in the thread structure is actually
a good idea.
In patch #4 I honestly don't understand at all how this stuff works, so
no-comment from my side on this.
Am 07.12.18 um 14:58 schrieb Daniel Vetter:
> On Fri, Dec 7, 2018 at 11:29 AM Chris Wilson wrote:
>> Quoting Patchwork (2018-12-07 10:27:46)
>>> == Series Details ==
>>>
>>> Series: igt: add timeline test cases (rev2)
>>> URL : https://patchwork.freedesktop.org/series/53743/
>>> State : failure
Am 07.12.18 um 13:34 schrieb Mika Kuoppala:
> Many errs of the form:
> drivers/gpu/drm/i915/selftests/intel_hangcheck.c: In function
> ‘__igt_reset_evict_vma’:
> ./include/linux/kern_levels.h:5:18: error: format ‘%x’ expects argument of
> type ‘unsigned int’, but argum
>
> Fixes: b312d8ca3a7c
Hi Stephen,
yeah, that is a known problem. I missed the change during rebase of the
revert.
Please see patch "2312f9842854 drm/v3d: fix broken build" which is
already in drm-misc-next and fixes the issue.
Christian.
Am 06.12.18 um 03:32 schrieb Stephen Rothwell:
> Hi all,
>
> After merging
Am 07.12.18 um 13:22 schrieb Chris Wilson:
> Many errs of the form:
> drivers/gpu/drm/i915/selftests/intel_hangcheck.c: In function
> ‘__igt_reset_evict_vma’:
> ./include/linux/kern_levels.h:5:18: error: format ‘%x’ expects argument of
> type ‘unsigned int’, but argum
>
> Fixes: b312d8ca3a7c
Hi Harish,
Am 26.11.18 um 21:59 schrieb Kasiviswanathan, Harish:
> Thanks Tejun,Eric and Christian for your replies.
>
> We want GPUs resource management to work seamlessly with containers and
> container orchestration. With the Intel / bpf based approach this is not
> possible.
I think one
Am 23.11.18 um 18:36 schrieb Eric Anholt:
> Christian König writes:
>
>> Am 20.11.18 um 21:57 schrieb Eric Anholt:
>>> Kenny Ho writes:
>>>
Account for the number of command submitted to amdgpu by type on a per
cgroup basis, for the purpose of profiling/monitoring applications.
>>> For
Am 22.11.18 um 17:51 schrieb Daniel Vetter:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() callsites trigger, and
Am 22.11.18 um 17:51 schrieb Daniel Vetter:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
>
Am 10.11.18 um 15:56 schrieb Noralf Trønnes:
> This patchset adds a GEM object function table and makes use of it in
> the CMA helper.
>
> This was originally part of a shmem helper series[1] that didn't make
> it. Daniel and Christian showed interest in the vtable part so I have
> hooked it up to
Am 26.10.18 um 10:28 schrieb zhoucm1:
> Thanks, Could you help to submit to drm-misc again?
Done.
Christian.
>
> -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
>>>
Am 26.10.18 um 10:03 schrieb Chris Wilson:
> We need to serialise the addition of a new fence into the shared list
> such that the fence is visible before we claim it is there. Otherwise a
> concurrent reader of the shared fence list will see an uninitialised
> fence slot before it is set.
>
>
Am 25.10.18 um 12:36 schrieb Maarten Lankhorst:
> Op 25-10-18 om 12:21 schreef 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 GFP_KERNEL
>>
>>Find functions that refer to
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, Christian König wrote:
+++ b/drivers/gpu/drm/drm_syncobj.c
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 struct dma_fence
uint64_t point
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 drm_syncobj_signal_pt *signal_pt;
+struct dma_fence *f = NULL;
+
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 avoided.
>>
>> The correct solution is to move the allocation out of the spinlock or
Am 23.10.18 um 11:37 schrieb Chunming Zhou:
> 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)
> v5:
> fix a corner case
> v6:
>
Am 23.10.18 um 11:11 schrieb Chris Wilson:
> Quoting zhoucm1 (2018-10-23 10:09:01)
>>
>> 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
Am 20.06.2018 18:22 schrieb Chris Wilson :
Fix i915's CI build after the removal of the dmabuf->kmap interface that
left the mock routines intact.
In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0:
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error:
95 matches
Mail list logo
