Re: [PATCH] drm: add drm device name

Let's drop this patch. Mesa will use family_id. Marek On Wed, Sep 18, 2019 at 4:10 PM Marek Olšák wrote: > On Wed, Sep 18, 2019 at 10:03 AM Michel Dänzer wrote: > >> On 2019-09-18 1:41 a.m., Marek Olšák wrote: >> > drmVersion::name = amdgpu, radeon, intel, etc. >

Re: [PATCH] drm: add drm device name

On Wed, Sep 18, 2019 at 10:03 AM Michel Dänzer wrote: > On 2019-09-18 1:41 a.m., Marek Olšák wrote: > > drmVersion::name = amdgpu, radeon, intel, etc. > > drmVersion::desc = vega10, vega12, vega20, ... > > > > The common Mesa code will use name and desc to select th

Re: [PATCH] drm: add drm device name

gt;> Am 17.09.19 um 10:17 schrieb Daniel Vetter: > >>>>> On Tue, Sep 17, 2019 at 10:12 AM Christian König > >>>>> wrote: > >>>>>> Am 17.09.19 um 07:47 schrieb Jani Nikula: > >>>>>>> On Mon, 16 Sep 2019, Marek Olšák w

Re: [PATCH] drm: add drm device name

; On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote: > > > > > > + dri-devel > > > > > > On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny > wrote: > > >> > > >> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc

Re: [PATCH] drm: add drm device name

+ dri-devel On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote: > Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc > passing it to user space > instead of unused DRM driver name descriptor. > > Change-Id: I809f6d3e057111417efbe8fa7cab8f0113ba4b21 > Signed-off-by: Sonny Jiang

Re: [PATCH v2] drm/amdgpu: Default disable GDS for compute+gfx

König wrote: > > Am 29.08.19 um 07:55 schrieb zhoucm1: > > > On 2019/8/29 上午1:08, Marek Olšák wrote: > > It can't break an older driver, because there is no older driver that > requires the static allocation. > > Note that closed source drivers don't count, becaus

Re: [PATCH v2] drm/amdgpu: Default disable GDS for compute+gfx

It can't break an older driver, because there is no older driver that requires the static allocation. Note that closed source drivers don't count, because they don't need backward compatibility. Marek On Wed, Aug 28, 2019 at 2:44 AM zhoucm1 wrote: > > On 2019/7/23 上午3:08, Christian König wrote

[PATCH] Revert "drm/amdgpu: fix transform feedback GDS hang on gfx10 (v2)"

From: Marek Olšák This reverts commit b41335c6c0303d100abe89c843e52645d1974cd9. SET_CONFIG_REG writes to memory if register shadowing is enabled, causing a VM fault. NGG streamout is unstable anyway, so all UMDs should use legacy streamout. I think Mesa is the only driver using NGG streamout

Re: [PATCH] drm/amdgpu: reserve GDS resources on the gfx ring for gfx10

On Wed., Jul. 17, 2019, 10:43 Christian König, < ckoenig.leichtzumer...@gmail.com> wrote: > Am 17.07.19 um 16:27 schrieb Marek Olšák: > > > > On Wed., Jul. 17, 2019, 03:15 Christian König, < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 17.07.19 um 02:0

Re: [PATCH] drm/amdgpu: reserve GDS resources on the gfx ring for gfx10

On Wed., Jul. 17, 2019, 03:15 Christian König, < ckoenig.leichtzumer...@gmail.com> wrote: > Am 17.07.19 um 02:06 schrieb Marek Olšák: > > From: Marek Olšák > > > > Hopefully we'll only use 1 gfx ring, because otherwise we'd have to have > > separate GDS

[PATCH] drm/amdgpu: reserve GDS resources on the gfx ring for gfx10

From: Marek Olšák Hopefully we'll only use 1 gfx ring, because otherwise we'd have to have separate GDS buffers for each gfx ring. This is a workaround to ensure stability of transform feedback. Shaders hang waiting for a GDS instruction (ds_sub, not ds_ordered_count). The disadvanta

Re: [PATCH] drm/amdgpu/gfx10: set SH_MEM_CONFIG.INITIAL_INST_PREFETCH

The patch doesn't apply. Can you rebase it? Thanks, Marek On Fri, Jul 12, 2019 at 9:47 AM Haehnle, Nicolai wrote: > Prefetch mode 0 is not supported and can lead to hangs with certain very > specific code patterns. Set a sound prefetch mode for all VMIDs rather > than forcing all shaders to set

