Am 20.06.19 um 18:30 schrieb Emil Velikov:
> On 2019/06/14, Koenig, Christian wrote:
>> Am 14.06.19 um 17:53 schrieb Emil Velikov:
>>> On 2019/06/14, Koenig, Christian wrote:
Am 14.06.19 um 14:09 schrieb Emil Velikov:
> On 2019/05/27, Emil Velikov wrote:
> [SNIP]
> Hi Christian,
>>
On 2019-06-21 9:12 a.m., Koenig, Christian wrote:
>
> First of all I tried to disable DRM authentication completely with a
> kernel config option. Surprisingly that actually works out of the box at
> least on the AMDGPU stack.
>
> This effectively allows us to get rid of DRI2 and the related se
Am 21.06.19 um 09:41 schrieb Michel Dänzer:
> On 2019-06-21 9:12 a.m., Koenig, Christian wrote:
>> First of all I tried to disable DRM authentication completely with a
>> kernel config option. Surprisingly that actually works out of the box at
>> least on the AMDGPU stack.
>>
>> This effectively al
On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote:
> Am 20.06.19 um 18:30 schrieb Emil Velikov:
> > On 2019/06/14, Koenig, Christian wrote:
> >> Am 14.06.19 um 17:53 schrieb Emil Velikov:
> >>> On 2019/06/14, Koenig, Christian wrote:
> Am 14.06.19 um 14:09 schrieb Emil Velikov:
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
>
Am 21.06.19 um 11:09 schrieb Daniel Vetter:
> On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote:
>> Am 20.06.19 um 18:30 schrieb Emil Velikov:
>>> On 2019/06/14, Koenig, Christian wrote:
Am 14.06.19 um 17:53 schrieb Emil Velikov:
> On 2019/06/14, Koenig, Christian wrote:
>>
On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian
wrote:
>
> Am 21.06.19 um 11:09 schrieb Daniel Vetter:
> > On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote:
> >> Am 20.06.19 um 18:30 schrieb Emil Velikov:
> >>> On 2019/06/14, Koenig, Christian wrote:
> Am 14.06.19 um 17:53
add df sw init to df 1.7 function to prevent regression issues on pre-vega20
products.
Change-Id: I4941003ea4a99ba0ea736c7ecc8800148423c379
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/df_
Am 21.06.19 um 11:20 schrieb Daniel Vetter:
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called
Am 21.06.19 um 11:35 schrieb Daniel Vetter:
On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian
wrote:
Am 21.06.19 um 11:09 schrieb Daniel Vetter:
On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote:
Am 20.06.19 um 18:30 schrieb Emil Velikov:
On 2019/06/14, Koenig, Christian wro
On 2019/06/21, Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian
> wrote:
> >
> > Am 21.06.19 um 11:09 schrieb Daniel Vetter:
> > > On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote:
> > >> Am 20.06.19 um 18:30 schrieb Emil Velikov:
> > >>> On 2019/06/14, Ko
On Fri, Jun 21, 2019 at 11:55 AM Christian König
wrote:
>
> Am 21.06.19 um 11:20 schrieb Daniel Vetter:
> > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> >> On the exporter side we add optional explicit pinning callbacks. If those
> >> callbacks are implemented the framework n
Am 21.06.19 um 12:20 schrieb Emil Velikov:
> On 2019/06/21, Daniel Vetter wrote:
>> On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian
>> wrote:
>>> Am 21.06.19 um 11:09 schrieb Daniel Vetter:
On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote:
> Am 20.06.19 um 18:30 schrie
On Fri, Jun 14, 2019 at 10:35:25PM +0200, Daniel Vetter wrote:
> 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
On 2019/06/21, Koenig, Christian wrote:
> No this should apply to all drivers, not just amdgpu.
>
> > While I suggested:
> > - keeping amdgpu consistent with the rest
> > - exposing the KConfig option for the whole of the kernel, and
> > - merging it alongside this work
> >
> > So I effectiv
On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian
wrote:
> Am 21.06.19 um 12:20 schrieb Emil Velikov:
> > In particular, that user-space will "remove" render nodes.
>
> Yes, that is my main concern here. You basically make render nodes
> superfluously. That gives userspace all legitimization to a
Am 21.06.19 um 12:53 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> [SNIP]
>> Well partially. That RADV broke is unfortunate, but we have done so many
>> customized userspace stuff both based on Mesa/DDX as well as closed
>> source components that it is just highly likely that w
Am 21.06.19 um 13:03 schrieb Daniel Vetter:
On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian
wrote:
Am 21.06.19 um 12:20 schrieb Emil Velikov:
In particular, that user-space will "remove" render nodes.
Yes, that is my main concern here. You basically make render nodes
superfluously. That gi
On Fri, Jun 21, 2019 at 1:37 PM Christian König
wrote:
>
> Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> > On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian
> > wrote:
> >> Am 21.06.19 um 12:20 schrieb Emil Velikov:
> >>> In particular, that user-space will "remove" render nodes.
> >> Yes, that
Drop drm_gem_object from amdgpu_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/
Drop drm_gem_object from radeon_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/radeon/radeon.h | 3 +--
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 4 ++--
drivers/gpu/drm/r
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +++---
drivers/gpu/drm/radeon/radeon_mn.c| 2 +-
drivers/
Signed-off-by: Gerd Hoffmann
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/virtio/virtg
On Fri, Jun 21, 2019 at 1:50 PM Daniel Vetter wrote:
>
> On Fri, Jun 21, 2019 at 1:37 PM Christian König
> wrote:
> >
> > Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> > > On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian
> > > wrote:
> > >> Am 21.06.19 um 12:20 schrieb Emil Velikov:
> > >>> In
On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 12:53 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> [SNIP]
> >> Well partially. That RADV broke is unfortunate, but we have done so many
> >> customized userspace stuff both based on Mesa/DDX as well as closed
> >> so
On 2019/06/21, Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 1:50 PM Daniel Vetter wrote:
> >
> > On Fri, Jun 21, 2019 at 1:37 PM Christian König
> > wrote:
> > >
> > > Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> > > > On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian
> > > > wrote:
> > > >>
Am 21.06.19 um 12:32 schrieb Daniel Vetter:
On Fri, Jun 21, 2019 at 11:55 AM Christian König
wrote:
Am 21.06.19 um 11:20 schrieb Daniel Vetter:
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
[SNIP]
Imo the below semantics would be much cleaner:
- invalidate may add new fence
Am 21.06.19 um 13:58 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 12:53 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
[SNIP]
Well partially. That RADV broke is unfortunate, but we have done so many
customized userspace stuff bo
On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 13:58 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> Am 21.06.19 um 12:53 schrieb Emil Velikov:
> >>> On 2019/06/21, Koenig, Christian wrote:
> [SNIP]
> Well partially. That RADV broke is unfortunate, but we
Am 21.06.19 um 14:47 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 13:58 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
Am 21.06.19 um 12:53 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> [SNIP]
>> Well part
Is this supported on smu7 parts as well? Might be better to just enable it on
the specific asics that support it. I think it might just be vega20.
Alex
From: amd-gfx on behalf of Evan Quan
Sent: Thursday, June 20, 2019 10:07 PM
To: amd-gfx@lists.freedesktop.o
It works on my Fiji card. Maybe Vega10 functionality is just broken in this
regard?
Kent
From: amd-gfx On Behalf Of Deucher,
Alexander
Sent: Friday, June 21, 2019 9:42 AM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/powerplay: no memory activity support on Vega10
If both init and sw_init are empty, we don't need both. Just rename the init
callback to sw_init.
Alex
From: amd-gfx on behalf of Kim,
Jonathan
Sent: Friday, June 21, 2019 5:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kim, Jonathan
Subject: [PATCH] drm/amdgpu:
Maybe it's dependent on the SMU firwmare version?
Alex
From: Russell, Kent
Sent: Friday, June 21, 2019 9:54 AM
To: Deucher, Alexander; Quan, Evan; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amd/powerplay: no memory activity support on Vega10
It works
Am 20.06.19 um 19:44 schrieb StDenis, Tom:
Signed-off-by: Tom St Denis
Acked-by: Christian König
---
src/lib/read_vram.c | 47 +
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/src/lib/read_vram.c b/src/lib/read_vram.c
index 131c
On 2019-06-21 1:50 p.m., Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 1:37 PM Christian König
> wrote:
>> Am 21.06.19 um 13:03 schrieb Daniel Vetter:
>>> So if you want to depracate render functionality on primary nodes, you
>>> _have_ to do that hiding in userspace. Or you'll break a lot of
>>>
On 2019-06-21 1:58 p.m., Emil Velikov wrote:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 12:53 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
>
> In particular, that user-space will "remove" render nodes.
Yes, that is my main concern here. You basically
change df_init to df_sw_init df 1.7 to prevent regression issues on pre-vega20
products when callback is called in sw_common_sw_init.
Change-Id: I4941003ea4a99ba0ea736c7ecc8800148423c379
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 4 ++--
1 file changed, 2 insertions(+
On Fri, Jun 21, 2019 at 01:00:17PM +, Koenig, Christian wrote:
> Am 21.06.19 um 14:47 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> Am 21.06.19 um 13:58 schrieb Emil Velikov:
> >>> On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 12:53 schrieb Emil Velikov:
On Fri, Jun 21, 2019 at 05:15:22PM +0200, Michel Dänzer wrote:
> On 2019-06-21 1:50 p.m., Daniel Vetter wrote:
> > On Fri, Jun 21, 2019 at 1:37 PM Christian König
> > wrote:
> >> Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> >>> So if you want to depracate render functionality on primary nodes, yo
On 2019-06-21 5:44 p.m., Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 05:15:22PM +0200, Michel Dänzer wrote:
>> On 2019-06-21 1:50 p.m., Daniel Vetter wrote:
>>> On Fri, Jun 21, 2019 at 1:37 PM Christian König
>>> wrote:
Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> So if you want to de
On 2019-06-21 11:31 a.m., Kim, Jonathan wrote:
> change df_init to df_sw_init df 1.7 to prevent regression issues on pre-vega20
> products when callback is called in sw_common_sw_init.
>
> Change-Id: I4941003ea4a99ba0ea736c7ecc8800148423c379
> Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehli
On Fri, Jun 21, 2019 at 02:06:54PM +0200, Christian König wrote:
> Am 21.06.19 um 12:32 schrieb Daniel Vetter:
> > On Fri, Jun 21, 2019 at 11:55 AM Christian König
> > wrote:
> > > Am 21.06.19 um 11:20 schrieb Daniel Vetter:
> > > > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
Make it easy to distinguish unmapped, idle and busy queues in the
HQD dump.
Also remove CU mask from the HQD dump because these registers are
not per-queue, but per pipe.
Signed-off-by: Felix Kuehling
---
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 35 ++--
.../gpu/drm/amd/amdgp
Thanks, sorry about this. I'll be more thorough next time. Patch verified
with vega20 and vega10 systems.
Jon
-Original Message-
From: Kuehling, Felix
Sent: Friday, June 21, 2019 12:10 PM
To: amd-gfx@lists.freedesktop.org; Kim, Jonathan
Subject: Re: [PATCH] drm/amdgpu: add sw_init t
It was replaced with the sw_init callback so is no longer
needed.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 7118ca21aa4e..896a4bc60040 100
On 2019-06-21 5:33 p.m., Alex Deucher wrote:
> It was replaced with the sw_init callback so is no longer
> needed.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd
On Mon, Jun 17, 2019 at 5:42 PM Ernst Sjöstrand wrote:
>
> Done automatically with unexpand.
>
> Signed-off-by: Ernst Sjöstrand
Thanks for the patches. I've gone ahead and squashed them into the
original patches for upstream.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 158
Apply the same setting to SH_MEM_CONFIG and VM_CONTEXT1_CNTL. This
makes the noretry param no longer KFD-specific. On GFX10 I'm not
changing SH_MEM_CONFIG in this commit because GFX10 has different
retry behaviour in the SQ and I don't have a way to test it at the
moment.
Suggested-by: Christian K
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c: In function ‘amdgpu_pmu_init’:
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:249:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
int ret = 0;
^
It is never used since introduction in
On Sat, 22 Jun 2019, Mao Wenan wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c: In function ‘amdgpu_pmu_init’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:249:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-variable]
> int ret
52 matches
Mail list logo
