Reviewed-by: Marek Olšák
Marek
On Fri, Jul 4, 2025 at 3:43 AM Jesse Zhang wrote:
> The term "HQD" is CP-specific and doesn't
> accurately describe the queue resources for other IP blocks like SDMA,
> VCN, or VPE. This change:
>
> 1. Renames `num_hqds` to `num_sl
USHRT_MAX seems too low. Traces for workstation apps create 20-30k BOs,
which is not very far from the limit. RADV doesn't suballocate BOs. Neither
GL nor VK has a ilmit on the number of BOs that can be created. The
hypothetical maximum number of BOs that can be allocated on a GPU with 32GB
of addr
On Mon, Apr 14, 2025 at 7:33 AM Christian König
wrote:
> Am 12.04.25 um 10:03 schrieb Arunpravin Paneer Selvam:
> > Add queue id support to the user queue wait IOCTL
> > drm_amdgpu_userq_wait structure.
> >
> > This is required to retrieve the wait user queue and maintain
> > the fence driver ref
Reviewed-by: Marek Olšák
For both patches.
Marek
On Mon, Mar 24, 2025 at 4:34 PM Alex Deucher
wrote:
> Add an INFO query to check if user queues are supported.
>
> v2: switch to a mask of IPs (Marek)
> v3: move to drm_amdgpu_info_device (Marek)
>
> Cc: marek.ol...@amd.
Adding it into drm_amdgpu_info_device with a DRM version bump is better.
Marek
On Fri, Mar 21, 2025 at 4:54 PM Alex Deucher wrote:
> I can move it into device_info if that's better.
>
> Alex
>
> On Fri, Mar 21, 2025 at 3:42 PM Marek Olšák wrote:
> >
> > This
This is not in device_info, but it'll do.
Reviewed-by: Marek Olšák
Marek
On Mon, Mar 17, 2025 at 5:38 PM Alex Deucher
wrote:
> Add an INFO query to check if user queues are supported.
>
> v2: switch to a mask of IPs (Marek)
>
> Cc: marek.ol...@amd.com
> Cc: p
I would prefer a bitmask of supported UQ IPs in device info, but this is
fine too.
Reviewed-by: Marek Olšák
Marek
On Mon, Mar 17, 2025 at 3:23 PM Alex Deucher
wrote:
> Add an INFO query to check if user queues are supported.
>
> Cc: marek.ol...@amd.com
> Cc: prike.li...@
On Mon, Mar 17, 2025 at 2:27 PM Alex Deucher wrote:
> On Mon, Mar 17, 2025 at 1:23 PM Marek Olšák wrote:
> >
> > Userspace needs a query that a queue IP type is supported.
> "available_rings" is used for that right now, but if that's 0, somethin
Userspace needs a query that a queue IP type is supported.
"available_rings" is used for that right now, but if that's 0, something
else must indicate IP support.
amd_ip_info::num_queues should be non-zero even when user queues are
supported. The exact number doesn't matter with user queues.
Mare
The hw supports it.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
From 02f89c11dca69c6555f8bad75c84b50126c53554 Mon Sep 17 00:00:00
Reviewed-by: Marek Olšák
On Tue, Jun 18, 2019 at 3:19 AM Richard Thier wrote:
> num_gb_pipes was set to a wrong value using r420_pipe_config
>
> This have lead to HyperZ glitches on fast Z clearing.
>
> See: https://bugs.freedesktop.org/show_bug.cgi?id=110897
>
> Signed-
Ping. This is urgent.
Marek
On Mon, Jan 27, 2025 at 10:52 AM Marek Olšák wrote:
> Updated patch attached.
>
> Vulkan can't support DCC and Z/S compression on GFX12 without this.
>
> Marek
>
> On Fri, Jan 24, 2025 at 10:15 AM Marek Olšák wrote:
>
>> Require
Updated patch attached.
Vulkan can't support DCC and Z/S compression on GFX12 without this.
Marek
On Fri, Jan 24, 2025 at 10:15 AM Marek Olšák wrote:
> Required by Vulkan because it can allocate whole VRAM as 1 BO and parts
> of it bypass compression and read raw data.
>
&
So it's implemented but not enabled by default, right?
Marek
On Fri, Jan 24, 2025 at 12:40 PM Alex Deucher wrote:
> On Fri, Jan 24, 2025 at 12:38 PM SRINIVASAN SHANMUGAM
> wrote:
> >
> >
> > On 1/24/2025 10:01 PM, Marek Olšák wrote:
> >
> > Does this
Does this commit really enable it though? Or is it just for sysfs?
Marek
On Fri, Jan 24, 2025 at 1:42 AM Srinivasan Shanmugam <
srinivasan.shanmu...@amd.com> wrote:
> Enable the cleaner shader for GFX10.1.1/10.1.2 GPUs to provide data
> isolation between GPU workloads. The cleaner shader is resp
Required by Vulkan because it can allocate whole VRAM as 1 BO and parts
of it bypass compression and read raw data.
Signed-off-by: Marek Olšák
From 98d5342d1b6f247fc6addca48febf0334a445bf5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Fri, 24 Jan 2025 09:43:45 -0500
On Mon, Jan 20, 2025 at 1:41 PM Simona Vetter
wrote:
> On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> >
> > Am 18.01.25 um 03:37 schrieb Marek Olšák:
> > [...]
> > >
> > > 3) Implementing DRM_FORMAT_MOD_LINEAR as
15, 2025 at 12:20:07PM +, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote:
> > > On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone
> wrote:
> > >> AMD hardware is the only hardware I know of which doesn't support
> > >> overalig
On Tue, Jan 14, 2025 at 1:34 PM Faith Ekstrand wrote:
> On January 14, 2025 03:39:45 Marek Olšák wrote:
>
>> I would keep the existing modifier interfaces, API extensions, and
>> expectations the same as today for simplicity.
>>
>> The new linear modifier definit
On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
> Hi,
>
> On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote:
> > I would keep the existing modifier interfaces, API extensions, and
> expectations the same as today for simplicity.
>
> Well yes, not just for simplicity
On Tue, Jan 14, 2025 at 12:55 PM James Jones wrote:
> I don't see how that fits in the current modifier usage patterns. I'm
> not clear how applications are supposed to programmatically "look at the
> modifiers of other drivers to find commonalities," nor how that "keeps
> "expectations the same
I would keep the existing modifier interfaces, API extensions, and
expectations the same as today for simplicity.
The new linear modifier definition (proposal) will have these fields:
5 bits for log2 pitch alignment in bytes
5 bits for log2 height alignment in rows
5 bits for log2 offset
On Fri, Dec 20, 2024 at 10:24 AM Simona Vetter
wrote:
> On Thu, Dec 19, 2024 at 05:09:33PM +0100, Michel Dänzer wrote:
> > On 2024-12-19 10:02, Daniel Stone wrote:
> > >
> > > How this would be used in practice is also way too underdocumented. We
> > > need to document that exact-round-up 64b is
>
> * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> * match only a single modifier.
>
That sentence is misleading and impossible to meet. Specifications are
sometimes changed to reflect the overwhelming reality. Multiple modifiers
can represent identical layouts
On Thu, Dec 19, 2024 at 5:32 AM Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 09:53:56PM +0000, Marek Olšák wrote:
> > On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey
> wrote:
> >
> > > On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > > >
On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> >
> > For that reason I think linear modifiers with explicit pitch/size
> > alignment constraints is a sound concept and fits into how modifiers work
> > overall.
> > -Sima
>
>
On Mon, Dec 16, 2024 at 9:53 AM Simona Vetter
wrote:
> On Mon, Dec 16, 2024 at 11:46:13AM +0100, Lucas Stach wrote:
> > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > > On 2024-12-15 21:53, Marek Olšák wrote:
> > > > The com
On Mon, Dec 16, 2024 at 5:46 AM Lucas Stach wrote:
> Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > On 2024-12-15 21:53, Marek Olšák wrote:
> > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> > >
> > > Signed-off-
On Mon, Dec 16, 2024 at 4:28 AM Dmitry Baryshkov <
dmitry.barysh...@linaro.org> wrote:
> On Mon, Dec 16, 2024 at 12:40:54AM -0500, Marek Olšák wrote:
> > git send-email (or rather the way it sends email) has been banned by
> gmail
> > due to being considered unsecure. I
On Mon, Dec 16, 2024 at 4:27 AM Michel Dänzer
wrote:
> On 2024-12-15 21:53, Marek Olšák wrote:
> > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >
> > Signed-off-by: Marek Olšák marek.ol...@amd.com>>
> >
> > diff --git a/include/uap
>
> You should really just be using git send-email.
>
> On 12/15/24 11:57 PM, Marek Olšák wrote:
> > Only for you: Attached.
> >
> > Marek
> >
> > On Sun, Dec 15, 2024 at 6:37 PM Joshua Ashton > <mailto:jos...@froggi.es>> wrote:
> >
> &g
Only for you: Attached.
Marek
On Sun, Dec 15, 2024 at 6:37 PM Joshua Ashton wrote:
> You should just re-send the whole patch, probably.
>
> On 12/15/24 8:54 PM, Marek Olšák wrote:
> > Missed 2 lines from the diff:
> >
> > +#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_1
Missed 2 lines from the diff:
+#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_128B fourcc_mod_code(NONE, 2)
+#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_256B fourcc_mod_code(NONE, 3)
Marek
On Sun, Dec 15, 2024 at 3:53 PM Marek Olšák wrote:
> The comment explains the problem w
The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
Signed-off-by: Marek Olšák
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 78abd819fd62e..8ec4163429014 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -484,9 +484,27
Reviewed-by: Marek Olšák
BTW, we don't have to define everything here. We can use most of the
32 values freely.
Marek
On Fri, Oct 25, 2024 at 2:03 AM Qiang Yu wrote:
>
> From: Qiang Yu
>
> This is used when radeonsi export small texture's modifier
> to user with eglE
Selvam
> Acked-by: Christian König
> Suggested-by: Marek Olšák
> Suggested-by: Christian König
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 238 +-
> include/uapi/drm/amdgpu_drm.h | 48 ++--
> 2 files changed, 206 insertions(+), 8
Reviewed-by: Marek Olšák
Marek
On Thu, Sep 26, 2024 at 10:02 AM Alex Deucher wrote:
>
> On Thu, Sep 26, 2024 at 10:00 AM Marek Olšák wrote:
> >
> > Is GTT cleared too?
>
> GTT has always been cleared since it's system memory.
>
> Alex
>
>
> >
>
Is GTT cleared too?
Marek
On Thu, Sep 26, 2024, 09:53 Alex Deucher wrote:
> Ping?
>
> On Fri, Sep 6, 2024 at 2:04 PM Alex Deucher
> wrote:
> >
> > Driver now clears VRAM on allocation. Bump the
> > driver version so mesa knows when it will get
> > cleared vram by default.
> >
> > Signed-off-b
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.
> >
> &
1 - 100 of 548 matches
Mail list logo