Re: [PATCH] drm/amdgpu/gfx10: set SH_MEM_CONFIG.INITIAL_INST_PREFETCH

Reviewed-by: Marek Olšák Marek On Fri, Jul 12, 2019 at 9:47 AM Haehnle, Nicolai wrote: > Prefetch mode 0 is not supported and can lead to hangs with certain very > specific code patterns. Set a sound prefetch mode for all VMIDs rather > than forcing all shaders to set the prefetch mo

Re: [PATCH] drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback

ping On Tue, Jul 2, 2019 at 2:29 PM Marek Olšák wrote: > From: Marek Olšák > > This RELEASE_MEM use has the Release semantic, which means we should write > back but not invalidate. Invalidations only make sense with the Acquire > semantic (ACQUIRE_MEM), or when RELEASE_MEM is

Re: The problem "ring gfx timeout" are experienced yet another AMD GPU Vega 8 user

It looks like memory corruption. You can try to disable IOMMU in the BIOS. Marek On Tue, Jul 2, 2019 at 12:07 AM Mikhail Gavrilov < mikhail.v.gavri...@gmail.com> wrote: > On Wed, 27 Feb 2019 at 00:57, Marek Olšák wrote: > > > > Sadly, the logs don't contain a

[ANNOUNCE] libdrm 2.4.99

with memset rather than "= {0}" Leo Liu (1): tests/amdgpu/vcn: add VCN2.0 decode support Lucas Stach (1): etnaviv: drop etna_bo_from_handle symbol Marek Olšák (1): Bump version to 2.4.99 Marek Vasut (1): etnaviv: Fix double-free in etna_bo_cache_free() M

[PATCH] drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback

From: Marek Olšák This RELEASE_MEM use has the Release semantic, which means we should write back but not invalidate. Invalidations only make sense with the Acquire semantic (ACQUIRE_MEM), or when RELEASE_MEM is used to do the combined Acquire-Release semantic, which is a barrier, not a fence

Re: [PATCH 2/2] drm/amdgpu: handle AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID on gfx10

Thanks. I'll push both patches with emit_ib_size updated for this patch. Marek On Thu, Jun 27, 2019 at 3:50 AM zhoucm1 wrote: > any reason for not care .emit_ib_size in this one? > > -David > > > On 2019年06月27日 06:35, Marek Olšák wrote: > > From: Marek Olšák >

[PATCH 2/2] drm/amdgpu: handle AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID on gfx10

From: Marek Olšák Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index 6baaa65a1daa..5b807a19bbbf 100644 --- a/drivers

[PATCH 1/2] drm/amdgpu: fix transform feedback GDS hang on gfx10 (v2)

From: Marek Olšák v2: update emit_ib_size (though it's still wrong because it was wrong before) Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h | 3 ++- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +++--- 2 files changed, 13 insertions(+), 4 deletions(-)

[PATCH 1/2] drm/amdgpu: fix transform feedback GDS hang on gfx10

From: Marek Olšák Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h | 3 ++- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 12 ++-- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h b/drivers/gpu/drm/amd/amdgpu

[PATCH 2/2] drm/amdgpu: handle AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID on gfx10

From: Marek Olšák Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index 75a34779a57c..77507b2a4652 100644 --- a/drivers

[PATCH] drm/amdgpu: bump the DRM version for GDS ENOMEM fixes

From: Marek Olšák Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 1f38d6fc1fe3..f9462ad2a314 100644 --- a

[PATCH] drm/amdgpu: bump the DRM version for GDS ENOMEM fixes

From: Marek Olšák Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 1f38d6fc1fe3..7daa2a8f1c08 100644 --- a/drivers/gpu/drm/amd

Re: [PATCH 11/11] drm/amdgpu: stop removing BOs from the LRU during CS

This series fixes the OOM errors. However, if I torture the kernel driver more, I can get it to deadlock and end up with unkillable processes. I can also get an OOM error. I just ran the test 5 times: AMD_DEBUG=testgdsmm glxgears & AMD_DEBUG=testgdsmm glxgears & AMD_DEBUG=testgdsmm glxgears & AMD_

Re: [PATCH] drm/amdgpu: remove static GDS, GWS and OA allocation

Reviewed-by: Marek Olšák Marek On Fri, May 10, 2019 at 1:58 PM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > As far as we know this was never used by userspace and so should be > removed. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd

Re: Userptr broken with the latest amdgpu driver

config file. Please update your > kernel config file to enable option CONFIG_ZONE_DEVICE. > > You should have this message in dmesg log: > > "HMM_MIRROR kernel config option is not enabled, " > "add CONFIG_ZONE_DEVICE=y in config file to fix > > Phil

Userptr broken with the latest amdgpu driver

Hi, amdgpu_mn_register fails with -ENODEV in amdgpu_gem_userptr_ioctl. The regression happened within the last 1-2 months. Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH xf86-video-amdgpu] Allow changing DCC parameters between flips

