Re: [PATCH v3 20/22] drm/vmwgfx: Convert to CRTC VBLANK callbacks

wgfx_stdu.c | 3 +++ > 6 files changed, 15 insertions(+), 9 deletions(-) > Acked-by: Thomas Hellstrom ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

On 5/7/19 1:42 PM, Koenig, Christian wrote: 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 13:08 schrieb zhoucm1: On 2019

Re: [PATCH 1/2] drm/ttm: fix busy memory to fail other user v6

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 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

Re: [PATCH 1/1] drm/ttm: Account for kernel allocations in kernel zone only

kernel allocations that DO spare a number of DMA32 pages according to the kernel allocator heuristics, and then populate TTM buffers with DMA32 pages only. However, since vmwgfx bo's don't request DMA32 pages, we're OK with this, and it's really up to Christian to decide. So: Acked-by: Thomas Hellst

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

On Fri, 2019-02-22 at 07:10 +, Koenig, Christian wrote: > Am 21.02.19 um 22:02 schrieb Thomas Hellstrom: > > Hi, > > > > On Thu, 2019-02-21 at 20:24 +, Kuehling, Felix wrote: > > > On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote: > > > > On Thu,

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

Hi, On Thu, 2019-02-21 at 20:24 +, Kuehling, Felix wrote: > On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote: > > On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote: > > > On 2019-02-21 2:59 a.m., Koenig, Christian wrote: > > > > On x86 with HIGHMEM the

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote: > On 2019-02-21 2:59 a.m., Koenig, Christian wrote: > > On x86 with HIGHMEM there is no dma32 zone. Why do we need one on > > > > x86_64? Can we make x86_64 more like HIGHMEM instead? > > > > > > > > Regards, > > > > Felix > > > > >

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

On Wed, 2019-02-20 at 19:23 +, Kuehling, Felix wrote: > On 2019-02-20 1:41 a.m., Thomas Hellstrom wrote: > > On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote: > > > On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote: > > > > On Mon, 2019-02-18 at 18:0

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

On Wed, 2019-02-20 at 08:35 +, Koenig, Christian wrote: > Am 20.02.19 um 09:14 schrieb Thomas Hellstrom: > > On 2/20/19 9:07 AM, Christian König wrote: > > > Am 20.02.19 um 07:41 schrieb Thomas Hellstrom: > > > > On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

On 2/20/19 9:07 AM, Christian König wrote: Am 20.02.19 um 07:41 schrieb Thomas Hellstrom: On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote: On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote: On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote: Am 18.02.19 um 10:47 schrieb Thomas

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote: > On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote: > > On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote: > > > Am 18.02.19 um 10:47 schrieb Thomas Hellstrom: > > > > On Mon, 2019-02-18 at 09:20

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote: > Am 18.02.19 um 10:47 schrieb Thomas Hellstrom: > > On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote: > > > Another good question is also why the heck the acc_size counts > > > towards > > >

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

unds valid to me in any way, > Christian. > > Am 18.02.19 um 09:02 schrieb Thomas Hellstrom: > > Hmm, > > > > This zone was intended to stop TTM page allocations from > > exhausting > > the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by default, > > wh

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

Hmm, This zone was intended to stop TTM page allocations from exhausting the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by default, which means if we drop this check, other devices may stop functioning unexpectedly? However, in the end I'd expect the kernel page allocation system to

Re: [PATCH 2/5] drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant

On Thu, 2019-02-07 at 09:59 +0100, Thomas Zimmermann wrote: > Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same > value. The only exception is vboxvideo, which is being converted to > the > new offset by this patch. Unifying the constants in a single place > simplifies the

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

Hi, Emil, On 10/04/2018 04:12 PM, Emil Velikov wrote: > On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote: >> Hi, Emil, >> >> On 09/05/2018 03:53 PM, Emil Velikov wrote: >>> On 5 September 2018 at 14:20, Thomas Hellstrom >>> wrote: >>> >&

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

Ping? On 09/30/2018 07:31 PM, Thomas Hellstrom wrote: > Hi, Emil, > > On 09/05/2018 03:53 PM, Emil Velikov wrote: >> On 5 September 2018 at 14:20, Thomas Hellstrom >> wrote: >> >>>> In that case, please give me 24h to do a libdrm release before >>&g

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

