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/amdgpu/amdgp

[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/amd/amdgpu

[ANNOUNCE] libdrm 2.4.97

: 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.97 https://dri.freedesktop.org/libdrm

[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_0.c | 17

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 < > ckoenig.le

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

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

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

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

. > 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 ++ > > amdgpu/a

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

> > > > 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 when we want to use e.g. builtin sort

[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, 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 Marek Olšá

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

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. > > It does

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

e 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: Marek Olšá

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

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

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

[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.201

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

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

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 > > On Thu, Sep 1

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

l 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 König >> wrote: &g

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 22:33 schrieb Marek

[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/amdgpu_cs.c

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

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

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, 2018 at 7:34 AM, Christ

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

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

[ANNOUNCE] libdrm 2.4.93

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): amdgpu

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

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

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 wrote: >>> On 2

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

On Mon, Jul 16, 2018 at 12:05 PM, Michel Dänzer wrote: > On 2018-07-13 08:47 PM, Marek Olšák wrote: >> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer wrote: >>> On 2018-07-12 07:03 PM, Marek Olšák wrote: >>>> On Thu, Jul 12, 2018, 3:31 AM Michel Dänzer wrote: >

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer wrote: > On 2018-07-12 07:03 PM, Marek Olšák wrote: >> On Thu, Jul 12, 2018, 3:31 AM Michel Dänzer wrote: >>> On 2018-07-12 02:47 AM, Marek Olšák wrote: >>>> From: Marek Olšák >>>> >>>>

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

On Thu, Jul 12, 2018, 3:31 AM Michel Dänzer wrote: > On 2018-07-12 02:47 AM, Marek Olšák wrote: > > From: Marek Olšák > > > > --- > > amdgpu/amdgpu.h| 7 ++- > > amdgpu/amdgpu_bo.c | 4 > > 2 files changed, 10 insertions(+), 1 deletion(-)

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

On Wed, Jul 11, 2018 at 10:09 PM, zhoucm1 wrote: > > > On 2018年07月12日 08:47, Marek Olšák wrote: >> >> From: Marek Olšák > > less patch comment to describe why amdgpu_bo_handle_type_kms doesn't meet > requriement and what patch does. The comment in amdgpu.h describe

Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

On Wed, Jul 11, 2018 at 9:14 PM, Zhang, Jerry (Junwei) wrote: > On 07/12/2018 08:47 AM, Marek Olšák wrote: >> >> From: Marek Olšák >> >> --- >> amdgpu/amdgpu.h| 7 ++- >> amdgpu/amdgpu_bo.c | 4 >> 2 files changed, 10 insertion

[PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport

From: Marek Olšák --- amdgpu/amdgpu.h| 7 ++- amdgpu/amdgpu_bo.c | 4 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index 36f91058..be83b457 100644 --- a/amdgpu/amdgpu.h +++ b/amdgpu/amdgpu.h @@ -77,21 +77,26 @@ struct

[PATCH libdrm] amdgpu: don't call add_handle_to_table for KMS BO exports

From: Marek Olšák --- amdgpu/amdgpu_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c index 9e37b14..9e7f958 100644 --- a/amdgpu/amdgpu_bo.c +++ b/amdgpu/amdgpu_bo.c @@ -233,21 +233,21 @@ int amdgpu_bo_export(amdgpu_bo_handle bo

Re: [PATCH] drm/amdgpu: update ib_start/size_alignment same as windows used

Acked-by: Marek Olšák Marek On Fri, Jun 15, 2018, 4:03 AM zhoucm1 wrote: > Marek, Can I get your RB or Acked on this patches? Since these info are > reported to UMD. > > > Thanks, > > David Zhou > > > On 2018年06月15日 15:22, zhoucm1 wrote: > > > > &g

Re: [PATCH v2 1/1] drm/amdgpu: Enable scatter gather display support

Can you be more specific, Christian? Mesa has this, I don't think it needs anything else: https://cgit.freedesktop.org/mesa/mesa/commit/?id=7d2079908d9ef05ec3f35b7078833e57846cab5b Marek On Wed, Mar 28, 2018 at 3:46 AM, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 28.03.2018

[PATCH] drm/amdgpu: optionally do a writeback but don't invalidate TC for IB fences

From: Marek Olšák <marek.ol...@amd.com> There is a new IB flag that enables this new behavior. Full invalidation is unnecessary for RELEASE_MEM and doesn't make sense when draw calls from two adjacent gfx IBs run in parallel. This will be the new default for Mesa. v2: bump the version

[PATCH] drm/amdgpu: optionally do a writeback but don't invalidate TC for IB fences

From: Marek Olšák <marek.ol...@amd.com> There is a new IB flag that enables this new behavior. Full invalidation is unnecessary for RELEASE_MEM and doesn't make sense when draw calls from two adjacent gfx IBs run in parallel. This will be the new default for Mesa. Signed-off-by: Marek

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Wed, Mar 21, 2018 at 2:15 PM, Christian König <christian.koe...@amd.com> wrote: > Am 21.03.2018 um 19:04 schrieb Marek Olšák: > > On Wed, Mar 21, 2018 at 10:07 AM, Christian König < > christian.koe...@amd.com> wrote: > >> Am 21.03.2018 um 14:57 schrieb Marek

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Wed, Mar 21, 2018 at 10:07 AM, Christian König <christian.koe...@amd.com> wrote: > Am 21.03.2018 um 14:57 schrieb Marek Olšák: > > On Wed, Mar 21, 2018 at 4:13 AM, Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 21.03.2018 um 06:08 schrieb

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Wed, Mar 21, 2018 at 4:13 AM, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 21.03.2018 um 06:08 schrieb Marek Olšák: > > On Tue, Mar 20, 2018 at 4:16 PM, Christian König <christian.koe...@amd.com > > wrote: > >> That's what I meant with us

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

gt; BOs as well if the kernel can handle it. > > Christian. > > > Am 20.03.2018 um 00:01 schrieb Marek Olšák: > > In theory, Mesa doesn't have to do anything. It can continue setting VRAM > and if the kernel has to put a display buffer into GTT, it doesn't matter > (for Mesa). Whet

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

In theory, Mesa doesn't have to do anything. It can continue setting VRAM and if the kernel has to put a display buffer into GTT, it doesn't matter (for Mesa). Whether the VRAM placement is really used is largely determined by BO priorities. The way I understand scather/gather is that it only

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Mon, Mar 19, 2018 at 4:53 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Mon, Mar 19, 2018 at 4:26 PM, Marek Olšák <mar...@gmail.com> wrote: > > When Mesa wants a buffer in VRAM, it always sets VRAM. It relies on BO > move > > throttling to prevent un

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

..@lists.freedesktop.org] *On Behalf > Of *Deucher, Alexander > *Sent:* Monday, March 19, 2018 4:13 PM > > *To:* Li, Samuel <samuel...@amd.com>; Koenig, Christian < > christian.koe...@amd.com>; Marek Olšák <mar...@gmail.com> > *Cc:* Alex Deucher <alexdeuc.

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Mon, Mar 19, 2018 at 3:27 PM, Christian König wrote: > I think that the consensus with Alex and me is that we should avoid > exactly that. > > Overriding the preferred domain in the kernel is a no-go for that patch > set, so please implement the discussed changes in

[PATCH libdrm] amdgpu:support 16 ibs per submit for PAL/SRIOV

From: Qiang Yu to support SRIOV and MCBP, need 16 IBs per submit Signed-off-by: Qiang Yu Reviewed-by: Junwei Zhang --- amdgpu/amdgpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/amdgpu/amdgpu.h

Re: [PATCH libdrm 2/2] amdgpu: add AMDGPU_VA_RANGE_HIGH

For the series: Reviewed-by: Marek Olšák <marek.ol...@amd.com> Marek On Mon, Feb 26, 2018 at 2:16 PM, Christian König <ckoenig.leichtzumer...@gmail.com> wrote: > Return high addresses if requested and available. > > Signed-off-by: Christian König <christian.koe...@

Re: [Mesa-dev] [PATCH] winsys/amdgpu: request high addresses

Reviewed-by: Marek Olšák <marek.ol...@amd.com> Marek On Mon, Feb 26, 2018 at 2:17 PM, Christian König <ckoenig.leichtzumer...@gmail.com> wrote: > We now have hopefully fixed all bugs regarding high addresses on Vega10 and > Raven. Start to use the high range to make room

[PATCH libdrm] admgpu: add amdgpu_query_sw_info for querying high bits of 32-bit address space

From: Marek Olšák <marek.ol...@amd.com> --- amdgpu/amdgpu.h | 21 + amdgpu/amdgpu_device.c | 14 ++ amdgpu/amdgpu_internal.h | 1 + 3 files changed, 36 insertions(+) diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index 2eb03bf..928b2a6

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

On Fri, Feb 2, 2018 at 5:13 PM, mikhail <mikhail.v.gavri...@gmail.com> wrote: > On Thu, 2018-02-01 at 21:31 +0100, Marek Olšák wrote: >> >> Valgrind doesn't show any memory-related issue with Mesa. It does show >> an issue with "New Unity Project". This can c

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

On Thu, Feb 1, 2018 at 7:39 PM, mikhail <mikhail.v.gavri...@gmail.com> wrote: > On Thu, 2018-02-01 at 18:34 +0100, Marek Olšák wrote: >> On Thu, Feb 1, 2018 at 5:27 PM, mikhail <mikhail.v.gavri...@gmail.com >> > wrote: >> > On Tue, 2018-01-30 at 22:38 +0100, M

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

On Thu, Feb 1, 2018 at 5:27 PM, mikhail <mikhail.v.gavri...@gmail.com> wrote: > On Tue, 2018-01-30 at 22:38 +0100, Marek Olšák wrote: >> On Tue, Jan 30, 2018 at 10:36 PM, Marek Olšák <mar...@gmail.com> >> wrote: >> > On Tue, Jan 30, 2018 at 10:04 PM, mikhail

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

On Tue, Jan 30, 2018 at 10:36 PM, Marek Olšák <mar...@gmail.com> wrote: > On Tue, Jan 30, 2018 at 10:04 PM, mikhail <mikhail.v.gavri...@gmail.com> > wrote: >> On Tue, 2018-01-30 at 20:12 +0100, Marek Olšák wrote: >>> Can you record an apitrace on a driver that

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

On Tue, Jan 30, 2018 at 10:04 PM, mikhail <mikhail.v.gavri...@gmail.com> wrote: > On Tue, 2018-01-30 at 20:12 +0100, Marek Olšák wrote: >> Can you record an apitrace on a driver that is not radeonsi? > > All traces from five listed games was recorded on Intel GPU (not

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

On Tue, Jan 30, 2018 at 7:08 PM, mikhail wrote: > Launching games with latest llvm and mesa not solve problem. :( > > Current versions: > mesa: 17.4.0-0.18.git32170d8 > llvm: 7.0.0-0.1.r322903 > > /home/mikhail/.local/share/Steam/steamapps/common/Comedy Night/Comedy

Re: LLVM 7.0 + Wayland = broken mouse control

On Mon, Jan 29, 2018 at 8:58 PM, mikhail <mikhail.v.gavri...@gmail.com> wrote: > > On Mon, 2018-01-29 at 19:18 +0100, Marek Olšák wrote: >> Please report this issue to the gnome-shell team. gnome-shell has a >> bug in how they handle (or ignore) 10-bits-per-channel visuals

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

On Mon, Jan 29, 2018 at 6:51 PM, mikhail wrote: > > May be problem in my LLVM and MESA? > mesa: 17.4.0-0.16.git41c36c4 > llvm: 7.0.0-0.1.r322132 I don't know. > > I am couldn't update it to much newer version cause newer version is > breaks my GNOME desktop. I am

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

Neither of your apitraces crashes on my machine. Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: All games maded with Unity engine in steam catalog crashes on AMD GPU, but worked on Intel GPU on same machine.

[-gpudriverdevsupport (Bcc)] Let's keep this on amd-gfx. It looks like all backtraces crash in free() or operator delete(). I would say it's heap corruption. Can you record an apitrace on a driver that is not radeonsi? Can you correctly replay the apitrace on a driver that is not radeonsi? Can

Re: [PATCH xf86-video-amdgpu] Fix linear check in amdgpu_glamor_share_pixmap_backing

Reviewed-by: Marek Olšák <marek.ol...@amd.com> Marek On Mon, Jan 22, 2018 at 6:36 PM, Michel Dänzer <mic...@daenzer.net> wrote: > From: Michel Dänzer <michel.daen...@amd.com> > > We were incorrectly interpreting the tiling information. > > Reported-by: Marek Olš

Re: [PATCH libdrm 3/4] amdgpu: use the high VA range if possible v2

Actually, 0x8000 is fine. For the series: Reviewed-by: Marek Olšák <marek.ol...@amd.com> Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm 3/4] amdgpu: use the high VA range if possible v2

Can we put the 32-bit address space higher? E.g. high bits = 0xfff0 ? Marek On Sun, Jan 7, 2018 at 10:11 AM, Christian König wrote: > Retire the low range on Vega10 this frees up everything below > 0x8000 for HMM. > > v2: keep the 32bit range

Re: [PATCH libdrm 1/3] amdgpu: Clean up amdgpu_parse_asic_ids error handling

On Fri, Dec 1, 2017 at 5:56 PM, Michel Dänzer wrote: > From: Michel Dänzer > > * Move error message printing into amdgpu_parse_asic_ids and make it > return void > * Print only "Invalid format" error message if parse_one_line returns > -EINVAL > *

Re: [PATCH] amdgpu: disable GPU reset if amdgpu.lockup_timeout=0

On Tue, Dec 12, 2017 at 5:36 PM, Christian König <ckoenig.leichtzumer...@gmail.com> wrote: > Am 12.12.2017 um 15:57 schrieb Marek Olšák: >> >> On Tue, Dec 12, 2017 at 10:01 AM, Christian König >> <ckoenig.leichtzumer...@gmail.com> wrote: >>> >

Re: [PATCH] amdgpu: disable GPU reset if amdgpu.lockup_timeout=0

On Tue, Dec 12, 2017 at 4:18 AM, Liu, Monk wrote: > NAK, you change break SRIOV logic: > > Without lockup_timeout set, this gpu_recover() won't get called at all , > unless your IB triggered invalid instruct and that IRQ invoked > Amdgpu_gpu_recover(), by this cause you should

Re: [PATCH] amdgpu: disable GPU reset if amdgpu.lockup_timeout=0

On Tue, Dec 12, 2017 at 10:01 AM, Christian König <ckoenig.leichtzumer...@gmail.com> wrote: > Am 11.12.2017 um 22:29 schrieb Marek Olšák: >> >> From: Marek Olšák <marek.ol...@amd.com> >> >> Signed-off-by: Marek Olšák <marek.ol...@amd.com> >> -

[PATCH] amdgpu: disable GPU reset if amdgpu.lockup_timeout=0

From: Marek Olšák <marek.ol...@amd.com> Signed-off-by: Marek Olšák <marek.ol...@amd.com> --- Is this really correct? I have no easy way to test it. drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu

Re: [PATCH libdrm] [drm] - Adding amdgpu_cs_create_syncobj2 to create syncobj as signaled initially

You need a freedesktop.org account: https://www.freedesktop.org/wiki/AccountRequests/ Marek On Tue, Nov 28, 2017 at 2:32 PM, Mao, David wrote: > I have never tried to commit the change before. So I guess the answer is no. > Could you let me know, how I can apply for the

Re: [PATCH] amdgpu: Add R600_DEBUG flag to reserve VMID per ctx.

Pushed with a fixed typo and whitespace, thanks. Marek On Thu, Nov 2, 2017 at 3:50 PM, Andrey Grodzovsky wrote: > Fixes reverted patch f03b7c9 by doing VMID reservation per > process and not per context. > Also updates required amdgpu libdrm version since the change >

<    1   2   3   4   5   >