As you probably noticed, I don't use gitlab for my own patches yet. Marek On Fri, Mar 1, 2019 at 3:52 AM Michel Dänzer wrote: > > Thanks Marek for the patch, but xf86-video-amdgpu patches are being > reviewed as GitLab merge requests since the last release[0]. > > I'll create a merge request wi

[PATCH xf86-video-amdgpu] Allow changing DCC parameters between flips

From: Marek Olšák --- src/amdgpu_present.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/src/amdgpu_present.c b/src/amdgpu_present.c index ce88bd8f..f4fc6ebd 100644 --- a/src/amdgpu_present.c +++ b/src/amdgpu_present.c @@ -271,26 +271,34

Re: [PATCH] drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates

Reviewed-by: Marek Olšák Marek On Thu, Feb 28, 2019 at 9:59 AM Nicholas Kazlauskas < nicholas.kazlaus...@amd.com> wrote: > To help xf86-video-amdgpu and mesa know DC supports updating the > tiling attributes for a framebuffer per-flip. > > Cc: Michel Dänzer > Cc: Marek O

Re: The problem "ring gfx timeout" are experienced yet another AMD GPU Vega 8 user

Sadly, the logs don't contain any clue as to why it hangs. It would be helpful to check if the hang can be reproduced on Vega 56 or 64 as well. Marek On Tue, Feb 26, 2019 at 7:51 AM Mikhail Gavrilov < mikhail.v.gavri...@gmail.com> wrote: > On Tue, 26 Feb 2019 at 00:40, Mare

Re: The problem "ring gfx timeout" are experienced yet another AMD GPU Vega 8 user

Some shaders are stuck at "s_load_dwordx4 s[32:35], s[36:37], 0x0", but that might mean all sorts of things. Do you also have the dmesg log? Marek On Sat, Feb 9, 2019 at 12:20 PM Mikhail Gavrilov < mikhail.v.gavri...@gmail.com> wrote: > On Sat, 9 Feb 2019 at 22:01,

Re: The problem "ring gfx timeout" are experienced yet another AMD GPU Vega 8 user