Hi, Emil, On 09/05/2018 03:53 PM, Emil Velikov wrote: On 5 September 2018 at 14:20, Thomas Hellstrom wrote: In that case, please give me 24h to do a libdrm release before pushing. I had to push some workarounds for the sandboxing mentioned earlier :-\ Thanks Emil Ouch, I just pushed

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 09/05/2018 03:07 PM, Emil Velikov wrote: On 5 September 2018 at 11:10, Thomas Hellstrom wrote: Hi, Emil, On 09/05/2018 11:33 AM, Emil Velikov wrote: On 4 September 2018 at 23:33, Dave Airlie wrote: On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom wrote: On 09/03/2018 06:33 PM, Daniel

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

Hi, Emil, On 09/05/2018 11:33 AM, Emil Velikov wrote: On 4 September 2018 at 23:33, Dave Airlie wrote: On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom wrote: On 09/03/2018 06:33 PM, Daniel Vetter wrote: On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: On 08/31/2018 05:30 PM

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 09/03/2018 06:33 PM, Daniel Vetter wrote: On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: On 08/31/2018 05:27 PM, Emil Velikov wrote: On 31 August 2018 at 15:38, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: On 08/31/2018 05:27 PM, Emil Velikov wrote: On 31 August 2018 at 15:38, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 08/31/2018 05:27 PM, Emil Velikov wrote: On 31 August 2018 at 15:38, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 08/31/2018 04:49 PM, Michel Dänzer wrote: On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote: On 08/31/2018 04:38 PM, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

On 08/31/2018 04:38 PM, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code

Re: [PATCH 0/2] Provide init/release functions for struct ttm_bo_global

On 08/13/2018 02:28 PM, Thomas Zimmermann wrote: Hi Am 13.08.2018 um 12:33 schrieb Christian König: Yes, please! I had it on my TODO list to clean that up for an eternity. On top of these patches, I have a patch set that provides a single init/release interface for TTM global data. I'll post

Re: [PATCH 3/5] drm/ttm: move ttm_tt defines into ttm_tt.h

Acked-by: Thomas Hellstrom <thellst...@vmware.com> On 03/06/2018 10:13 AM, Christian König wrote: Hi Michel & Thomas, any more comments on this? Or can I commit it? Thanks, Christian. Am 27.02.2018 um 12:49 schrieb Christian König: Let's stop mangling everything in a sin

Re: [PATCH 0/5] prevent OOM triggered by TTM

set according to its request. Thanks, Thomas Thanks Roger(Hongbo.He) -Original Message- From: Thomas Hellstrom [mailto:tho...@shipmail.org] Sent: Wednesday, February 07, 2018 2:43 PM To: He, Roger <hongbo...@amd.com>; amd-gfx@lists.freedesktop.org; dri-de...@lists.freedeskt

Re: [PATCH 0/5] prevent OOM triggered by TTM

Hi, Roger, On 02/06/2018 10:04 AM, Roger He wrote: currently ttm code has no any allocation limit. So it allows pages allocatation unlimited until OOM. Because if swap space is full of swapped pages and then system memory will be filled up with ttm pages. and then any memory allocation request

Re: [PATCH] [RFC]drm/ttm: fix scheduling balance

Hi, On 01/25/2018 06:30 PM, Christian König wrote: Am 25.01.2018 um 17:47 schrieb Thomas Hellstrom: On 01/25/2018 03:57 PM, Thomas Hellstrom wrote: On 01/25/2018 10:59 AM, Chunming Zhou wrote: there is a scheduling balance issue about get node like: a. process A allocates full memory and use

Re: [PATCH] [RFC]drm/ttm: fix scheduling balance

On 01/25/2018 03:57 PM, Thomas Hellstrom wrote: On 01/25/2018 10:59 AM, Chunming Zhou wrote: there is a scheduling balance issue about get node like: a. process A allocates full memory and use it for submission. b. process B tries to allocates memory, will wait for process A BO idle

Re: [PATCH] [RFC]drm/ttm: fix scheduling balance

