Re: [PATCH] drm/amdgpu: always allocate cleared VRAM for GEM allocations

2024-09-06 Thread Marek Olšák
On Fri, Sep 6, 2024 at 1:53 PM Alex Deucher wrote: > > On Fri, Sep 6, 2024 at 10:18 AM Marek Olšák wrote: > > > > Can you also bump the DRM version, so that userspace knows when to > > skip its own clear? > > Sure, although going forward, it might be better to migr

Re: [PATCH] drm/amdgpu: always allocate cleared VRAM for GEM allocations

2024-09-06 Thread Marek Olšák
Can you also bump the DRM version, so that userspace knows when to skip its own clear? Also, clearing with SDMA takes up to 33 times more time (= is up to 97% slower) than clearing with compute. Marek On Thu, Aug 29, 2024 at 2:23 PM Paneer Selvam, Arunpravin wrote: > > this will fix performance

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-08-07 Thread Marek Olšák
On Wed, Aug 7, 2024 at 4:21 AM Tvrtko Ursulin wrote: > > > On 04/08/2024 19:11, Marek Olšák wrote: > > On Thu, Aug 1, 2024 at 2:55 PM Marek Olšák wrote: > >> > >> On Thu, Aug 1, 2024, 03:37 Christian König > >> wrote: > >>> > >>

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-08-04 Thread Marek Olšák
On Thu, Aug 1, 2024 at 2:55 PM Marek Olšák wrote: > > On Thu, Aug 1, 2024, 03:37 Christian König wrote: >> >> Am 01.08.24 um 08:53 schrieb Marek Olšák: >> >> On Thu, Aug 1, 2024, 00:28 Khatri, Sunil wrote: >>> >>> >>> On 8/1/2024 8:49 AM

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-08-03 Thread Marek Olšák
On Fri, Aug 2, 2024 at 6:10 AM Lazar, Lijo wrote: > > > > On 8/2/2024 12:25 AM, Marek Olšák wrote: > > On Thu, Aug 1, 2024, 03:37 Christian König > <mailto:christian.koe...@amd.com>> wrote: > > > > __ > > Am 01.08.24 um 08:53 schrieb

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-08-01 Thread Marek Olšák
On Thu, Aug 1, 2024, 03:37 Christian König wrote: > Am 01.08.24 um 08:53 schrieb Marek Olšák: > > On Thu, Aug 1, 2024, 00:28 Khatri, Sunil wrote: > >> >> On 8/1/2024 8:49 AM, Marek Olšák wrote: >> >> + /* Header is at index 0, followed by num_nops - 1

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-07-31 Thread Marek Olšák
On Thu, Aug 1, 2024, 00:28 Khatri, Sunil wrote: > > On 8/1/2024 8:49 AM, Marek Olšák wrote: > > On Tue, Jul 30, 2024 at 8:43 AM Sunil Khatri > wrote: > >> Adding NOP packets one by one in the ring > >> does not use the CP efficiently. > >> > >&

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-07-31 Thread Marek Olšák
he Header instead of fetching all NOP packets > one by one. > > Cc: Christian König > Cc: Pierre-Eric Pelloux-Prayer > Cc: Tvrtko Ursulin > Cc: Marek Olšák > Signed-off-by: Sunil Khatri > --- > drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 24 +--- >

Re: [PATCH v1 2/3] drm/amdgpu: optimize the padding for gfx9

2024-07-31 Thread Marek Olšák
he Header instead of fetching all NOP packets > one by one. > > Cc: Christian König > Cc: Pierre-Eric Pelloux-Prayer > Cc: Tvrtko Ursulin > Cc: Marek Olšák > Signed-off-by: Sunil Khatri > --- > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 24 +--- >

Re: [PATCH v1 3/3] drm/amdgpu: optimize the padding for gfx_v9_4_3

2024-07-31 Thread Marek Olšák
he Header instead of fetching all NOP packets > one by one. > > Cc: Christian König > Cc: Pierre-Eric Pelloux-Prayer > Cc: Tvrtko Ursulin > Cc: Marek Olšák > Signed-off-by: Sunil Khatri > --- > drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 20 +++- > 1 f

Re: [PATCH v1 1/3] drm/amdgpu: optimize the padding for gfx12

2024-07-31 Thread Marek Olšák
he Header instead of fetching all NOP packets > one by one. > > Cc: Christian König > Cc: Pierre-Eric Pelloux-Prayer > Cc: Tvrtko Ursulin > Cc: Marek Olšák > Signed-off-by: Sunil Khatri > --- > drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 22 -- >

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-07-31 Thread Marek Olšák
On Wed, Jul 31, 2024 at 11:19 PM Marek Olšák wrote: > > On Tue, Jul 30, 2024 at 8:43 AM Sunil Khatri wrote: > > > > Adding NOP packets one by one in the ring > > does not use the CP efficiently. > > > > Solution: > > Use CP optimization while addi

Re: [PATCH 2/2] drm/amdgpu: optimize the padding for gfx11

2024-07-31 Thread Marek Olšák
he Header instead of fetching all NOP packets > one by one. > > Cc: Christian König > Cc: Pierre-Eric Pelloux-Prayer > Cc: Tvrtko Ursulin > Cc: Marek Olšák > Signed-off-by: Sunil Khatri > --- > drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 22 -- >

Re: [PATCH] drm/amdgpu: optimize the padding with hw optimization

2024-07-31 Thread Marek Olšák
he Header instead of fetching all NOP packets > one by one. > > Cc: Christian König > Cc: Pierre-Eric Pelloux-Prayer > Cc: Tvrtko Ursulin > Cc: Marek Olšák > Signed-off-by: Sunil Khatri > --- > drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 24 +--- >

Re: [PATCH v7 1/2] drm/buddy: Add start address support to trim function

2024-07-23 Thread Marek Olšák
The reason is that our DCC requires 768K alignment in some cases. I haven't read this patch series, but one way to do that is to align to 256K, overallocate by 512K, and then not use either 0, 256K, or 512K at the beginning to get to 768K alignment. Marek On Tue, Jul 23, 2024, 11:04 Matthew Auld

Re: [PATCH v5 2/2] drm/amdgpu: Add address alignment support to DCC buffers

2024-07-16 Thread Marek Olšák
AMDGPU_GEM_CREATE_GFX12_DCC is set on 90% of all memory allocations, and almost all of them are not displayable. Shouldn't we use a different way to indicate that we need a non-power-of-two alignment, such as looking at the alignment field directly? Marek On Tue, Jul 16, 2024, 11:45 Arunpravin Pa

Re: [PATCH] drm/amd: Bump KMS_DRIVER_MINOR version

2024-07-12 Thread Marek Olšák
Reviewed-by: Marek Olšák Marek On Thu, Jul 11, 2024 at 11:05 AM Aurabindo Pillai wrote: > > Increase the KMS minor version to indicate GFX12 DCC support since this > contains a major change in how DCC is managed across IPs like GFX, DCN > etc. This will be used mainly by userspace

Re: [PATCH] drm/amd/display: Allow display DCC for DCN401

2024-07-10 Thread Marek Olšák
Can you also increase KMS_DRIVER_MINOR with a proper comment in amdgpu_drv.c, which will be used by Mesa to tell whether display DCC is supported on gfx12? Thanks, Marek On Wed, Jul 10, 2024 at 4:05 PM Aurabindo Pillai wrote: > > > > On 7/10/24 10:49 AM, Marek Olšák wrote: > >

Re: [PATCH] drm/amd/display: Allow display DCC for DCN401

2024-07-10 Thread Marek Olšák
This will enable display DCC for Wayland because Mesa already exposes modifiers with DCC. Has it been tested? Marek On Mon, Jul 8, 2024 at 12:06 PM Aurabindo Pillai wrote: > > To enable mesa to use display dcc, DM should expose them in the > supported modifiers. Add the best (most efficient) mod

Re: [PATCH] drm/amdgpu: restore dcc bo tilling configs while moving

2024-07-02 Thread Marek Olšák
data_format == 13, 15, and 23 are also invalid. Marek On Tue, Jul 2, 2024 at 12:05 PM Marek Olšák wrote: > > I think the change should fix invalid values passed from userspace. > > max_com == 3 should be clamped to 2. > data_format == 0 || data_format > 24 should do 2 things:

Re: [PATCH] drm/amdgpu: restore dcc bo tilling configs while moving

2024-07-02 Thread Marek Olšák
I think the change should fix invalid values passed from userspace. max_com == 3 should be clamped to 2. data_format == 0 || data_format > 24 should do 2 things: set data_format to 10, set num_format to 0. Marek On Tue, Jul 2, 2024 at 9:43 AM Marek Olšák wrote: > > Reviewed-by: Ma

Re: [PATCH] drm/amdgpu: restore dcc bo tilling configs while moving

2024-07-02 Thread Marek Olšák
Reviewed-by: Marek Olšák On Sun, Jun 30, 2024 at 11:35 PM Min, Frank wrote: > > [AMD Official Use Only - AMD Internal Distribution Only] > > From: Frank Min > > While moving buffer which as dcc tiling config, it is needed to restore its > original dcc tiling. > > 1

[PATCH 12/13] drm/amdgpu/display: add all gfx12 modifiers

2024-06-26 Thread Marek Olšák
Signed-off-by: Marek Olšák --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c index

[PATCH 13/13] drm/amdgpu: rewrite convert_tiling_flags_to_modifier_gfx12

2024-06-26 Thread Marek Olšák
There were multiple bugs, like checking SWIZZLE_MODE before checking GFX12_SWIZZLE_MODE, which has undefined behavior. The function had no effect before (it always returned -EINVAL). Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 45 + 1 file

[PATCH 10/13] drm/amdgpu/display: handle gfx12 in amdgpu_dm_plane_format_mod_supported

2024-06-26 Thread Marek Olšák
All this code has undefined behavior on GFX12 and shouldn't be executed. Signed-off-by: Marek Olšák --- .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 47 ++- 1 file changed, 25 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pl

[PATCH 09/13] drm/amdgpu: handle gfx12 in amdgpu_display_verify_sizes

2024-06-26 Thread Marek Olšák
It verified GFX9-11 swizzle modes on GFX12, which has undefined behavior. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 27 - include/uapi/drm/drm_fourcc.h | 2 ++ 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a

[PATCH 08/13] drm/amdgpu: don't use amdgpu_lookup_format_info on gfx12

2024-06-26 Thread Marek Olšák
It only uses fields for GFX9-11 related to the separate DCC buffer, which doesn't exist in GFX12. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/dr

[PATCH 07/13] drm/amdgpu: add amdgpu_framebuffer::gfx12_dcc

2024-06-26 Thread Marek Olšák
amdgpu_framebuffer doesn't have tiling_flags, so we need this. amdgpu_display_get_fb_info never gets NULL parameters, so checking for NULL was useless. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 15 --- drivers/gpu/drm/amd/amdgpu/amdgpu_m

[PATCH 11/13] drm/amdgpu/display: set plane attributes for gfx12 correctly

2024-06-26 Thread Marek Olšák
It used gfx9 flags, which has undefined behavior on gfx12. Signed-off-by: Marek Olšák --- .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 50 ++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c b/drivers/gpu

[PATCH 06/13] drm/amdgpu/display: handle gfx12 in dm_check_cursor_fb

2024-06-26 Thread Marek Olšák
Checking SWIZZLE_MODE has undefined behavior on gfx12. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display

[PATCH 05/13] drm/amdgpu: remove AMD_FMT_MOD_GFX12_DCC_MAX_COMPRESSED_BLOCK_* definitions

2024-06-26 Thread Marek Olšák
They were added accidentally. Signed-off-by: Marek Olšák --- include/uapi/drm/drm_fourcc.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index d0063ac6e09f..4168445fbb8b 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b

[PATCH 03/13] drm/amdgpu/gfx12: remove superfluous cache flags

2024-06-26 Thread Marek Olšák
If any INV flags are needed, they should be executed via ACQUIRE_MEM before INDIRECT_BUFFER. GLM flags are also removed because the hw ignores them. Signed-off-by: Marek Olšák Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 6 -- 1 file changed, 6 deletions(-) diff

[PATCH 04/13] drm/amdgpu/gfx12: remove GDS leftovers

2024-06-26 Thread Marek Olšák
GDS doesn't exist in gfx12. The incomplete packet allows userspace to hang the hw from the kernel. Signed-off-by: Marek Olšák Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 16 1 file changed, 16 deletions(-) diff --git a/drivers/gpu/drm/amd/a

[PATCH 02/13] drm/amdgpu/gfx11: remove superfluous cache flags

2024-06-26 Thread Marek Olšák
If any INV flags are needed, they should be executed via ACQUIRE_MEM before INDIRECT_BUFFER. Signed-off-by: Marek Olšák Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu

[PATCH 01/13] drm/amdgpu: check for LINEAR_ALIGNED correctly in check_tiling_flags_gfx6

2024-06-26 Thread Marek Olšák
Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c index cfec85563bc6..3c5fb907bdd9 100644 --- a/drivers/gpu

Re: [PATCH 4/6] drm/amdgpu: add AMDGPU_INFO_GB_ADDR_CONFIG query

2024-06-19 Thread Marek Olšák
s > and work around issues because of legacy hw. > > Regards, > Christian. > > Am 19.06.24 um 02:34 schrieb Marek Olšák: > > I would put this into drm_amdgpu_info_device. That structure can grow in > > size. > > > > Marek > > > > On T

Re: [PATCH 4/6] drm/amdgpu: add AMDGPU_INFO_GB_ADDR_CONFIG query

2024-06-18 Thread Marek Olšák
I would put this into drm_amdgpu_info_device. That structure can grow in size. Marek On Tue, Jun 18, 2024 at 11:30 AM Pierre-Eric Pelloux-Prayer wrote: > > libdrm_amdgpu uses AMDGPU_INFO_READ_MMR_REG to fill the dev->info.gb_addr_cfg > value. > Since this value is already known by the kernel, th

Re: "firmware/sysfb: Set firmware-framebuffer parent device" breaks lightdm on Ubuntu 22.04 using amdgpu

2024-06-13 Thread Marek Olšák
On Thu, Jun 13, 2024 at 3:23 AM Thomas Zimmermann wrote: > > Hi > > Am 13.06.24 um 08:00 schrieb Marek Olšák: > > +amd-gfx > > > > On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote: > >> Hi Thomas, > >> > >> Commit 9eac534db0013aff9b912

Re: "firmware/sysfb: Set firmware-framebuffer parent device" breaks lightdm on Ubuntu 22.04 using amdgpu

2024-06-12 Thread Marek Olšák
+amd-gfx On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote: > > Hi Thomas, > > Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title > breaks (crashes?) lightdm (login screen) such that all I get is the > terminal. It's also reproducible with tag v6.9 where

Re: [RFC PATCH 00/18] TTM interface for managing VRAM oversubscription

2024-04-25 Thread Marek Olšák
The most extreme ping-ponging is mitigated by throttling buffer moves in the kernel, but it only works without VM_ALWAYS_VALID and you can set BO priorities in the BO list. A better approach that works with VM_ALWAYS_VALID would be nice. Marek On Wed, Apr 24, 2024 at 1:12 PM Friedrich Vock wrote

Re: [PATCH 1/3] drm/amdgpu: Forward soft recovery errors to userspace

2024-03-09 Thread Marek Olšák
Reviewed-by: Marek Olšák Marek On Fri, Mar 8, 2024 at 3:43 AM Christian König wrote: > > Am 07.03.24 um 20:04 schrieb Joshua Ashton: > > As we discussed before[1], soft recovery should be > > forwarded to userspace, or we can get into a really > > bad state where a

Re: [PATCH 2/2] drm/amdgpu: Mark ctx as guilty in ring_soft_recovery path

2024-01-15 Thread Marek Olšák
On Mon, Jan 15, 2024 at 3:06 PM Christian König wrote: > > Am 15.01.24 um 20:30 schrieb Joshua Ashton: > > On 1/15/24 19:19, Christian König wrote: > >> Am 15.01.24 um 20:13 schrieb Joshua Ashton: > >>> On 1/15/24 18:53, Christian König wrote: > Am 15.01.24 um 19:35 schrieb Joshua Ashton: > >

Re: [PATCH 2/2] drm/amdgpu: Mark ctx as guilty in ring_soft_recovery path

2024-01-15 Thread Marek Olšák
On Mon, Jan 15, 2024 at 11:41 AM Michel Dänzer wrote: > > On 2024-01-15 17:19, Friedrich Vock wrote: > > On 15.01.24 16:43, Joshua Ashton wrote: > >> On 1/15/24 15:25, Michel Dänzer wrote: > >>> On 2024-01-15 14:17, Christian König wrote: > Am 15.01.24 um 12:37 schrieb Joshua Ashton: > >

Re: [PATCH] Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole"

2024-01-10 Thread Marek Olšák
ernel outside the ranges reserved for the kernel. Marek On Sat, Jan 6, 2024 at 1:48 AM Marek Olšák wrote: > > The 32-bit address space means the high 32 bits are constant and > predetermined and it's definitely somewhere in the upper range of the address > space. If ROCm or

Re: 回复: Re: 回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2

2024-01-09 Thread Marek Olšák
int p = -1. unsigned u = p; int p2 = u; p2 is -1. Marek On Tue, Jan 9, 2024, 03:26 Christian König wrote: > Am 09.01.24 um 09:09 schrieb 李真能: > > Thanks! > > What about the second patch? > > The second patch: amdgpu: change proirity value to be consistent with > kernel. > > As I want to pass

Re: [PATCH] Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole"

2024-01-05 Thread Marek Olšák
crashing Mesa application shuts down. > Reverting Jay's patch certainly didn't fix that, but only hides the > problem. > > Regards, >Felix > > > On 2024-01-04 13:29, Marek Olšák wrote: > > Hi, > > > > I have received information that the origi

Re: [PATCH] Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole"

2024-01-04 Thread Marek Olšák
Hi, I have received information that the original commit makes all 32-bit userspace VA allocations fail, so UMDs like Mesa can't even initialize and they either crash or fail to load. If TBA/TMA was relocated to the 32-bit address range, it would explain why UMDs can't allocate anything in that ra

Re: [PATCH] drm/amdgpu: Enable tunneling on high-priority compute queues

2023-12-11 Thread Marek Olšák
On Fri, Dec 8, 2023 at 1:37 PM Alex Deucher wrote: > On Fri, Dec 8, 2023 at 12:27 PM Joshua Ashton wrote: > > > > FWIW, we are shipping this right now in SteamOS Preview channel > > (probably going to Stable soon) and it seems to be working as expected > > and fixing issues there in instances we

Re: [PATCH] drm/amdgpu: Enable tunneling on high-priority compute queues

2023-12-08 Thread Marek Olšák
On Fri, Dec 8, 2023 at 9:57 AM Christian König wrote: > Am 08.12.23 um 12:43 schrieb Friedrich Vock: > > On 08.12.23 10:51, Christian König wrote: > >> Well longer story short Alex and I have been digging up the > >> documentation for this and as far as we can tell this isn't correct. > > Huh. I

Re: [PATCH] drm/amdgpu: Enable tunneling on high-priority compute queues

2023-12-08 Thread Marek Olšák
It's correct according to our documentation. Reviewed-by: Marek Olšák Marek On Fri, Dec 8, 2023 at 5:47 AM Christian König wrote: > Well longer story short Alex and I have been digging up the > documentation for this and as far as we can tell this isn't correct. > >

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-08-09 Thread Marek Olšák
On Wed, Aug 9, 2023 at 3:35 AM Michel Dänzer wrote: > > On 8/8/23 19:03, Marek Olšák wrote: > > It's the same situation as SIGSEGV. A process can catch the signal, > > but if it doesn't, it gets killed. GL and Vulkan APIs give you a way > > to catch the

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-08-08 Thread Marek Olšák
It's the same situation as SIGSEGV. A process can catch the signal, but if it doesn't, it gets killed. GL and Vulkan APIs give you a way to catch the GPU error and prevent the process termination. If you don't use the API, you'll get undefined behavior, which means anything can happen, including pr

Re: Non-robust apps and resets (was Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations)

2023-08-02 Thread Marek Olšák
A screen that doesn't update isn't usable. Killing the window system and returning to the login screen is one option. Killing the window system manually from a terminal or over ssh and then returning to the login screen is another option, but 99% of users either hard-reset the machine or do sysrq+R

Re: Non-robust apps and resets (was Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations)

2023-07-25 Thread Marek Olšák
On Tue, Jul 25, 2023 at 4:03 AM Michel Dänzer wrote: > > On 7/25/23 04:55, André Almeida wrote: > > Hi everyone, > > > > It's not clear what we should do about non-robust OpenGL apps after GPU > > resets, so I'll try to summarize the topic, show some options and my > > proposal to move forward o

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-07-05 Thread Marek Olšák
On Wed, Jul 5, 2023 at 3:32 AM Michel Dänzer wrote: > > On 7/5/23 08:30, Marek Olšák wrote: > > On Tue, Jul 4, 2023, 03:55 Michel Dänzer wrote: > > On 7/4/23 04:34, Marek Olšák wrote: > > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer > > wrote: > >

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-07-04 Thread Marek Olšák
On Tue, Jul 4, 2023, 03:55 Michel Dänzer wrote: > On 7/4/23 04:34, Marek Olšák wrote: > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer <mailto:michel.daen...@mailbox.org>> wrote: > > On 6/30/23 22:32, Marek Olšák wrote: > > > On Fri, Jun 30, 2023 at 11:11

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-07-03 Thread Marek Olšák
On Mon, Jul 3, 2023, 22:38 Randy Dunlap wrote: > > > On 7/3/23 19:34, Marek Olšák wrote: > > > > > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer <mailto:michel.daen...@mailbox.org>> wrote: > > > > Marek, > Please stop sending html emails to the ma

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-07-03 Thread Marek Olšák
On Mon, Jul 3, 2023, 03:12 Michel Dänzer wrote: > On 6/30/23 22:32, Marek Olšák wrote: > > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer < > michel.daen...@mailbox.org <mailto:michel.daen...@mailbox.org>> wrote: > >> On 6/30/23 16:59, Alex Deucher wrote: >

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-06-30 Thread Marek Olšák
That's a terrible idea. Ignoring API calls would be identical to a freeze. You might as well disable GPU recovery because the result would be the same. There are 2 scenarios: - robust contexts: report the GPU reset status and skip API calls; let the app recreate the context to recover - non-robust

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-06-27 Thread Marek Olšák
On Tue, Jun 27, 2023 at 5:31 PM André Almeida wrote: > Hi Marek, > > Em 27/06/2023 15:57, Marek Olšák escreveu: > > On Tue, Jun 27, 2023, 09:23 André Almeida > <mailto:andrealm...@igalia.com>> wrote: > > > > +User Mode Driver > > +---

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-06-27 Thread Marek Olšák
On Tue, Jun 27, 2023, 09:23 André Almeida wrote: > Create a section that specifies how to deal with DRM device resets for > kernel and userspace drivers. > > Acked-by: Pekka Paalanen > Signed-off-by: André Almeida > --- > > v4: > https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@i

Re: [RFC PATCH 0/1] Add AMDGPU_INFO_GUILTY_APP ioctl

2023-05-03 Thread Marek Olšák
On Wed, May 3, 2023, 14:53 André Almeida wrote: > Em 03/05/2023 14:08, Marek Olšák escreveu: > > GPU hangs are pretty common post-bringup. They are not common per user, > > but if we gather all hangs from all users, we can have lots and lots of > > them. > > > &

Re: [RFC PATCH 0/1] Add AMDGPU_INFO_GUILTY_APP ioctl

2023-05-03 Thread Marek Olšák
WRITE_DATA with ENGINE=PFP will execute the packet on the frontend engine, while ENGINE=ME will execute the packet on the backend engine. Marek On Wed, May 3, 2023 at 1:08 PM Marek Olšák wrote: > GPU hangs are pretty common post-bringup. They are not common per user, > but if we gath

Re: [RFC PATCH 0/1] Add AMDGPU_INFO_GUILTY_APP ioctl

2023-05-03 Thread Marek Olšák
GPU hangs are pretty common post-bringup. They are not common per user, but if we gather all hangs from all users, we can have lots and lots of them. GPU hangs are indeed not very debuggable. There are however some things we can do: - Identify the hanging IB by its VA (the kernel should know it) -

Re: drm/amd/display: disable display DCC with retiling due to worse power consumption

2023-05-01 Thread Marek Olšák
We're going to do this in Mesa instead: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22771 Marek On Fri, Apr 28, 2023 at 6:36 PM Marek Olšák wrote: > On Fri, Apr 28, 2023, 16:14 Joshua Ashton wrote: > >> I mean I would also like power and perf numbers for

Re: drm/amd/display: disable display DCC with retiling due to worse power consumption

2023-04-28 Thread Marek Olšák
cino have worse power consumption with retiled displayable DCC and modifiers, and that can also be due to how retiling is implemented for modifiers. Marek > - Joshie 🐸✨ > > On Friday, 28 April 2023, Marek Olšák wrote: > > I thought the same thing initially, but then realized

Re: drm/amd/display: disable display DCC with retiling due to worse power consumption

2023-04-28 Thread Marek Olšák
o avoid regressing perf. > > - Joshie 🐸✨ > > On 28 April 2023 10:47:17 BST, "Marek Olšák" wrote: >> >> Hi, >> >> It's attached for review. >> >> Thanks, >> Marek >> >

Re: drm/amd/display: disable display DCC with retiling due to worse power consumption

2023-04-28 Thread Marek Olšák
6 Hamza Mahfooz wrote: > > Hey Marek, > > On 4/28/23 05:47, Marek Olšák wrote: > > Hi, > > > > It's attached for review. > > Please send this to the mailing list using git-send-email(1). Also, > please include a commit description and it would be helpful

drm/amd/display: disable display DCC with retiling due to worse power consumption

2023-04-28 Thread Marek Olšák
ption MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plan

Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type

2023-04-26 Thread Marek Olšák
probability. No such app can be allowed to continue executing after a reset. Marek On Wed, Apr 26, 2023 at 5:51 AM Michel Dänzer wrote: > On 4/25/23 21:11, Marek Olšák wrote: > > The last 3 comments in this thread contain arguments that are false and > were specifically pointed out as fals

Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type

2023-04-25 Thread Marek Olšák
y the case. If an application has > enabled robustness it should notice that something went wrong and act > appropriately. > > The only thing we need to handle is for applications without robustness > in case of a hard reset or otherwise it will trigger an reset over and > over again.

Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type

2023-04-25 Thread Marek Olšák
ed by userspace may result in persistent corruption. Marek On Tue, Apr 25, 2023 at 6:27 AM Michel Dänzer wrote: > On 4/24/23 18:45, Marek Olšák wrote: > > Soft resets are fatal just as hard resets, but no reset is "always > fatal". There are cases when apps keep working

Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type

2023-04-24 Thread Marek Olšák
Soft resets are fatal just as hard resets, but no reset is "always fatal". There are cases when apps keep working depending on which features are being used. It's still unsafe. Marek On Mon, Apr 24, 2023, 03:03 Christian König wrote: > Am 24.04.23 um 03:43 schrieb André Almeida: > > When a DRM

Re: [PATCH 03/13] drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers

2023-04-13 Thread Marek Olšák
ss. It's just a > passthrough to the packet. If we discover we need it at some point, > it would be nice to not have to add a new interface to add it. > > Alex > > > > > Christian. > > > > > > > > Alex > > > > > > > >

Re: [PATCH 03/13] drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers

2023-04-13 Thread Marek Olšák
he GDS information because they were unnecessary. The GDS size > was already part of the device info before we added the shadow info. > > But as far as I know the firmware needs valid VAs for all three buffers or > won't work correctly. > > Christian. > > Am 06.04.23 um

Re: [PATCH 03/13] drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers

2023-04-06 Thread Marek Olšák
ote: > That's what I thought as well, but Mitch/Hans insisted on that. > > We should probably double check internally. > > Christian. > > Am 06.04.23 um 11:43 schrieb Marek Olšák: > > GDS memory isn't used on gfx11. Only GDS OA is used. > > Marek > >

Re: [PATCH 03/13] drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers

2023-04-06 Thread Marek Olšák
GDS memory isn't used on gfx11. Only GDS OA is used. Marek On Thu, Apr 6, 2023 at 5:09 AM Christian König wrote: > Why that? > > This is the save buffer for GDS, not the old style GDS BOs. > > Christian. > > Am 06.04.23 um 09:36 schrieb Marek Olšák: > > gds_va

Re: [PATCH 03/13] drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers

2023-04-06 Thread Marek Olšák
gds_va is unnecessary. Marek On Thu, Mar 30, 2023 at 3:18 PM Alex Deucher wrote: > For GFX11, the UMD needs to allocate some shadow buffers > to be used for preemption. The UMD allocates the buffers > and passes the GPU virtual address to the kernel since the > kernel will program the packet t

Re: [PATCH 07/13] drm/amdgpu: add UAPI to query GFX shadow sizes

2023-03-27 Thread Marek Olšák
Reviewed-by: Marek Olšák On Thu, Mar 23, 2023 at 5:41 PM Alex Deucher wrote: > Add UAPI to query the GFX shadow buffer requirements > for preemption on GFX11. UMDs need to specify the shadow > areas for preemption. > > v2: move into existing asic info query > drop

Re: [PATCH v3 1/5] drm/amdgpu: add UAPI for workload hints to ctx ioctl

2023-03-22 Thread Marek Olšák
n Wed, Mar 22, 2023 at 10:37 AM Marek Olšák wrote: > > > > It sounds like the kernel should set the hint based on which queues are > used, so that every UMD doesn't have to duplicate the same logic. > > Userspace has a better idea of what they are doing than the kernel. >

Re: [PATCH v3 1/5] drm/amdgpu: add UAPI for workload hints to ctx ioctl

2023-03-22 Thread Marek Olšák
t; code for Mesa to actually use it. Otherwise we don't have the justification > to push it into the kernel driver. > > Christian. > > Am 22.03.23 um 15:24 schrieb Marek Olšák: > > The hint is static per API (one of graphics, video, compute, unknown). In > the case of Vulkan,

Re: [PATCH v3 1/5] drm/amdgpu: add UAPI for workload hints to ctx ioctl

2023-03-22 Thread Marek Olšák
e should remove the getting the hint from the UAPI. > > But what's wrong with setting it after creating the context? Don't you > know enough about the use case? I need to understand the background a bit > better here. > > Christian. > > Am 22.03.23 um 15:05 sch

Re: [PATCH 07/11] drm/amdgpu: add UAPI to query GFX shadow sizes

2023-03-22 Thread Marek Olšák
On Tue, Mar 21, 2023 at 3:51 PM Alex Deucher wrote: > On Mon, Mar 20, 2023 at 8:30 PM Marek Olšák wrote: > > > > > > On Mon, Mar 20, 2023 at 1:38 PM Alex Deucher > wrote: > >> > >> Add UAPI to query the GFX shadow buffer requirements > >>

Re: [PATCH 07/11] drm/amdgpu: add UAPI to query GFX shadow sizes

2023-03-22 Thread Marek Olšák
On Tue, Mar 21, 2023 at 3:54 PM Alex Deucher wrote: > On Mon, Mar 20, 2023 at 8:31 PM Marek Olšák wrote: > > > > On Mon, Mar 20, 2023 at 1:38 PM Alex Deucher > wrote: > >> > >> Add UAPI to query the GFX shadow buffer requirements > >> for preempti

Re: [PATCH v3 1/5] drm/amdgpu: add UAPI for workload hints to ctx ioctl

2023-03-22 Thread Marek Olšák
etails: > > https://patchwork.freedesktop.org/patch/496111/ > > > > Regards > > Shashank > > > > *From:* Marek Olšák > *Sent:* 21 March 2023 04:05 > *To:* Sharma, Shashank > *Cc:* amd-gfx@lists.freedesktop.org; Deucher, Alexander > ; Somalapuram,

Re: [PATCH v3 1/5] drm/amdgpu: add UAPI for workload hints to ctx ioctl

2023-03-20 Thread Marek Olšák
I think we should do it differently because this interface will be mostly unused by open source userspace in its current form. Let's set the workload hint in drm_amdgpu_ctx_in::flags, and that will be immutable for the lifetime of the context. No other interface is needed. Marek On Mon, Sep 26,

Re: [PATCH 07/11] drm/amdgpu: add UAPI to query GFX shadow sizes

2023-03-20 Thread Marek Olšák
On Mon, Mar 20, 2023 at 1:38 PM Alex Deucher wrote: > Add UAPI to query the GFX shadow buffer requirements > for preemption on GFX11. UMDs need to specify the shadow > areas for preemption. > > Signed-off-by: Alex Deucher > --- > include/uapi/drm/amdgpu_drm.h | 10 ++ > 1 file changed,

Re: [PATCH 07/11] drm/amdgpu: add UAPI to query GFX shadow sizes

2023-03-20 Thread Marek Olšák
On Mon, Mar 20, 2023 at 1:38 PM Alex Deucher wrote: > Add UAPI to query the GFX shadow buffer requirements > for preemption on GFX11. UMDs need to specify the shadow > areas for preemption. > > Signed-off-by: Alex Deucher > --- > include/uapi/drm/amdgpu_drm.h | 10 ++ > 1 file changed,

Re: [PATCH] drm/amdgpu: expose more memory stats in fdinfo

2023-03-09 Thread Marek Olšák
Ping On Thu, Feb 23, 2023 at 1:46 PM Marek Olšák wrote: > Updated patch attached. > > Marek > > On Mon, Feb 6, 2023 at 4:05 AM Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Just two nit picks: >> >> +seq_pri

Re: [PATCH] drm/amdgpu: expose more memory stats in fdinfo

2023-02-23 Thread Marek Olšák
rs. > > Kerneldoc complicent comments look like this: > > /* @timestamp replaced by @rcu on dma_fence_release() */ > struct rcu_head rcu; > > Apart from that looks good to me. > > Regards, > Christian. > > Am 30.01.23 um 07:56 schrieb Marek Olšák:

[PATCH] drm/amdgpu: expose more memory stats in fdinfo

2023-01-29 Thread Marek Olšák
in fdinfo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This will be used for performance investigations. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 24 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

[PATCH] drm/amdgpu: add more fields into device info, caches sizes, etc.

2023-01-29 Thread Marek Olšák
: important for conformance on gfx11 Other fields are exposed from IP discovery. enabled_rb_pipes_mask_hi is added for future chips, currently 0. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 ++ drivers/gpu/drm/amd/amdgpu

Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM

2023-01-24 Thread Marek Olšák
A new Gallium HUD "value producer" could be added that reads fdinfo without calling the driver. I still think there is merit in having this in amdgpu_drm.h too. Marek On Tue, Jan 24, 2023 at 3:13 AM Marek Olšák wrote: > The table of exposed driver-specific counte

Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM

2023-01-24 Thread Marek Olšák
nt to add some more values nor have the values > as part of the UAPI. > > Christian. > > Am 24.01.23 um 08:37 schrieb Marek Olšák: > > The Gallium HUD doesn't consume strings. It only consumes values that are > exposed as counters from the driver. In this case, we nee

Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM

2023-01-23 Thread Marek Olšák
e userspace HUD. > > Regards, > Christian. > > Am 21.01.23 um 01:45 schrieb Marek Olšák: > > We badly need a way to query evicted memory usage. It's essential for > investigating performance problems and it uncovered the buddy allocator > disaster. Please either suggest a

Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM

2023-01-20 Thread Marek Olšák
We badly need a way to query evicted memory usage. It's essential for investigating performance problems and it uncovered the buddy allocator disaster. Please either suggest an alternative, suggest changes, or review. We need it ASAP. Thanks, Marek On Tue, Jan 10, 2023 at 11:55 AM Marek

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

2023-01-13 Thread Marek Olšák
Valve would like this in kernel 6.2, but if put it there, we also need to backport INFO ioctl changes for DRM driver version 3.50.0. Marek On Fri, Jan 13, 2023 at 6:33 PM Marek Olšák wrote: > There is no hole on 32-bit unfortunately. It looks like the hole on 64-bit > is now ABI. >

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

2023-01-13 Thread Marek Olšák
There is no hole on 32-bit unfortunately. It looks like the hole on 64-bit is now ABI. I moved the field to replace _pad1. The patch is attached (with your Rb). Marek On Fri, Jan 13, 2023 at 4:20 PM Alex Deucher wrote: > On Fri, Jan 13, 2023 at 4:02 PM Marek Olšák wrote: > > >

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

2023-01-13 Thread Marek Olšák
i've added the comments and indeed pahole shows the hole as expected. Marek On Thu, Jan 12, 2023 at 11:44 AM Alex Deucher wrote: > On Thu, Jan 12, 2023 at 6:50 AM Christian König > wrote: > > > > Am 11.01.23 um 21:48 schrieb Alex Deucher: > > > On Wed, Ja

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

2023-01-11 Thread Marek Olšák
On Wed, Jan 11, 2023, 15:50 Alex Deucher wrote: > On Wed, Jan 11, 2023 at 3:48 PM Alex Deucher > wrote: > > > > On Wed, Jan 4, 2023 at 3:17 PM Marek Olšák wrote: > > > > > > Yes, it's meant to be like a spec sheet. We are not interested in the >

  1   2   3   4   5   6   >