I don't see any attachments here. Marek On Sat, Feb 9, 2019, 11:37 AM Grodzovsky, Andrey +Marek > > Can't find the last fence seqno from mmCP_EOP_LAST_FENCE_LO in gfx ring > dump (probably that seqno wasn't really the last if the register was > dumped several times before) but since waves were d

Re: [PATCH] drm/amdgpu: add a workaround for GDS ordered append hangs with compute queues

FYI, when I push this, I'll bump the DRM version. Marek On Mon, Feb 4, 2019 at 10:55 AM Marek Olšák wrote: > On Mon, Feb 4, 2019 at 7:42 AM Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> At least from coding style, backward compatibility etc.. th

Re: [PATCH] drm/amdgpu: add a workaround for GDS ordered append hangs with compute queues

On Mon, Feb 4, 2019 at 7:42 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > At least from coding style, backward compatibility etc.. this looks sane > to me, so feel free to add an Acked-by. > > But I absolutely can't judge if that is correct from the hardware point of > view or no

Re: [PATCH v2] drm/amdgpu: Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES

Can you also bump the KMS version? Thanks, Marek On Fri, Feb 1, 2019 at 3:09 PM Marek Olšák wrote: > Reviewed-by: Marek Olšák > Tested-by: Marek Olšák > > On Fri, Feb 1, 2019 at 3:00 PM Andrey Grodzovsky < > andrey.grodzov...@amd.com> wrote: > >> New chunk fo

Re: [PATCH v2] drm/amdgpu: Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES

Reviewed-by: Marek Olšák Tested-by: Marek Olšák On Fri, Feb 1, 2019 at 3:00 PM Andrey Grodzovsky wrote: > New chunk for dependency on start of job's execution instead on > the end. This is used for GPU deadlock prevention when > userspace uses mid-IB fences to wait for mid-IB

Re: [PATCH] drm/amdgpu: add AMDGPU_IB_FLAG_GET_START_SYNCOBJ to expose scheduled fence

On Tue, Jan 29, 2019 at 3:01 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 28.01.19 um 22:52 schrieb Marek Olšák: > > From: Marek Olšák > > > > Normal syncobjs signal when an IB finishes. Start syncobjs signal when > > an IB starts. > &

Re: [PATCH] drm/amdgpu: add AMDGPU_IB_FLAG_GET_START_SYNCOBJ to expose scheduled fence

On Tue, Jan 29, 2019, 3:01 AM Christian König < ckoenig.leichtzumer...@gmail.com wrote: > Am 28.01.19 um 22:52 schrieb Marek Olšák: > > From: Marek Olšák > > > > Normal syncobjs signal when an IB finishes. Start syncobjs signal when > > an IB starts. > >

[PATCH] drm/amdgpu: add AMDGPU_IB_FLAG_GET_START_SYNCOBJ to expose scheduled fence

From: Marek Olšák Normal syncobjs signal when an IB finishes. Start syncobjs signal when an IB starts. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 18 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3

Re: [PATCH] drm/amdgpu: clean up memory/GDS/GWS/OA alignment code

Ping On Tue, Jan 22, 2019 at 4:45 PM Marek Olšák wrote: > From: Marek Olšák > > - move all adjustments into one place > - specify GDS/GWS/OA alignment in basic units of the heaps > - it looks like GDS alignment was 1 instead of 4 > > Signed-off-by: Marek Olšák > --

Re: [PATCH] drm/amdgpu: add a workaround for GDS ordered append hangs with compute queues

Ping On Tue, Jan 22, 2019 at 3:05 PM Marek Olšák wrote: > From: Marek Olšák > > I'm not increasing the DRM version because GDS isn't totally without bugs > yet. > > v2: update emit_ib_size > > Signed-off-by: Marek Olšák > --- > drivers/gpu/drm/amd/am

[PATCH] drm/amdgpu: clean up memory/GDS/GWS/OA alignment code

From: Marek Olšák - move all adjustments into one place - specify GDS/GWS/OA alignment in basic units of the heaps - it looks like GDS alignment was 1 instead of 4 Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 7 --- drivers/gpu/drm/amd/amdgpu

[PATCH] drm/amdgpu: add a workaround for GDS ordered append hangs with compute queues

From: Marek Olšák I'm not increasing the DRM version because GDS isn't totally without bugs yet. v2: update emit_ib_size Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h | 2 ++ drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 19 +++- drivers/gpu/drm/

[ANNOUNCE] libdrm 2.4.97

Marchi (2): gitignore: sort file gitignore: add _build Marek Olšák (3): amdgpu: update amdgpu_drm.h amdgpu: add a faster BO list API Bump the version to 2.4.97 Mauro Rossi (1): android: Fix 32-bit app crashing in 64-bit Android git tag: libdrm-2.4.

[PATCH] drm/amdgpu: add a workaround for GDS ordered append hangs with compute queues

From: Marek Olšák I'm not increasing the DRM version because GDS isn't totally without bugs yet. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h | 2 ++ drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 17 drivers/gpu/drm/amd/amdgpu/gfx_v8_

Re: [PATCH libdrm] amdgpu: add a faster BO list API

FYI, I've pushed the patch because it helps simplify our the amdgpu winsys code and I already have code that depends on it that I don't wanna rewrite. Marek On Wed, Jan 16, 2019 at 12:39 PM Marek Olšák wrote: > On Wed, Jan 16, 2019 at 9:43 AM Christian König < >

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Wed, Jan 16, 2019 at 9:43 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 16.01.19 um 15:39 schrieb Marek Olšák: > > > > On Wed, Jan 16, 2019, 9:34 AM Koenig, Christian wrote: > >> Am 16.01.19 um 15:31 schrieb Marek Olšák: >> >> >

Re: [PATCH libdrm] amdgpu: update amdgpu_drm.h

On Wed, Jan 16, 2019 at 11:25 AM Koenig, Christian wrote: > Am 16.01.19 um 17:15 schrieb Marek Olšák: > > On Wed, Jan 16, 2019 at 2:37 AM Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 15.01.19 um 20:25 schrieb Marek Olšák: >> > From:

Re: [PATCH libdrm] amdgpu: update amdgpu_drm.h

On Wed, Jan 16, 2019 at 2:37 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 15.01.19 um 20:25 schrieb Marek Olšák: > > From: Marek Olšák > > Maybe note in the commit message from which upstream kernel. > No upstream kernel. It's from

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Wed, Jan 16, 2019 at 10:15 AM Bas Nieuwenhuizen wrote: > On Wed, Jan 16, 2019 at 3:38 PM Marek Olšák wrote: > > > > > > > > On Wed, Jan 16, 2019, 7:46 AM Bas Nieuwenhuizen wrote: > >> > >> So random questions: > >> > >> 1) In

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Wed, Jan 16, 2019, 9:34 AM Koenig, Christian Am 16.01.19 um 15:31 schrieb Marek Olšák: > > > > On Wed, Jan 16, 2019, 7:55 AM Christian König < > ckoenig.leichtzumer...@gmail.com wrote: > >> Well if you ask me we should have the following interface for >> negot

Re: [PATCH libdrm] amdgpu: add a faster BO list API

mments below. > The reason amdgpu was slower than radeon was because of this inefficient bo list interface. > On Mon, Jan 7, 2019 at 8:31 PM Marek Olšák wrote: > > > > From: Marek Olšák > > > > --- > > amdgpu/amdgpu-symbol-check | 3 ++

Re: [PATCH libdrm] amdgpu: add a faster BO list API

need something in the interim? > > > > 3) Did we measure any performance benefit? > > > > In general I'd like to to ack the raw bo list creation function as > > this interface seems easier to use. The two arrays thing has always > > been kind of a pain wh

[PATCH libdrm] amdgpu: update amdgpu_drm.h

From: Marek Olšák --- include/drm/amdgpu_drm.h | 8 1 file changed, 8 insertions(+) diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h index 1ceec56d..be84e43c 100644 --- a/include/drm/amdgpu_drm.h +++ b/include/drm/amdgpu_drm.h @@ -319,20 +319,26 @@ struct

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Thu, Jan 10, 2019, 6:51 AM Christian König < ckoenig.leichtzumer...@gmail.com wrote: > Am 10.01.19 um 12:41 schrieb Marek Olšák: > > > > On Thu, Jan 10, 2019, 4:15 AM Koenig, Christian wrote: > >> Am 10.01.19 um 00:39 schrieb Marek Olšák: >> >> On Wed,

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Thu, Jan 10, 2019, 4:15 AM Koenig, Christian Am 10.01.19 um 00:39 schrieb Marek Olšák: > > On Wed, Jan 9, 2019 at 1:41 PM Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 09.01.19 um 17:14 schrieb Marek Olšák: >> >> On Wed, Ja

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Wed, Jan 9, 2019 at 1:41 PM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 09.01.19 um 17:14 schrieb Marek Olšák: > > On Wed, Jan 9, 2019 at 8:09 AM Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 09.01.19 um 13:36 schrie

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Wed, Jan 9, 2019 at 8:09 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 09.01.19 um 13:36 schrieb Marek Olšák: > > > > On Wed, Jan 9, 2019, 5:28 AM Christian König < > ckoenig.leichtzumer...@gmail.com wrote: > >> Looks good, but I'

Re: [PATCH libdrm] amdgpu: add a faster BO list API

On Wed, Jan 9, 2019, 5:28 AM Christian König < ckoenig.leichtzumer...@gmail.com wrote: > Looks good, but I'm wondering what's the actual improvement? > No malloc calls and 1 less for loop copying the bo list. Marek > Christian. > > Am 07.01.19 um 20:31 schrieb

[PATCH libdrm] amdgpu: add a faster BO list API

From: Marek Olšák --- amdgpu/amdgpu-symbol-check | 3 ++ amdgpu/amdgpu.h| 56 +- amdgpu/amdgpu_bo.c | 36 amdgpu/amdgpu_cs.c | 25 + 4 files changed, 119 insertions(+), 1 deletion(-) diff

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

On Fri, Nov 2, 2018 at 3:39 AM Koenig, Christian wrote: > Am 31.10.18 um 23:12 schrieb Marek Olšák: > > On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian < > christian.koe...@amd.com> wrote: > >> Am 30.10.18 um 16:59 schrieb Michel Dänzer: >> > On 201

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian wrote: > Am 30.10.18 um 16:59 schrieb Michel Dänzer: > > On 2018-10-30 4:52 p.m., Marek Olšák wrote: > >> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák wrote: > >>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer > wro

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

On Tue, Oct 30, 2018, 11:52 AM Marek Olšák wrote: > > > On Tue, Oct 30, 2018, 11:49 AM Marek Olšák wrote: > >> >> >> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer wrote: >> >>> On 2018-10-29 10:15 p.m., Marek Olšák wrote: >>> > You and

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

On Tue, Oct 30, 2018, 11:49 AM Marek Olšák wrote: > > > On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer wrote: > >> On 2018-10-29 10:15 p.m., Marek Olšák wrote: >> > You and I discussed this extensively internally a while ago. It's >> expected >> >

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer wrote: > On 2018-10-29 10:15 p.m., Marek Olšák wrote: > > You and I discussed this extensively internally a while ago. It's > expected > > and correct behavior. Mesa doesn't unmap some buffers and never will. > > I