On 01/25/2018 10:59 AM, Chunming Zhou wrote: there is a scheduling balance issue about get node like: a. process A allocates full memory and use it for submission. b. process B tries to allocates memory, will wait for process A BO idle in eviction. c. process A completes the job, process B

Re: [PATCH 3/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc_page

On 12/21/2017 07:05 AM, He, Roger wrote: -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: Wednesday, December 20, 2017 9:36 PM To: He, Roger ; amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [PATCH

Re: [PATCH 2/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc

With a suitable commit log, LGTM. Reviewed-by: Thomas Hellstrom <thellst...@vmware.com> On 12/20/2017 11:34 AM, Roger He wrote: Change-Id: I5279b5cd3560c4082b00f822219575a5f9c3808a Signed-off-by: Roger He <hongbo...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c

Re: [PATCH 7/7] drm/ttm: enable swapout of per VM BOs during allocation and allows reaping of deleted BOs

What about "Enable recursive locking at swapout time to make it possible to swap out BOs that share the same reservation object." Is "per VM BOs" an AMD specific name?  In that case, I'd avoid using it in the TTM code since most people have no idea what they are and why the need specific

Re: [PATCH 1/7] drm/ttm: call ttm_bo_swapout directly when ttm shrink

Roger, 5 out of 7 patches in this series are completely lacking a commit log message, and thats not OK. Really. https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html#describe-your-changes I'll review these, but IIRC the no_wait in the memory accounting code is different in

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

e state in a the operation_ctx will make that usage-pattern more obvious but will help make the code cleaner and less error prone. /Thomas Regards, Christian. Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom: Roger and Chrisitian, Correct me if I'm wrong, but It seems to me like a lot of t

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

15.12.2017 um 08:01 schrieb Thomas Hellstrom: Roger and Chrisitian, Correct me if I'm wrong, but It seems to me like a lot of the recent changes to ttm_bo.c are to allow recursive reservation object locking in the case of shared reservation objects, but only in certain functions and with

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

ctx will make that usage-pattern more obvious but will help make the code cleaner and less error prone. /Thomas Regards, Christian. Am 15.12.2017 um 08:01 schrieb Thomas Hellstrom: Roger and Chrisitian, Correct me if I'm wrong, but It seems to me like a lot of the recent changes to ttm_b

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

Roger and Chrisitian, Correct me if I'm wrong, but It seems to me like a lot of the recent changes to ttm_bo.c are to allow recursive reservation object locking in the case of shared reservation objects, but only in certain functions and with special arguments so it doesn't look like

Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO

Hi. On 12/14/2017 09:10 AM, Roger He wrote: Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62 Signed-off-by: Roger He --- drivers/gpu/drm/ttm/ttm_bo.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

Re: [PATCH 2/2] drm/ttm: completely rework ttm_bo_delayed_delete

On 12/14/2017 02:17 PM, Christian König wrote: Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom: On 12/13/2017 09:55 PM, Thomas Hellstrom wrote: Hi, Christian, While this has probably already been committed, and looks like a nice cleanup there are two things below I think needs fixing

Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx

Hi, Christian, On 12/14/2017 09:40 AM, Christian König wrote: Hi Thomas, sorry for that. Noted on the rest of that series as well that we need to improve the commit messages. But this one somehow slipped through because I discussed this change previously internally with Roger. That made

Re: [PATCH 2/2] drm/ttm: completely rework ttm_bo_delayed_delete

On 12/13/2017 09:55 PM, Thomas Hellstrom wrote: Hi, Christian, While this has probably already been committed, and looks like a nice cleanup there are two things below I think needs fixing. On 11/15/2017 01:31 PM, Christian König wrote: There is no guarantee that the next entry

Re: [PATCH 2/2] drm/ttm: completely rework ttm_bo_delayed_delete

Hi, Christian, While this has probably already been committed, and looks like a nice cleanup there are two things below I think needs fixing. On 11/15/2017 01:31 PM, Christian König wrote: There is no guarantee that the next entry on the ddelete list stays on the list when we drop the locks.

Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx

Hi, I think this series is quite poorly documented. We should have a log message explaining the purpose of the commit. Also since it's not obvious what the series is attempting to achieve, please add a 0/X series header message.. /Thomas On 12/12/2017 10:33 AM, Roger He wrote: