ttwoch, 11. August 2021 18:52
An: Deucher, Alexander ; Koenig, Christian
Cc: Liu, Leo ; Zhu, James ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Betreff: [PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN
ring_end_use hooks
From: Michel Dänzer
In c
gards,
Christian.
Von: Quan, Evan
Gesendet: Donnerstag, 12. August 2021 04:42
An: Koenig, Christian ; Michel Dänzer
; Deucher, Alexander
Cc: Liu, Leo ; Zhu, James ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Betreff: RE: [PATCH 2/2] drm/a
Reviewed-by: Christian König
Von: Daniel Gomez
Gesendet: Donnerstag, 18. März 2021 09:32
Cc: dag...@gmail.com ; Daniel Gomez ;
Deucher, Alexander ; Koenig, Christian
; David Airlie ; Daniel Vetter
; amd-...@lists.freedesktop.org
; dri-devel
2021 11:46
An: Daniel Vetter ; Koenig, Christian
; linux-graphics-maintai...@vmware.com
Cc: DRI Development
Betreff: vmwgfx leaking bo pins?
Hi,
I tried latest drm-fixes today and saw a lot of these: Fallout from ttm
rework?
/Thomas
[ 298.404788] WARNING: CPU: 1 PID: 3839 at
drivers/g
__
Von: Matthew Auld
Gesendet: Donnerstag, 9. September 2021 16:56
An: Christian König ; Koenig, Christian
Cc: Thomas Hellström ; ML dri-devel
Betreff: i915 ttm_tt shmem backend
Hi Christian,
We are looking into using shmem as a ttm_tt backend in i915 for cached
system memory objects. We would al
Seconded, there is one include for each hardware version.
At least of hand I don't see a duplicate.
Von: Simon Ser
Gesendet: Donnerstag, 30. September 2021 12:17
An: Guo Zhengkui
Cc: Deucher, Alexander ; Koenig, Christian
; Pan, Xinhui ; David Airlie
; D
mory-mgmt developers.
> I think Noralf Tronnes or Gerd Hoffmann would also make good reviewers
> for this, fairly close to what they've been working on in the past.
I will try to take another look next week. Busy as usual here.
Christian.
> -Daniel
>
>> Best regards
>>
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 06.05.19 um 10:04 schrieb Daniel Vetter:
> [SNIP]
+ /* pin buffer into GTT */
+ return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
>>> This is kinda what I mean with "shouldn't we pin the attachment" - afaiui
>>> this can fail is someone already pinned the buffer into vram. And that
>>>
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
> add ticket for display bo, so that it can preempt busy bo.
>
> Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
> Signed-off-by: Chunming Zhou
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
> 1 file changed, 17 i
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 into this EBUSY condition in TTM check if
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.
>>>
>>> basic
Am 07.05.19 um 13:37 schrieb Thomas Hellstrom:
> [CAUTION: External Email]
>
> On 5/7/19 1:24 PM, Christian König wrote:
>> Am 07.05.19 um 13:22 schrieb zhoucm1:
>>>
>>>
>>> On 2019年05月07日 19:13, Koenig, Christian wrote:
>>>> Am 07.05.19 um 1
Am 08.05.19 um 10:34 schrieb Thomas Hellstrom:
> [SNIP]
No, what I mean is to add the acquire_ctx as separate parameter to
ttm_mem_evict_first().
E.g. we only need it in this function and it is actually not related
to the ttm operation context filled in by the driver.
>>>
>
Am 08.05.19 um 14:15 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Wed, May 8, 2019 at 2:00 PM Christian König
> wrote:
>> Am 08.05.19 um 12:11 schrieb Daniel Vetter:
>>> On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
On Tue, May 07, 2019 at 10:13:30AM +0200, Chris
I've foudn one more problem with this.
With lockdep enabled I get a warning because ttm_eu_reserve_buffers()
has called ww_acquire_done() on the ticket (which essentially means we
are done, no more locking with that ticket).
The simplest solution is probably to just remove the call to
ww_acqui
Am 10.05.19 um 16:57 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 8:28 AM Christian König
> wrote:
>> Am 09.05.19 um 23:04 schrieb Kenny Ho:
>>> + /* only allow bo from the same cgroup or its ancestor to be imported
>>> */
>>> + if (drmcgrp != NULL &&
>>> +
Am 10.05.19 um 17:07 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 8:31 AM Christian König
> wrote:
>> I think it is a good approach to try to add a global limit first and
>> when that's working go ahead with limiting device specific resources.
> What are some of the gl
Am 10.05.19 um 17:25 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 11:08 AM Koenig, Christian
> wrote:
>> Am 10.05.19 um 16:57 schrieb Kenny Ho:
>>> On Fri, May 10, 2019 at 8:28 AM Christian König
>>> wrote:
>>>> Am 0
ssage
Subject: Re: [PATCH 11/11] drm/amdgpu: stop removing BOs from the LRU during CS
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Olsak, Marek" ,"Liang,
Prike"
,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.o
Am 16.05.19 um 04:29 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
>> On 5/9/2019 2:04 PM, Kenny Ho wrote:
>>> There are four control file types,
>>> stats (ro) - display current measured values for a resource
>>> max (rw) - limits for a reso
Am 16.05.19 um 12:46 schrieb Chunming Zhou:
> Feature is controlled by DRM_CAP_SYNCOBJ_TIMELINE drm capability.
>
> Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
> ---
> include/drm/drm.h| 1 +
> tests/amdgpu/syncobj_tests.c | 8
> 2 files changed, 9 inserti
Am 16.05.19 um 14:28 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Thu, May 16, 2019 at 09:25:31AM +0200, Christian König wrote:
>> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
>>> Am 16.05.19 um 04:29 schrieb Kenny Ho:
>>>> [CAUTION: External E
Am 17.05.19 um 11:55 schrieb Michel Dänzer:
> [CAUTION: External Email]
>
> On 2019-05-17 11:47 a.m., zhoucm1 wrote:
>> ping, Could you help check in patch to gitlab? My connection to gitlab
>> still has problem.
> Please follow the process documented in include/drm/README for
> include/drm/drm.h .
28 schrieb Zhou, David(ChunMing):
Can you guy do that? Otherwise if kernel driver doesn't set that cap, test
could fail.
Thanks,
-David
Original Message
Subject: Re: [PATCH libdrm] enable syncobj test depending on capability
From: "Koenig, Christian"
To: Michel
h would not be the case if nothing hangs.
>
> Andrey
>
>
> From: Erico Nunes
> Sent: 17 May 2019 17:42:48
> To: Grodzovsky, Andrey
> Cc: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); David
> Airlie; Daniel Vetter; Luc
Am 20.05.19 um 18:26 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote:
>> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
>>> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
>>> GEM VRA
Am 21.05.19 um 01:16 schrieb Erico Nunes:
> [CAUTION: External Email]
>
> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> only deleted when the timeout handler is able to be cancelled
> successfully.
>
> In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
Am 21.05.19 um 14:16 schrieb Erico Nunes:
> [CAUTION: External Email]
>
> On Tue, May 21, 2019 at 8:47 AM Koenig, Christian
> wrote:
>> Am 21.05.19 um 01:16 schrieb Erico Nunes:
>>> [CAUTION: External Email]
>>>
>>> After "5918045c4ed4 drm/sch
Am 21.05.19 um 16:13 schrieb Alex Deucher:
> [CAUTION: External Email]
>
> On Tue, May 21, 2019 at 2:48 AM Koenig, Christian
> wrote:
>> Am 21.05.19 um 01:16 schrieb Erico Nunes:
>>> [CAUTION: External Email]
>>>
>>> After "5918045c4ed4 drm/sch
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
> 982c0500fd1a8012c31d3c9dd8de285129904656"
>
> Signed-off-by: Chunming Zhou
> Suggested-by: Michel Dänzer
Am 22.05.19 um 13:29 schrieb Daniel Vetter:
> [SNIP]
> Forgot to add: Iirc it was buffer sharing between i915 and amdgpu that
> hits this. Can't say for sure since intel-gfx isn't cc'ed on this
> version, so our CI hasn't picked this up.
I've changed this so that when exporter/importer disagree on
Am 22.05.19 um 20:30 schrieb Daniel Vetter:
> [SNIP]
>> Well, it seems you are making incorrect assumptions about the cache
>> maintenance of DMA-buf here.
>>
>> At least for all DRM devices I'm aware of mapping/unmapping an
>> attachment does *NOT* have any cache maintenance implications.
>>
>> E.
Am 23.05.19 um 13:50 schrieb Zhou, David(ChunMing):
> 在 2019/5/23 19:03, Christian König 写道:
>> [CAUTION: External Email]
>>
>> Am 23.05.19 um 12:24 schrieb zhoucm1:
>>>
>>> On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during
Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
> [CAUTION: External Email]
>
> From: Thomas Hellstrom
>
> With SEV encryption, all DMA memory must be marked decrypted
> (AKA "shared") for devices to be able to read it. In the future we might
> want to be able to switch normal (encrypted)
Am 24.05.19 um 11:55 schrieb Thomas Hellstrom:
> [CAUTION: External Email]
>
> On 5/24/19 11:11 AM, Thomas Hellstrom wrote:
>> Hi, Christian,
>>
>> On 5/24/19 10:37 AM, Koenig, Christian wrote:
>>> Am 24.05.19 um 10:11 schrieb Thomas Hellström (VM
Am 24.05.19 um 12:37 schrieb Thomas Hellstrom:
> [CAUTION: External Email]
>
> On 5/24/19 12:18 PM, Koenig, Christian wrote:
>> Am 24.05.19 um 11:55 schrieb Thomas Hellstrom:
>>> [CAUTION: External Email]
>>>
>>> On 5/24/19 11:11 AM, Thomas Hellstrom wrote
Am 27.05.19 um 10:17 schrieb Emil Velikov:
> From: Emil Velikov
>
> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> render node. A seemingly deliberate design decision.
>
> Hence we can drop the DRM_AUTH all together (details in follow-up patch)
> yet not all userspace c
Am 24.05.19 um 23:34 schrieb Kuehling, Felix:
> On 2019-05-23 5:06 a.m., Christian König wrote:
>> [CAUTION: External Email]
>>
>> Leaving BOs on the LRU is harmless. We always did this for VM page table
>> and per VM BOs.
>>
>> The key point is that BOs which couldn't be reserved can't be evicted.
Am 27.05.19 um 14:05 schrieb Emil Velikov:
> On 2019/05/27, Koenig, Christian wrote:
>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
>>> From: Emil Velikov
>>>
>>> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
>>> render
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.
>>>
>>> S
Am 27.05.19 um 15:26 schrieb Emil Velikov:
> On 2019/05/27, Daniel Vetter wrote:
>> On Mon, May 27, 2019 at 10:47:39AM +0000, Koenig, Christian wrote:
>>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
>>>> From: Emil Velikov
>>>>
>>>> Currently
Am 27.05.19 um 17:26 schrieb Daniel Vetter:
> On Mon, May 27, 2019 at 3:42 PM Koenig, Christian
> wrote:
>> Am 27.05.19 um 15:26 schrieb Emil Velikov:
>>> On 2019/05/27, Daniel Vetter wrote:
>>>> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
&
Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> [SNIP]
>> Might be a good idea looking into reverting it partially, so that at
>> least command submission and buffer allocation is still blocked.
> I thought the issue is a lot more than vainfo, it's pretty much every
> hacked up compositor under the s
Hi Thomas,
Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
> Hi, Tom,
>
> Thanks for the reply. The question is not graphics specific, but lies
> in your answer further below:
>
> On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
>> On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
>> [SNIP]
>> As for kernel
Am 28.05.19 um 18:10 schrieb Emil Velikov:
> On 2019/05/28, Daniel Vetter wrote:
>> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
>> wrote:
>>> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
>>>> [SNIP]
>>>>> Might be a good idea looking
Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
> On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
>> On 5/28/19 10:17 AM, Koenig, Christian wrote:
>>> Hi Thomas,
>>>
>>> Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
>>>> Hi, Tom,
>
Am 29.05.19 um 15:03 schrieb Emil Velikov:
> On 2019/05/29, Dave Airlie wrote:
>> On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
>>> On 2019/05/28, Koenig, Christian wrote:
>>>> Am 28.05.19 um 18:10 schrieb Emil Velikov:
>>>>> On 2019/05/28, Daniel
Am 07.04.19 um 13:44 schrieb 易林:
> Hi, all:
> when analyzing v5.1 source code, I notice that in ttm_bo_add_move_fence,
> when reservation_object_reserve_shared failed and return ENOMEM,
> the fence's refcount increased without a pair decrement even after return to
> ttm_bo_add_move_fence's ca
Well first problem is I'm not sure if that is a good idea. Essentially
we want to get rid of TTM in the long run.
On the other hand this work might aid with that goal, so it might be
worth a try.
Second is that this might actually not work of hand. The problem is here:
> + /* TODO: This tes
Am 09.04.19 um 10:21 schrieb 易林:
>
>
>
>> Am 07.04.19 um 13:44 schrieb 易林:
>>> Hi, all:
>>> when analyzing v5.1 source code, I notice that in
>>> ttm_bo_add_move_fence,
>>> when reservation_object_reserve_shared failed and return ENOMEM,
>>> the fence's refcount increased without a pair decr
Am 08.04.19 um 13:59 schrieb Thomas Zimmermann:
[SNIP]
> If not for TTM, what would be the alternative? One VMA manager per
> memory region per device?
Since everybody vital seems to be on this mail thread anyway, let's use
it a bit for brain storming what a possible replacement for TTM should
l
Am 10.04.19 um 17:05 schrieb Grodzovsky, Andrey:
> On 4/10/19 10:41 AM, Christian König wrote:
>> Am 10.04.19 um 16:28 schrieb Grodzovsky, Andrey:
>>> On 4/10/19 10:06 AM, Christian König wrote:
Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
> On 4/9/19 10:50 AM, Christian König wrote:
>
Am 12.04.19 um 18:04 schrieb Thomas Hellstrom:
> Add a pointer to the struct vm_operations_struct in the bo_device, and
> assign that pointer to the default value currently used.
>
> The driver can then optionally modify that pointer and the new value
> can be used for each new vma created.
>
> Cc:
Am 15.04.19 um 01:37 schrieb Brian Yip:
> num_zones in the ttm_mem_global structure was never reset after calling
> ttm_mem_global_release(). Consequently, when multiple GPU drivers
> are loaded, and the first one fails to load its firmware, the second
> driver will attempt to load its own firmware
Am 12.04.19 um 17:53 schrieb Grodzovsky, Andrey:
> On 4/12/19 3:39 AM, Christian König wrote:
>> Am 11.04.19 um 18:03 schrieb Andrey Grodzovsky:
>>> Also reject TDRs if another one already running.
>>>
>>> v2:
>>> Stop all schedulers across device and entire XGMI hive before
>>> force signaling HW
Am 15.04.19 um 20:54 schrieb Dave Airlie:
>> Well, I've got commit rights as well.
>>
>> Going to remove the warning, add your rb and push everything if nobody
>> objects in the next hour or so.
> So this got committed and is in my -next tree, but where is the
> userspace and igt tests?
I was wait
Am 16.04.19 um 11:10 schrieb Karol Herbst:
> On Tue, Apr 16, 2019 at 8:38 AM Christian König
> wrote:
>> Am 16.04.19 um 02:35 schrieb Karol Herbst:
>>> Kobjects are supposed to be dynamically allocated, but with recent changes
>>> this rule was violated. Reverting those commits fixes crashes when
Am 15.04.19 um 21:17 schrieb Daniel Vetter:
> On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann wrote:
>> Hi
>>
>> Am 15.04.19 um 17:54 schrieb Daniel Vetter:
>>> On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote:
Hi
Am 09.04.19 um 09:12 schrieb kra...@redhat.com:
>>
Am 16.04.19 um 12:54 schrieb Karol Herbst:
> On Tue, Apr 16, 2019 at 11:12 AM Koenig, Christian
> wrote:
>> Am 16.04.19 um 11:10 schrieb Karol Herbst:
>>> On Tue, Apr 16, 2019 at 8:38 AM Christian König
>>> wrote:
>>>> Am 16.04.19 um 02:35 schrieb Karol
Am 16.04.19 um 13:03 schrieb Daniel Vetter:
> On Tue, Apr 16, 2019 at 12:05 PM Koenig, Christian
> wrote:
>> Am 15.04.19 um 21:17 schrieb Daniel Vetter:
>>> On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann
>>> wrote:
>>>> Hi
>>>>
>>
Am 16.04.19 um 14:18 schrieb Daniel Vetter:
> On Tue, Apr 16, 2019 at 11:06:54AM +0000, Koenig, Christian wrote:
>> Am 16.04.19 um 12:54 schrieb Karol Herbst:
>>> On Tue, Apr 16, 2019 at 11:12 AM Koenig, Christian
>>> wrote:
>>>> Am 16.04.19 um 11:10 sch
Am 16.04.19 um 14:43 schrieb Daniel Vetter:
> On Tue, Apr 16, 2019 at 02:40:37PM +0200, Christian König wrote:
>> Am 16.04.19 um 14:30 schrieb Lionel Landwerlin:
>>> We've been somewhat inconsistent when adding the new ioctl and
>>> returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncob
Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
> On 4/16/19 5:47 AM, Christian König wrote:
>> Am 15.04.19 um 23:17 schrieb Eric Anholt:
>>> Andrey Grodzovsky writes:
>>>
From: Christian König
We now destroy finished jobs from the worker thread to make sure that
we never des
Am 16.04.19 um 17:42 schrieb Grodzovsky, Andrey:
> On 4/16/19 10:58 AM, Grodzovsky, Andrey wrote:
>> On 4/16/19 10:43 AM, Koenig, Christian wrote:
>>> Am 16.04.19 um 16:36 schrieb Grodzovsky, Andrey:
>>>> On 4/16/19 5:47 AM, Christian König wrote:
>>>>
Am 17.04.19 um 10:10 schrieb Daniel Vetter:
> On Wed, Apr 17, 2019 at 09:09:27AM +0200, Christian König wrote:
>> Am 16.04.19 um 23:40 schrieb Andres Rodriguez:
>>> After a recent commit, access to the DRM_AUTH ioctls become more
>>> permissive. This resulted in a buggy check for drm_master capabil
Hi guys,
well going back to the beginning once more because something doesn't fit
together here.
I mean what exactly is the purpose of 8059add0478e "drm: allow render
capable master with DRM_AUTH ioctls"?
When I read the code correctly the effect is that we ignore the DRM_AUTH
flag when also
Am 17.04.19 um 13:06 schrieb Daniel Vetter:
> On Wed, Apr 17, 2019 at 12:29 PM Koenig, Christian
> wrote:
>> Hi guys,
>>
>> well going back to the beginning once more because something doesn't fit
>> together here.
>>
>> I mean what exactly is
Am 17.04.19 um 14:00 schrieb Daniel Vetter:
> On Wed, Apr 17, 2019 at 11:18:35AM +0000, Koenig, Christian wrote:
>> Am 17.04.19 um 13:06 schrieb Daniel Vetter:
>>> On Wed, Apr 17, 2019 at 12:29 PM Koenig, Christian
>>> wrote:
>>> [SNIP]
>> Well, what y
Am 17.04.19 um 17:51 schrieb Emil Velikov:
> Hi guys,
>
> On 2019/04/17, Daniel Vetter wrote:
>> On Wed, Apr 17, 2019 at 02:46:06PM +0200, Christian König wrote:
>>> Am 17.04.19 um 14:35 schrieb Daniel Vetter:
>>>> On Wed, Apr 17, 2019 at 12:06:32PM +000
Am 17.04.19 um 19:59 schrieb Christian König:
> Am 17.04.19 um 19:53 schrieb Grodzovsky, Andrey:
>> On 4/17/19 1:17 PM, Christian König wrote:
>>> I can't review this patch, since I'm one of the authors of it, but in
>>> general your changes look good to me now.
>>>
>>> For patch #5 I think it migh
Am 17.04.19 um 20:29 schrieb Grodzovsky, Andrey:
> On 4/17/19 2:01 PM, Koenig, Christian wrote:
>> Am 17.04.19 um 19:59 schrieb Christian König:
>>> Am 17.04.19 um 19:53 schrieb Grodzovsky, Andrey:
>>>> On 4/17/19 1:17 PM, Christian König wrote:
>>>>>
Am 18.04.19 um 08:46 schrieb Daniel Vetter:
> On Wed, Apr 17, 2019 at 7:30 PM Koenig, Christian
> wrote:
>> Am 17.04.19 um 17:51 schrieb Emil Velikov:
>>> Hi guys,
>>>
>>> On 2019/04/17, Daniel Vetter wrote:
>>>> On Wed, Apr 17, 2019 at 02:46:0
Am 18.04.19 um 10:08 schrieb Daniel Vetter:
> On Wed, Apr 17, 2019 at 09:13:22PM +0200, Christian König wrote:
>> Am 17.04.19 um 21:07 schrieb Daniel Vetter:
>>> On Tue, Apr 16, 2019 at 08:38:33PM +0200, Christian König wrote:
Each importer can now provide an invalidate_mappings callback.
Am 18.04.19 um 10:26 schrieb Daniel Vetter:
> On Thu, Apr 18, 2019 at 08:06:03AM +0000, Koenig, Christian wrote:
>> Am 18.04.19 um 08:46 schrieb Daniel Vetter:
>>> On Wed, Apr 17, 2019 at 7:30 PM Koenig, Christian
>>> wrote:
>>>> Am 17.04.19 um 17
Well you at least have to give me time till after the holidays to get
going again :)
Not sure exactly jet why we need patch number 5.
And we should probably commit patch #1 and #2.
Christian.
Am 22.04.19 um 13:54 schrieb Grodzovsky, Andrey:
> Ping for patches 3, new patch 5 and patch 6.
>
> An
Am 23.04.19 um 14:31 schrieb Serge Semin:
> Since commit 4b050ba7a66c ("MIPS: pgtable.h: Implement the
> pgprot_writecombine function for MIPS") and commit c4687b15a848 ("MIPS: Fix
> definition of pgprot_writecombine()") write-combine vma mapping is
> available to be used by kernel subsystems for M
Am 24.04.19 um 10:01 schrieb Daniel Vetter:
> On Tue, Apr 23, 2019 at 4:42 PM Christian König
> wrote:
>> Well that's not so easy of hand.
>>
>> The basic problem here is that when you busy wait at this place you can
>> easily run into situations where application A busy waits for B while B busy
ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang, Prike"
,dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>
CC:
Well that's not so easy of hand.
The basic pro
Am 24.04.19 um 14:00 schrieb Thomas Hellstrom:
> Add a pointer to the struct vm_operations_struct in the bo_device, and
> assign that pointer to the default value currently used.
>
> The driver can then optionally modify that pointer and the new value
> can be used for each new vma created.
>
> Cc:
Am 24.04.19 um 14:05 schrieb Thomas Zimmermann:
> Hi Christian,
>
> Am 24.04.19 um 13:48 schrieb Thomas Zimmermann:
>> +
>> +/*
>> + * Helpers for struct ttm_bo_driver
>> + */
>> +
>> +static bool drm_is_gem_vram(struct ttm_buffer_object *bo)
>> +{
>> +return (bo->destroy == ttm_buffer_object_d
Am 24.04.19 um 21:14 schrieb Heiner Kallweit:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Acked-by: Christian König
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/
Am 25.04.2019 10:35 schrieb Thomas Hellstrom :
Hi, Christian,
On Wed, 2019-04-24 at 16:20 +0200, Thomas Hellström wrote:
> On Wed, 2019-04-24 at 14:10 +0000, Koenig, Christian wrote:
> > Am 24.04.19 um 14:00 schrieb Thomas Hellstrom:
> > > Add a pointer to the struct vm_operat
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_entry(&man->lru[i],
>>> +
Am 30.04.19 um 11:23 schrieb Sam Ravnborg:
> [CAUTION: External Email]
>
> Hi Thomas.
>
+
+/**
+ * Returns the container of type &struct drm_gem_vram_object
+ * for field bo.
+ * @bo: the VRAM buffer object
+ * Returns: The containing GEM VRAM object
>>
Am 30.04.19 um 14:03 schrieb Sahu, Satyajit:
> On 4/30/2019 5:02 PM, Christian König wrote:
>> [CAUTION: External Email]
>>
>> Am 30.04.19 um 13:12 schrieb Sahu, Satyajit:
>>> On 4/30/2019 4:29 PM, Christian König wrote:
[CAUTION: External Email]
Am 30.04.19 um 12:51 schrieb Sahu, Sa
Am 30.04.19 um 16:34 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Tue, Apr 30, 2019 at 04:26:32PM +0200, Christian König wrote:
>> Am 30.04.19 um 15:59 schrieb Daniel Vetter:
>>> On Tue, Apr 30, 2019 at 03:42:22PM +0200, Christian König wrote:
Am 29.04.19 um 10:40 schrieb Daniel V
Am 01.05.2019 11:00 schrieb Lionel Landwerlin :
[CAUTION: External Email]
On 16/04/2019 20:53, Dave Airlie wrote:
> On Tue, 16 Apr 2019 at 22:58, Lionel Landwerlin
> wrote:
>> Unfortunately userspace users of this API cannot be publicly disclosed
>> yet.
>>
>> This commit effectively disables t
Am 21.01.19 um 11:06 schrieb Ard Biesheuvel:
> Currently, the DRM code assumes that PCI devices are always cache
> coherent for DMA, and that this can be selectively overridden for
> some buffers using non-cached mappings on the CPU side and PCIe
> NoSnoop transactions on the bus side.
>
> Whether
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 t
Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>> But my concern is that it seems likely that non-cache coherent
>> implementations are relying on this hack as well. There must be a
>> reason that this hack is only disabled for Powe
Am 24.01.19 um 10:28 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
>>> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>>>> But my concern is that it see
Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> [SNIP]
> This is *exactly* my point the whole time.
>
> The current code has
>
> static inline bool drm_arch_can_wc_memory(void)
> {
> #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
> return false;
>
> which means the optimization i
dling racing with all your comments fixed (still not
> committed). The third patch is a prototype based on the first 2 patches
> and on our discussion.
>
> Please take a look.
>
> Andrey
>
>
> On 01/18/2019 01:32 PM, Koenig, Christian wrote:
>> Am 18.01.19 um
Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
>>> [SNIP]
>>> This is *exactly* my point the whole time.
>>>
>>> The current code has
>&g
Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> The DRM driver stack is designed to work with cache coherent devices
> only, but permits an optimization to be enabled in some cases, where
> for some buffers, both the CPU and the GPU use uncached mappings,
> removing the need for DMA snooping and all
Reviewed-by: Christian König
If there are no objections over the weekend I'm going to push that into
upstream direction on monday.
Thanks for the work,
Christian.
Am 25.01.19 um 12:02 schrieb Thomas Zimmermann:
> This patchset cleans up the last remaining callers of ttm_bo_reference
> and ttm_
Am 25.01.19 um 14:05 schrieb Thomas Hellstrom:
> The vmwgfx driver needs to know whether the dma page pool is enabled
> to determine whether to refuse loading if the dma mode logic
> requests coherent memory from the dma page pool.
>
> Cc: "Koenig, Christian"
> Sig
Am 28.01.19 um 15:21 schrieb Thomas Hellstrom:
> On Mon, 2019-01-28 at 14:29 +0100, Thomas Hellström wrote:
>> Hi,
>>
>> On Mon, 2019-01-28 at 12:21 +0000, Koenig, Christian wrote:
>>> Am 25.01.19 um 14:05 schrieb Thomas Hellstrom:
>>>> The vmwgfx driver
Am 30.01.19 um 09:02 schrieb Christoph Hellwig:
> On Tue, Jan 29, 2019 at 08:58:35PM +, Jason Gunthorpe wrote:
>> On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote:
>>
>>> implement the mapping. And I don't think we should have 'special' vma's
>>> for this (though we may need some
1 - 100 of 485 matches
Mail list logo