Re: [PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

OK. I'll drop this patch. Marek On Wed, Oct 24, 2018 at 4:14 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 24.10.18 um 10:04 schrieb Michel Dänzer: > > On 2018-10-23 9:07 p.m., Marek Olšák wrote: > >> From: Marek Olšák > >> &

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

Mapping the same BO so often is illegal > and should be handled as error. > > Otherwise we will never be able to cleanly recover from a GPU lockup > with lost state by reloading the client library. > > Christian. > > Am 23.10.18 um 21:07 schrieb Marek Olšák: > > From:

Re: [PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

On Tue, Oct 23, 2018 at 10:38 PM Zhang, Jerry(Junwei) wrote: > On 10/24/18 3:07 AM, Marek Olšák wrote: > > From: Marek Olšák > > We need commit log and sign-off here. > > BTW, have you encounter any issue about that? > I don't know what you mean. I'm pretty

[PATCH libdrm 2/2] amdgpu: don't track handles for non-memory allocations

From: Marek Olšák --- amdgpu/amdgpu_bo.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c index 81f8a5f7..00b9b54a 100644 --- a/amdgpu/amdgpu_bo.c +++ b/amdgpu/amdgpu_bo.c @@ -91,26 +91,29 @@ drm_public int

[PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

From: Marek Olšák --- amdgpu/amdgpu_bo.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c index c0f42e81..81f8a5f7 100644 --- a/amdgpu/amdgpu_bo.c +++ b/amdgpu/amdgpu_bo.c @@ -22,20 +22,21 @@ * */ #include

Re: [PATCH] drm/amdgpu: Add DCC flags for GFX9 amdgpu_bo

Reviewed-by: Marek Olšák Marek On Tue, Oct 23, 2018 at 10:05 AM Nicholas Kazlauskas < nicholas.kazlaus...@amd.com> wrote: > [Why] > Hardware support for Delta Color Compression (DCC) decompression is > available in DC for GFX9 but there's no way for userspace to

Re: [PATCH 2/3] drm/amdgpu: increase the size of HQD EOP buffers

On Tue, Oct 9, 2018 at 12:17 PM Alex Deucher wrote: > On Fri, Oct 5, 2018 at 5:01 PM Marek Olšák wrote: > > > > From: Marek Olšák > > > > Signed-off-by: Marek Olšák > > --- > > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +- > > drivers/gpu/drm/am

[PATCH 3/3] drm/amdgpu: put HQD EOP buffers into VRAM

From: Marek Olšák This increases performance of compute queues. EOP events (PKT3_RELEASE_MEM) are stored into these buffers. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2

[PATCH 1/3] drm/amdgpu: set GTT_USWC on reserved VRAM allocations

From: Marek Olšák Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 904014dc5915..8e0f47343e0e 100644

[PATCH 2/3] drm/amdgpu: increase the size of HQD EOP buffers

From: Marek Olšák Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c index

Re: [PATCH libdrm v2 2/2] amdgpu/test: Fix deadlock tests for AI and RV v2

Yes, Andrey has commit rights. Marek On Wed, Oct 3, 2018 at 10:34 AM Christian König wrote: > > Thanks for keeping working on this. > > Series is Reviewed-by: Christian König as well. > > Do you now have commit rights? > > Christian. > > Am 02.10.2018 um 22:47 sc

Re: [PATCH libdrm v2 2/2] amdgpu/test: Fix deadlock tests for AI and RV v2

For the series: Reviewed-by: Marek Olšák Marek On Fri, Sep 28, 2018 at 10:46 AM Andrey Grodzovsky wrote: > > Seems like AI and RV requires uncashed memory mapping to be able > to pickup value written to memory by CPU after the WAIT_REG_MEM > command was already launched. > . &g

Re: [PATCH libdrm 1/3] amdgpu: Propogate user flags to amdgpu_bo_va_op_raw

This will break old UMDs that didn't set the flags correctly. Instead, UMDs should stop using amdgpu_bo_va_op if they want to set the flags. Marek On Thu, Sep 27, 2018 at 3:05 PM Andrey Grodzovsky wrote: > > Signed-off-by: Andrey Grodzovsky > --- > amdgpu/amdgpu_bo.c | 5 +++-- > 1 file changed

Re: [PATCH] drm/amdgpu: reserve GDS resources statically

tween per-VMID GDS and global GDS, but it's certainly something that people could add in the future. Marek On Thu, Sep 13, 2018 at 3:04 PM, Marek Olšák wrote: > I was thinking about that too, but it would be too much trouble for > something we don't need. > > Marek > >

Re: [PATCH] drm/amdgpu: reserve GDS resources statically

I was thinking about that too, but it would be too much trouble for something we don't need. Marek On Thu, Sep 13, 2018 at 2:57 PM, Deucher, Alexander wrote: > Why don't we just fix up the current GDS code so it works the same as vram > and then we can add a new CS or context flag to ignore the

Re: [PATCH] drm/amdgpu: reserve GDS resources statically

d of all that stuff if we really > don't need it. > > Christian. > > Am 13.09.2018 um 17:27 schrieb Marek Olšák: >> >> That's OK. We don't need IBs to get the same VMID. >> >> Marek >> >> On Thu, Sep 13, 2018 at 4:40 AM, Christian

Re: [PATCH] drm/amdgpu: reserve GDS resources statically

That's OK. We don't need IBs to get the same VMID. Marek On Thu, Sep 13, 2018 at 4:40 AM, Christian König wrote: > As discussed internally that doesn't work because threads don't necessary > get the same VMID assigned. > > Christian. > > Am 12.09.2018 um

[PATCH] drm/amdgpu: reserve GDS resources statically

From: Marek Olšák I've chosen to do it like this because it's easy and allows an arbitrary number of processes. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 10 -- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 3 - drivers/gpu/drm/amd/amdgpu/a

Re: [RFC] drm/amdgpu: Add macros and documentation for format modifiers.

On Fri, Sep 7, 2018 at 5:55 AM, Bas Nieuwenhuizen wrote: > On Fri, Sep 7, 2018 at 6:51 AM Marek Olšák wrote: >> >> Hopefully this answers some questions. >> >> Other parameters that affect tiling layouts are GB_ADDR_CONFIG (all >> chips) and MC_ARB_RAMCFG (GFX6-

Re: [RFC] drm/amdgpu: Add macros and documentation for format modifiers.

Hopefully this answers some questions. Other parameters that affect tiling layouts are GB_ADDR_CONFIG (all chips) and MC_ARB_RAMCFG (GFX6-8 only), and those vary with each chip. Some 32bpp 1D tiling layouts are compatible across all chips (1D display tiling is the same as SW_256B_D if Bpp == 4).

Re: [PATCH] drm/amdgpu: Refine gmc9 VM fault print.

Reviewed-by: Marek Olšák Marek On Mon, Aug 27, 2018 at 2:55 PM, Alex Deucher wrote: > On Mon, Aug 27, 2018 at 2:23 PM Andrey Grodzovsky > wrote: >> >> The fault reports the page number where the fault happend and not >> the exact faulty address. Update the print

Re: [PATCH 2/5] drm/amdgpu: add ring soft recovery v2

On Thu, Aug 23, 2018 at 2:51 AM Christian König wrote: > > Am 22.08.2018 um 21:32 schrieb Marek Olšák: > > On Wed, Aug 22, 2018 at 12:56 PM Alex Deucher wrote: > >> On Wed, Aug 22, 2018 at 6:05 AM Christian König > >> wrote: > >>> Instead of hammering

Re: [PATCH 2/5] drm/amdgpu: add ring soft recovery v2

On Wed, Aug 22, 2018 at 12:56 PM Alex Deucher wrote: > > On Wed, Aug 22, 2018 at 6:05 AM Christian König > wrote: > > > > Instead of hammering hard on the GPU try a soft recovery first. > > > > v2: reorder code a bit > > > > Signed-off-by: Christian König > > --- > > drivers/gpu/drm/amd/amdgpu/

Re: [PATCH libdrm 6/6] amdgpu: always add all BOs to lockup table

. > > Christian. > > > Am 09.08.2018 um 18:56 schrieb Marek Olšák: >> >> I don't think this is a good idea. Can you please explain why this >> won't cause performance regressions? >> >> Thanks >> Marek >> >> On Fri, Aug 3, 201

Re: [PATCH libdrm 6/6] amdgpu: always add all BOs to lockup table

I don't think this is a good idea. Can you please explain why this won't cause performance regressions? Thanks Marek On Fri, Aug 3, 2018 at 7:34 AM, Christian König wrote: > This way we can always find a BO structure by its handle. > > Signed-off-by: Christian König > --- > amdgpu/amdgpu_bo.c

Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

On Wed, Aug 1, 2018 at 2:29 PM, Christian König wrote: > Am 01.08.2018 um 19:59 schrieb Marek Olšák: >> >> On Wed, Aug 1, 2018 at 1:52 PM, Christian König >> wrote: >>> >>> Am 01.08.2018 um 19:39 schrieb Marek Olšák: >>>> >>>&

Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

On Wed, Aug 1, 2018 at 1:52 PM, Christian König wrote: > Am 01.08.2018 um 19:39 schrieb Marek Olšák: >> >> On Wed, Aug 1, 2018 at 2:32 AM, Christian König >> wrote: >>> >>> Am 01.08.2018 um 00:07 schrieb Marek Olšák: >>>> >>>> Can

Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

On Wed, Aug 1, 2018 at 2:32 AM, Christian König wrote: > Am 01.08.2018 um 00:07 schrieb Marek Olšák: >> >> Can this be implemented as a wrapper on top of libdrm? So that the >> tree (or hash table) isn't created for UMDs that don't need it. > > > No, the p

[ANNOUNCE] libdrm 2.4.93

hash table amdgpu: Destroy fd_hash table when the last device is removed. José Roberto de Souza (2): intel: Introducing Whiskey Lake platform intel: Introducing Amber Lake platform Kevin Strasser (1): xf86drm: Be sure to closedir before return Marek Olšák (3): a

Re: [PATCH 1/2] drm/amdgpu: return bo itself if userptr is cpu addr of bo (v3)

Can this be implemented as a wrapper on top of libdrm? So that the tree (or hash table) isn't created for UMDs that don't need it. Marek On Tue, Jul 31, 2018 at 6:13 AM, Christian König wrote: > Am 31.07.2018 um 11:54 schrieb Zhang, Jerry (Junwei): >> >> On 07/31/2018 05:04 PM, Christian König w

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

Christian, Would you please give me an Rb if the patch is OK with you? I have spoken with Michel and he would be OK with me pushing it as long as it gets an Rb from either you or Alex. Thanks, Marek On Wed, Jul 11, 2018 at 8:47 PM, Marek Olšák wrote: > From: Marek Olšák > > ---

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

On Wed, Jul 18, 2018 at 11:55 AM, Michel Dänzer wrote: > On 2018-07-17 08:14 PM, Marek Olšák wrote: >> Michel, I think you are wasting your time. This change can be misused >> as easily as any other API. It's not more dangerous that any other >> amdgpu libdrm function.

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

this (= losing performance on the lookup). Both are lose-lose solutions, because you'll lose and others will lose too. Marek On Tue, Jul 17, 2018 at 4:57 AM, Michel Dänzer wrote: > On 2018-07-16 08:51 PM, Marek Olšák wrote: >> On Mon, Jul 16, 2018 at 12:05 PM, Michel Dänzer wrot

<    1   2   3   4   5   6   >