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 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
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
+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
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
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
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
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
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
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.
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
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
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
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
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 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
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
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
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
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
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
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
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:
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
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:
> >
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
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
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
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_v11_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_v12_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_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_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_v10_0.c | 24 +---
>
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.
> >>
> >&
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 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 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 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:
> >>>
> >>
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
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 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
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
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
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
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
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
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:
> >
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:
> >
Based on the discussions we had about displayable DCC internally, only
MAX_COMPRESSED_BLOCK = 64B with both DCC_INDEPENDENT_64B_BLOCKS and
DCC_INDEPENDENT_128B_BLOCKS is supported by DCN on RDNA 2.
Is there something new on the hardware side that I missed?
Marek
On Tue, Sep 14, 2021 at 7:59 PM J
Ah, I forgot about 4K. It looks good. Thanks!
Marek
On Wed, Sep 15, 2021 at 8:23 PM Joshua Ashton wrote:
>
>
> On 9/16/21 01:11, Marek Olšák wrote:
> > Based on the discussions we had about displayable DCC internally, only
> > MAX_COMPRESSED_BLOCK = 64B with both DCC_INDEP
Hi,
Printing the backtrace from si_flush_gfx_cs while /etc/environment contains
GALLIUM_THREAD=0 at boot should show which GL call and X call caused the
flush.
Marek
On Thu, Sep 16, 2021 at 10:58 PM Quan, Evan wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Michel Dänzer
> >
used by gfx9 and gfx10.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/d
I've also amended the version bump that I forgot to do:
-#define KMS_DRIVER_MINOR 43
+#define KMS_DRIVER_MINOR 44
Marek
On Thu, Sep 30, 2021 at 12:06 PM Alex Deucher wrote:
> Acked-by: Alex Deucher
>
> On Thu, Sep 30, 2021 at 11:50 AM Marek Olšák wrote:
> >
"no_128" in the name.
>
> Is there something about it I am missing or is it just misleading naming?
>
> - Joshie 🐸✨
>
> On 9/30/21 17:14, Marek Olšák wrote:
> > I've also amended the version bump that I forgot to do:
> >
> > -#define KMS_DRIVER_MINOR
Mesa doesn't use sysfs.
Note that this is a uapi, meaning that once it's in the kernel, it can't be
changed like that.
What's the use case for this new interface? Isn't it partially redundant
with the current device info structure, which seems to have the equivalent
of dev_id and rev_id?
Marek
er, something that has been kept
> stable for many years.
>
> David
> --
> *From:* Christian König
> *Sent:* Tuesday, May 11, 2021 7:07 AM
> *To:* Deucher, Alexander ; Marek Olšák <
> mar...@gmail.com>
> *Cc:* Kees Cook ; Gu, JiaWei
I don't think fork() would work with userspace where all buffers are
shared. It certainly doesn't work now. The driver needs to be notified that
a buffer or texture is shared to ensure data coherency between processes,
and the driver must execute decompression and other render passes when a
buffer
Mesa doesn't have any use for this. It should be ok to expose just the
ioctl without userspace because it's just vbios info.
Marek
On Tue., May 18, 2021, 22:41 Gu, JiaWei (Will), wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Thanks Tom's suggestion.
> I'm fine to replace ioc
On Tue, Aug 4, 2020 at 5:32 PM Bas Nieuwenhuizen
wrote:
> This expose modifier support on GFX9+.
>
> Only modifiers that can be rendered on the current GPU are
> added. This is to reduce the number of modifiers exposed.
>
> The HW could expose more, but the best mechanism to decide
> what to expo
There are a few cases when the flags can change, for example DCC can be
disabled due to a hw limitation in the 3d engine. Modifiers give the
misleading impression that they help with that, but they don't. They don't
really help with anything.
Marek
On Mon., Aug. 10, 2020, 08:30 Christian König, <
On Wed, Aug 12, 2020 at 9:54 AM Daniel Vetter wrote:
> On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote:
> > There are a few cases when the flags can change, for example DCC can be
> > disabled due to a hw limitation in the 3d engine. Modifiers give the
> > misle
SET_SH_REG won't work with CP register shadowing. You need to use
WRITE_DATA or WREG32.
Marek
On Mon, Aug 24, 2020 at 7:57 AM Samuel Pitoiset
wrote:
> A trap handler can be used by userspace to catch shader exceptions
> like divide by zero, memory violations etc.
>
> On GFX6-GFX8, the registers
OK. Reviewed-by: Marek Olšák
Marek
On Wed, Sep 2, 2020 at 6:31 AM Bas Nieuwenhuizen
wrote:
> On Fri, Aug 7, 2020 at 9:43 PM Marek Olšák wrote:
> >
> > On Tue, Aug 4, 2020 at 5:32 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >
Monk or perhaps Felix,
Do you by any chance know why the CS ioctl returns -EINVAL for all compute
submissions if num_kcq <= 4 and what could cause that?
If not, is there any way to disable mid-IB preemption for compute?
Thanks,
Marek
On Fri, Jul 31, 2020 at 9:53 AM Felix Kuehling
wrote:
> Am
/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This fixes incorrect TCC harvesting info reported to userspace.
The impact was a very very tiny performance degradation (unnecessary
GL2 cache flushes).
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 22
Hi Sasha,
I disagree with this. Bumping the driver version will have implications on
other new features, because it's like an ABI barrier exposing new
functionality.
Marek
On Thu, May 7, 2020 at 10:28 AM Sasha Levin wrote:
> From: Marek Olšák
>
> [ U
Hi Christian,
Bas and Michel wanted to discuss this. The main disadvantage of no implicit
(pipeline) sync within the same queue is that we get lower performance and
lower GPU utilization in some cases.
We actually never really needed the kernel to have implicit sync, because
all user mode drivers
If a user mode driver is changed to rely on the existence of implicit sync,
it results in corruption and flickering as reported here:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2950
Marek
On Mon, May 25, 2020 at 6:05 PM Marek Olšák wrote:
> Hi Christian,
>
> Bas and Michel
On Thu, May 28, 2020 at 10:40 AM Christian König
wrote:
> Am 28.05.20 um 12:06 schrieb Michel Dänzer:
> > On 2020-05-28 11:11 a.m., Christian König wrote:
> >> Well we still need implicit sync [...]
> > Yeah, this isn't about "we don't want implicit sync", it's about "amdgpu
> > doesn't ensure la
On Thu, May 28, 2020 at 2:12 PM Christian König
wrote:
> Am 28.05.20 um 18:06 schrieb Marek Olšák:
>
> On Thu, May 28, 2020 at 10:40 AM Christian König
> wrote:
>
>> Am 28.05.20 um 12:06 schrieb Michel Dänzer:
>> > On 2020-05-28 11:11 a.m., Christian König w
sync should be inserted for implicit syncs well.
v2: bump the driver version
Signed-off-by: Christian König
Tested-by: Marek Olšák
Signed-off-by: Marek Olšák
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 4 +--
drivers/gpu
Only]
>
>
>
> Not sue if this is right direction, I think usermode wants all
> synchronizations to be explicit. Implicit sync often confuses people who
> don’t know its history. I remember Jason from Intel is driving explicit
> synchronization through the Linux ecosystem, which
red buffer, feel free go ahead.
>
> But if you add some description for its usage, that will be more clear to
> others.
>
> -David
> 在 2020/6/11 15:19, Marek Olšák 写道:
>
> Hi David,
>
> Explicit sync has nothing to do with this. This is for implicit sync,
> which
plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It's impossible to debug shader hangs with soft recovery.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/d
FYI, this fixes tiling on VanGogh.
Reviewed-by: Marek Olšák
Marek
On Tue, Oct 20, 2020 at 6:31 PM Bas Nieuwenhuizen
wrote:
> As far a I can tell uses a variant of DCN3xx which uses num_pkrs.
>
> If we do not initialize the variable we will set the register field
> to ilog2(0)
num_pkrs is a hardware config parameter like the number of shader engines.
It's constant for each chip.
Marek
On Wed, Oct 21, 2020 at 12:39 PM Bas Nieuwenhuizen
wrote:
> On Wed, Oct 21, 2020 at 6:09 PM Harry Wentland
> wrote:
> >
> > Even though log(0) is technically undefined our code assumes
: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index f7d217de5859..c78c615897f8
Updated patch.
Thanks,
Marek
On Tue, Nov 3, 2020 at 11:10 AM Marek Olšák wrote:
> Please review.
>
> Thanks,
> Marek
>
From c90a4b6a170dbeb1d2912612d842d2a8a7476eed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Tue, 3 Nov 2020 11:05:25 -0500
Subje
What is the behavior we should expect?
Marek
On Mon, Nov 23, 2020 at 7:31 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Ping, Pierre/Marek does this change works as expected?
>
> Regards,
> Christian.
>
> Am 18.11.20 um 14:20 schrieb Christian König:
> > This allows for optimiz
Pierre-Loup, does this do what you requested?
Thanks,
Marek
On Mon, Nov 23, 2020 at 3:17 PM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> That the CPU round trip is gone now.
>
> Christian.
>
> Am 23.11.20 um 20:49 schrieb Marek Olšák:
>
> What is th
: set LDS_CONFIG=0x20 on VanGogh to fix MGCG hang
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Same as Sienna Cichlid and Navy Flounder.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 +++
1 file changed, 3 insertions
The kernel could report the true alignment from the ioctl instead of 0.
Marek
On Fri, Sep 23, 2022 at 1:31 AM Christian König
wrote:
> Am 23.09.22 um 07:28 schrieb lepton:
> > On Thu, Sep 22, 2022 at 10:14 PM Christian König
> > wrote:
> >> Am 23.09.22 um 01:04 schrieb Lepton Wu:
> >>> Since s
I don't know what iris does, but I would guess that the same problems as
with AMD GPUs apply, making GPUs resets very fragile.
Marek
On Tue., Mar. 29, 2022, 08:14 Christian König,
wrote:
> My main question is what does the iris driver better than radeonsi when
> the client doesn't support the r
This needs to be a loop inserting all 64K_R_X and all 256K_R_X modifiers.
If num_pipes > 16, insert 256K_R_X first, else insert 64K_R_X first. Insert
the other one after that. For example:
for (unsigned i = 0; i < 2; i++) {
unsigned swizzle_r_x;
/* Insert the best one f
* AMDGPU_GEM_CREATE_FORCE_BEST_PLACEMENT (or
> > AMDGPU_GEM_CREATE_NO_GTT_FALLBACK ? or AMDGPU_CREATE_GEM_AVOID_GTT?):
> > tells the kernel that this bo really needs to be in VRAM
> >
> >
> > Pierre-Eric
> >
> > On 13/05/2022 00:17, Marek Olšák wrote:
> >&
Reviewed-by: Marek Olšák
for the series.
Marek
On Tue, Jul 19, 2022 at 3:53 PM Alex Deucher wrote:
> Ping on this series.
>
> Alex
>
> On Fri, Jul 8, 2022 at 6:56 PM Alex Deucher
> wrote:
> >
> > Use the former pad element to store the IP versions from the
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:
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
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,
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,
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,
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
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
> >>
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
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,
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.
>
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
1 - 100 of 510 matches
Mail list logo
