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
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
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:
> >>>
> >>
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
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
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
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.
> >>
> >&
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 +---
>
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 +---
>
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
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 --
>
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
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 --
>
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 +---
>
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
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
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
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:
> >
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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:
> >
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:
> >
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
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
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
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
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
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
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.
>
>
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
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
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
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
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:
> >
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
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
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:
>
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
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
> > +---
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
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.
> >
> &
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
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)
-
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
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
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
>>
>
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
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
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
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.
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
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
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
> > >
> > >
> >
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
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
>
>
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
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
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
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.
>
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,
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
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
> >>
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
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,
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,
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,
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,
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
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:
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
: 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
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
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
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
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
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.
>
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:
> >
>
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
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 - 100 of 510 matches
Mail list logo
