From: Michel Dänzer
It incorrectly claimed a resource isn't CPU visible if it's located at
the very end of CPU visible VRAM.
Fixes: a6ff969fe9 ("drm/amdgpu: fix visible VRAM handling during faults")
Reported-and-Tested-by: Jeremy Day
Signed-off-by: Michel Dänzer
---
drivers/g
0, res->size, );
while (cursor.remaining) {
- if ((cursor.start + cursor.size) >= adev->gmc.visible_vram_size)
+ if ((cursor.start + cursor.size) > adev->gmc.visible_vram_size)
return false;
amdgpu_res_next(, cursor.size);
}
> If we submit this before the clear-page-tracking patches are in, this will
> cause unacceptable performance regressions for ROCm applications.
I agree this probably shouldn't land earlier than that, ideally together or
shortly after though.
--
Earthling Michel Dänzer|
> We have use cases where that hurts as. Especially during boot when the
> backing VRAM isn't cleared yet.
>
> That's one of the reasons why we never always cleared the memory.
Any such performance gain was only valid in the first place if the kernel
delivering non-cleared memory to user space was considered acceptable, which it
quite clearly isn't.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2024-02-26 17:53, Christian König wrote:
> Am 26.02.24 um 17:50 schrieb Michel Dänzer:
>> On 2024-02-26 17:46, Michel Dänzer wrote:
>>> On 2024-02-26 17:34, Christian König wrote:
>>>
>>>> My question is why has it worked so far? I mean we a
On 2024-02-26 17:46, Michel Dänzer wrote:
> On 2024-02-26 17:34, Christian König wrote:
>
>> My question is why has it worked so far? I mean we are not doing this since
>> yesterday and the problem only shows up now?
>
> Yes, Wayland compositors are only starting to try
On 2024-02-26 17:34, Christian König wrote:
> Am 26.02.24 um 17:27 schrieb Michel Dänzer:
>> On 2024-02-26 16:58, Christian König wrote:
>>> Am 23.02.24 um 17:43 schrieb Michel Dänzer:
>>>> On 2024-02-23 11:04, Michel Dänzer wrote:
>>>>> On 2024-
On 2024-02-26 16:58, Christian König wrote:
> Am 23.02.24 um 17:43 schrieb Michel Dänzer:
>> On 2024-02-23 11:04, Michel Dänzer wrote:
>>> On 2024-02-23 10:34, Christian König wrote:
>>>> Am 23.02.24 um 09:11 schrieb Michel Dänzer:
>>>>> On 2024-
On 2024-02-23 11:04, Michel Dänzer wrote:
> On 2024-02-23 10:34, Christian König wrote:
>> Am 23.02.24 um 09:11 schrieb Michel Dänzer:
>>> On 2024-02-23 08:06, Christian König wrote:
>>>> Am 22.02.24 um 18:28 schrieb Michel Dänzer:
>>>>> From: Mich
On 2024-02-23 10:34, Christian König wrote:
> Am 23.02.24 um 09:11 schrieb Michel Dänzer:
>> On 2024-02-23 08:06, Christian König wrote:
>>> Am 22.02.24 um 18:28 schrieb Michel Dänzer:
>>>> From: Michel Dänzer
>>>>
>>>> Pinning the BO
On 2024-02-23 09:11, Michel Dänzer wrote:
> On 2024-02-23 08:06, Christian König wrote:
>>
>> So rejecting things during CS and atomic commit is the best thing we can do.
>
> It's problematic for a Wayland compositor:
>
> The CS ioctl failing is awkward. With G
On 2024-02-23 08:06, Christian König wrote:
> Am 22.02.24 um 18:28 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> Pinning the BO storage to VRAM for scanout would make it inaccessible
>> to non-P2P dma-buf importers.
>
> Thinking more about it I don't think
From: Michel Dänzer
Pinning the BO storage to VRAM for scanout would make it inaccessible
to non-P2P dma-buf importers.
Also keep file_priv->prime.lock locked until after bumping bo->num_fbs
in amdgpu_display_user_framebuffer_create, so that the checks there and
in amdgpu_dma_buf_
From: Michel Dänzer
Pinning the BO storage to VRAM for scanout would make it inaccessible
to non-P2P dma-buf importers.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10635
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 38 ++---
1
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 14 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3 +++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu
before calling into the driver to commit the
atomic commit.
I can't see why this wouldn't work with async commits, the same as with
synchronous ones, with any driver.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 1/15/24 18:53, Christian König wrote:
>>>>>>>>>> Am 15.01.24 um 19:35 schrieb Joshua Ashton:
>>>>>>>>>>> On 1/15/24 18:30, Bas Nieuwenhuizen wrote:
>>>>>>>>>>>> On Mon, Jan 15, 2024 at 7:14 PM F
On 2024-01-15 18:26, Friedrich Vock wrote:
> On 15.01.24 18:09, Michel Dänzer wrote:
>> On 2024-01-15 17:46, Joshua Ashton wrote:
>>> On 1/15/24 16:34, Michel Dänzer wrote:
>>>> On 2024-01-15 17:19, Friedrich Vock wrote:
>>>>> On 15.01.24 16:43, Joshua
On 2024-01-15 17:46, Joshua Ashton wrote:
> On 1/15/24 16:34, 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, Chris
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 1/15/24 09:40, Chris
eas Marek's proposal at the time would have kicked
me back to the login screen every time. > 0 vs effectively 0 chance of survival.
[0] Except for Firefox unnecessarily falling back to software rendering, which
is a side note, not the main point.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2023-12-14 11:31, Christian König wrote:
> Am 13.12.23 um 16:46 schrieb Michel Dänzer:
>> From a security PoV, the kernel should never return uncleared memory to (at
>> least unprivileged) user space. This series seems like a big step in that
>> direction.
>
&
gt; I don't think it's strictly necessary. But it may encourage sloppy user mode
> programming to rely on 0-initialized memory that ends up breaking in corner
> cases or on older kernels.
>From a security PoV, the kernel should never return uncleared memory to (at
>least unprivileged) user space. This series seems like a big step in that
>direction.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
at for performance, but not great for
> power.
Maybe the firmware power management heuristics could be derived from the system
power profile and fence deadline? E.g. the power profile defines the upper and
lower boundaries, the upper boundary is used while there's a pending f
On 11/13/23 10:47, Simon Ser wrote:
> On Monday, November 13th, 2023 at 10:41, Michel Dänzer
> wrote:
>
>> On 11/13/23 10:18, Simon Ser wrote:
>>
>>> On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
>>>
>&g
s
>> previous one will result in a new page-flip for asynchronous page-flips,
>> but will not result in any side-effect for asynchronous page-flips.
>>
>> Does it actually matter though? For async page-flips, I don't think this
>> would result in any actual difference in behavior?
>
> To sum this up, here is a matrix of behavior as seen by user-space:
>
> - Sync atomic page-flip
> - Set FB_ID to different value: programs hw for page-flip, sends uevent
> - Set FB_ID to same value: same (important for VRR)
> - Set another plane prop to same value: same
A page flip is programmed even if FB_ID isn't touched?
> - Set another plane prop to different value: maybe rejected if modeset
> required
> - Async atomic page-flip
> - Set FB_ID to different value: updates hw with new FB address, sends
> immediate uevent
> - Set FB_ID to same value: same (no-op for the hw)
No-op implies it doesn't trigger scanning out a frame with VRR, if scanout is
currently in vertical blank. Is that the case? If so, async flips can't
reliably trigger scanning out a frame with VRR.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
at the end of *_sw_init() instead of _late_init().
>>>
>>> I suggest to just come up with a function which can be used for the
>>> late_init() callback of the UVD/VCE blocks.
>>
>> I guess the issue is that we only need to initialize the entity once
>> so sw_init makes sense. All of the other functions get called at
>> resume time, etc. I think we could probably put it into
>> amdgpu_device_init_schedulers() somehow.
>
> I think something like this might do the trick.
This does indeed fix the IB test failures for me with Bonaire.
There are still
[drm] Fence fallback timer expired on ring sdma0
messages, that might be a separate regression though.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 10/31/23 15:34, Christian König wrote:
> Am 31.10.23 um 15:14 schrieb Michel Dänzer:
>
>> FWIW, RADV will also want explicit sync in the CS ioctl.
> You can replace that with the DMA-buf IOCTLs like Faith is planning to do for
> NVK.
Those ioctls cannot disable implic
is that the current libdrm implementation shares
> the DRM handle even between different kind of drivers (radeonsi vs radv).
Different drivers always use separate contexts though, even with the same DRM
file description, don't they?
FWIW, RADV will also want explicit sync i
On 10/23/23 10:27, Simon Ser wrote:
> On Sunday, October 22nd, 2023 at 12:12, Michel Dänzer
> wrote:
>> On 10/17/23 14:16, Simon Ser wrote:
>>
>>> After discussing with André it seems like we missed a plane type check
>>> here. We need to make sure FB_ID
On 10/17/23 14:16, Simon Ser wrote:
> After discussing with André it seems like we missed a plane type check
> here. We need to make sure FB_ID changes are only allowed on primary
> planes.
Can you elaborate why that's needed?
--
Earthling Michel Dänzer|
On 10/2/23 12:48, Michel Dänzer wrote:
> On 10/2/23 12:05, Michel Dänzer wrote:
>> On 9/29/23 22:41, Hamza Mahfooz wrote:
>>> From: Ivan Lipski
>>>
>>> This reverts commit 45e1ade04b4d60fe5df859076005779f27c4c9be.
>>>
>>> Since, it causes
From: Michel Dänzer
If no plane was newly enabled or changed scaling, there can be no new
scaling mismatch with the cursor plane.
By not pulling non-cursor plane states into all atomic commits while
the cursor plane is enabled, this avoids synchronizing all cursor plane
changes to vertical
From: Michel Dänzer
Cleanup, no functional change intended.
Signed-off-by: Michel Dänzer
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 +++
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu
On 10/2/23 12:05, Michel Dänzer wrote:
> On 9/29/23 22:41, Hamza Mahfooz wrote:
>> From: Ivan Lipski
>>
>> This reverts commit 45e1ade04b4d60fe5df859076005779f27c4c9be.
>>
>> Since, it causes the following IGT tests to fail:
>> kms_cursor_legacy@cursor
about how those tests fail? Maybe they accidentally rely on the
broken behaviour?
FWIW, something like the reverted commit is definitely needed, see
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1829068 . That
MR is blocked by the reverted fix.
--
Ea
On 9/14/23 22:52, Alex Deucher wrote:
> On Mon, Sep 11, 2023 at 10:36 AM Michel Dänzer wrote:
>>
>> From: Michel Dänzer
>>
>> It can be NULL e.g. with Raven.
>>
>> Fixes: 927e784c180c ("drm/amd/display: Add symclk enable/disable during
>> strea
From: Michel Dänzer
It was only checking planes which had any state changes in the same
commit. However, it also needs to check other enabled planes.
Not doing this meant that a commit might spuriously "succeed", resulting
in the cursor plane displaying with incorrect scaling.
From: Michel Dänzer
It can be NULL e.g. with Raven.
Fixes: 927e784c180c ("drm/amd/display: Add symclk enable/disable during stream
enable/disable")
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 6 --
1 file changed, 4 insert
tps://gitlab.freedesktop.org/drm/amd/-/issues/1500 .
That said, I agree this approach is very aggressive. I think it might be
acceptable with AC power, not sure about on battery though. (There might be
better performance/power profile mechanisms to hook into than AC vs battery)
--
Earthling Miche
ma = (crtc->cm_has_degamma ||
>>>> crtc->cm_is_degamma_srgb);
>>>> + if (has_crtc_cm_degamma){
>>>> + /* AMD HW doesn't have post-blending degamma caps. When DRM
>>>> + * CRTC atomic degamma is set, we maps it to DPP degamma block
>>>> + * (pre-blending) or, on legacy gamma, we use DPP degamma to
>>>> + * linearize (implicit degamma) from sRGB/BT709 according to
>>>> + * the input space.
>>>
>>> Uhh, you can't just move degamma before blending if KMS userspace
>>> wants it after blending. That would be incorrect behaviour. If you
>>> can't implement it correctly, reject it.
>>>
>>> I hope that magical unexpected linearization is not done with atomic,
>>> either.
>>>
>>> Or maybe this is all a lost cause, and only the new color-op pipeline
>>> UAPI will actually work across drivers.
>>
>> I agree that crtc degamma is an optional property and should be not
>> exposed if not available. I did something in this line for DCE that has
>> no degamma block[1]. Then, AMD DDX driver stopped to advertise atomic
>> API for DCE, that was not correct too[2].
>
> Did AMD go through all the trouble of making their Xorg DDX use KMS
> atomic, even after the kernel took it away from X due to modesetting
> DDX screwing it up?
No, I think Melissa meant the KMS properties for advanced colour transforms,
which xf86-video-amdgpu uses, not with atomic KMS though.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
merge?
One approach for this which has proved effective in Mesa and other projects is
to make warnings fatal in CI which must pass for any changes to be merged.
There is ongoing work toward introducing this for the DRM subsystem, using
gitlab.freedesktop.org CI.
--
Earthling Mich
On 8/21/23 22:02, André Almeida wrote:
> Em 17/08/2023 07:37, Michel Dänzer escreveu:
>> On 8/15/23 20:57, André Almeida wrote:
>>> From: Pekka Paalanen
>>>
>>> Specify how the atomic state is maintained between userspace and
>>> kernel, plus the spe
sults in drmModeAtomicCommit failing and the monitor losing signal
instead.
Simon, how did you determine that the HW cursor contents get rotated according
to the underlying planes?
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 8/17/23 12:37, Michel Dänzer wrote:
> On 8/15/23 20:57, André Almeida wrote:
>> From: Pekka Paalanen
>>
>> Specify how the atomic state is maintained between userspace and
>> kernel, plus the special case for async flips.
>>
>> Signed-off-by: Pekka Pa
effect with VRR: It could trigger scanout of
the next frame before vertical blank has reached its maximum duration. Some
kind of mechanism is required for this in order to allow user space to perform
low frame rate compensation.
--
Earthling Michel Dänzer| https://red
}
>
> + if (new_underlying_state->rotation != new_cursor_state->rotation) {
> + drm_dbg_atomic(crtc->dev, "Cursor plane rotation doesn't match
> underlying plane\n");
> + return -EINVAL;
> + }
> +
> /* In theory we could prob
application as a whole stops working.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 8/9/23 21:15, Marek Olšák wrote:
> 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
n should do its best to keep the application running.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 7/28/23 19:20, Alex Deucher wrote:
> On Fri, Jul 28, 2023 at 1:19 PM Michel Dänzer wrote:
>> On 7/28/23 18:43, Alex Deucher wrote:
>>> On Fri, Jul 28, 2023 at 10:25 AM Michel Dänzer wrote:
>>>> On 7/28/23 11:30, Michel Dänzer wrote:
>>>>&
text stops working. Any threads / other
parts of the process not using that OpenGL context continue working normally.
And any attempts to use that OpenGL context can be safely ignored (or the
OpenGL implementation couldn't support the robustness extensions).
--
Earth
On 7/28/23 18:43, Alex Deucher wrote:
> On Fri, Jul 28, 2023 at 10:25 AM Michel Dänzer wrote:
>> On 7/28/23 11:30, Michel Dänzer wrote:
>>> On 7/28/23 03:38, Zhang, Jesse(Jie) wrote:
>>>>
>>>> Could you try the patch again ? That work for me.
>>
On 7/28/23 11:30, Michel Dänzer wrote:
> On 7/28/23 03:38, Zhang, Jesse(Jie) wrote:
>>
>> Could you try the patch again ? That work for me.
>>
>> https://patchwork.freedesktop.org/patch/549605/
>> <https://patchwork.freedesktop.org/patch/549605/>
>
On 7/14/23 18:52, Michel Dänzer wrote:
> On 7/13/23 21:58, Harry Wentland wrote:
>> After driver init we shouldn't create new properties. Doing so
>> will lead to a warning storm from __drm_mode_object_add.
>>
>> We don't really need to create the property for
fore.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 7/25/23 19:06, Michel Dänzer wrote:
> On 7/24/23 19:52, Philip Yang wrote:
>> start_cpsch map queues when kfd_init_node have race condition with
>> IOMMUv2 init, and cause the gfx ring test failed later. Remove it
>> from start_cpsch because map queues will be done
On 7/25/23 15:02, André Almeida wrote:
> Em 25/07/2023 05:03, Michel Dänzer escreveu:
>> 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
On 7/24/23 19:52, Philip Yang wrote:
> start_cpsch map queues when kfd_init_node have race condition with
> IOMMUv2 init, and cause the gfx ring test failed later. Remove it
> from start_cpsch because map queues will be done when creating queues
> and resume queues.
>
> Reported
On 7/25/23 17:05, Marek Olšák wrote:
> 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
>>> reset
, thanks for the heads up.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
] https://registry.khronos.org/OpenGL/extensions/EXT/EXT_robustness.txt
> [3] https://registry.khronos.org/OpenGL/specs/gl/glspec46.core.pdf
> [4]
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/23.1/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c#L1657
> [5]
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/23.1/src/gallium/drivers/iris/iris_batch.c#L842
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 7/24/23 03:21, Sasha Levin wrote:
> From: Michel Dänzer
>
> [ Upstream commit 8e1b45c578b799510f9a01a9745a737e74f43cb1 ]
>
> This reverts commit 474f01015ffdb74e01c2eb3584a2822c64e7b2be.
The reverted commit is the same as patch 1 in this series...
Same issue with the
On 7/21/23 10:55, Michel Dänzer wrote:
> On 7/20/23 22:48, Philip Yang wrote:
>> On 2023-07-20 06:46, Michel Dänzer wrote:
>>> On 7/17/23 15:09, Michel Dänzer wrote:
>>>> On 5/10/23 23:23, Alex Deucher wrote:
>>>>> From: Philip Yang
>>
On 7/20/23 22:48, Philip Yang wrote:
> On 2023-07-20 06:46, Michel Dänzer wrote:
>> On 7/17/23 15:09, Michel Dänzer wrote:
>>> On 5/10/23 23:23, Alex Deucher wrote:
>>>> From: Philip Yang
>>>>
>>>> Rename smv_migrate_init to a better name kgd2
On 7/17/23 15:09, Michel Dänzer wrote:
> On 5/10/23 23:23, Alex Deucher wrote:
>> From: Philip Yang
>>
>> Rename smv_migrate_init to a better name kgd2kfd_init_zone_device
>> because it setup zone devive pgmap for page migration and keep it in
>> kfd_mig
] *ERROR* IB test failed
on comp_1.3.1 (-110).
[drm:process_one_work] *ERROR* ib ring test failed (-110).
[drm] Downstream port present 1, type 0
fbcon: amdgpudrmfb (fb0) is primary device
Console: switching to colour frame buffer device 192x60
amdgpu :05:00.0: [drm] fb0: amdgpudrmfb fram
s fine.
>
> v2: Add curly braces to avoid possibly 'else' confusion
I'm still hitting WARNINGs with this, see attachment.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
WARNING: CPU: 3 PID: 2
if (!aconnector->mst_root)
|^
I think coding style asks for curly braces around both cases as well.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
nd you asked me to test an EDID quirk
patch, which I reported not to have any effect for my monitor. Then I didn't
hear back anything until this patch series today, so I haven't tested the
de1da2f7fe25 commit. (I expect it to work, but I can't confirm it yet)
--
Earthlin
the
referenced commit?
(Also a bit surprised to learn about that one only now, and that it landed
without my confirming it actually works)
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
hat first page-flip is not
>> + * asynchronous.
>
> What would happen if one commits another async KMS update before the
> first page flip? Does one receive EAGAIN, does it amend the previous
> commit?
Should be the former. DRM_MODE_PAGE_FLIP_ASYNC just means t
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 6/30/23 22:32, Marek Olšák wrote:
> > > On Fri, Jun 30,
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 AM Michel Dänzer
> mailto:michel.daen...@mailbox.org>
> <
On 6/30/23 22:32, Marek Olšák wrote:
> On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer <mailto:michel.daen...@mailbox.org>> wrote:
>> On 6/30/23 16:59, Alex Deucher wrote:
>>> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick
>>> mailto:sebastian.w...@redhat.co
ing any unsaved work, whereas at least some applications might
otherwise allow saving the work by other means.
[0] Possibly accompanied by a one-time message to stderr along the lines of
"GPU reset detected but robustness not enabled in context, ignoring OpenGL API
calls".
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
'm attaching the EDID.
BTW, I'm using the monitor firmware version 1011.0, which AFAICT is the latest.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
edid
Description: Binary data
ant see your issue.
>
> Unfortunately, having the patches in question reverted causes hangs with 3
> monitor setups. So I will push that monitor specific quirk and bring back the
> reverted patches.
Sounds good, thanks.
--
Earthling Michel Dänzer| htt
On 6/7/23 19:35, Pillai, Aurabindo wrote:
>
> Do you see the issue if you force disable FAMS?
Neither hang occurs with FAMS disabled.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
g/dri/0/amdgpu_dm_dmub_tracebuffer
Both files attached.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
trace_code=14 tick_count=803999866 param0=278 param1=385593
trace_code=1 tick_count=36719773
static const u16 amdgpu_unsupported_pciidlist[] = {
> 0x5874,
> 0x5940,
> 0x5941,
> + 0x5b70,
> 0x5b72,
> 0x5b73,
> 0x5b74,
Reviewed-by: Michel Dänzer
Tested-by: Michel Dänzer
Thanks!
--
Earthling Michel Dänzer
h
applied and the other two patches reverted.
> We have a set of IGT tests you could try:
Results attached. This is with all 3 problematic patches applied and FreeSync
enabled in the monitor's OSD settings.
--
Earthling Michel Dänzer| https://redhat.co
...@amd.com
> Cc: mic...@daenzer.net
> Signed-off-by: Alex Deucher
The series is
Reviewed-by: Michel Dänzer
Thanks!
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
ers> and install just the open
> components?
I don't, and I'd rather not unless it's absolutely necessary. I'm not sure how
the user-space drivers could affect this.
I'll happily test further patches though.
--
Earthling Michel Dänzer| https://redhat.co
On 5/31/23 22:14, Aurabindo Pillai wrote:
> On 5/11/23 03:06, Michel Dänzer wrote:
>> On 5/10/23 22:54, Aurabindo Pillai wrote:
>>> On 5/10/23 09:20, Michel Dänzer wrote:
>>>> On 5/9/23 23:07, Pillai, Aurabindo wrote:
>>>>>
>>>>&g
On 5/31/23 16:01, Alex Deucher wrote:
> On Mon, May 29, 2023 at 5:45 AM Michel Dänzer wrote:
>>
>> On 4/12/23 03:23, Zhang, Jesse(Jie) wrote:
>>>
>>> Due to raven/raven2 maybe enable sclk slow down,
>>> they cannot get clock count by the RLC
the meantime though, these changes need to be reverted for 6.4, at least for
Picasso.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 5/23/23 18:09, Hamza Mahfooz wrote:
> On 5/22/23 09:08, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> This reverts commit ce560ac40272a5c8b5b68a9d63a75edd9e66aed2.
>>
>> It depends on its parent commit, which we want to revert.
>>
>> Sign
From: Michel Dänzer
This reverts commit ce560ac40272a5c8b5b68a9d63a75edd9e66aed2.
It depends on its parent commit, which we want to revert.
Signed-off-by: Michel Dänzer
---
.../drm/amd/display/dc/dcn20/dcn20_hwseq.c| 3 ---
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 22
From: Michel Dänzer
This reverts commit 474f01015ffdb74e01c2eb3584a2822c64e7b2be.
Caused a regression:
Samsung Odyssey Neo G9, running at 5120x1440@240/VRR, connected to Navi
21 via DisplayPort, blanks and the GPU hangs while starting the Steam
game Assetto Corsa Competizione (via Proton 7.0
#comment_972234
/ 9deeb132-a317-7419-e9da-cbc0a379c...@daenzer.net .
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 5/10/23 22:54, Aurabindo Pillai wrote:
> On 5/10/23 09:20, Michel Dänzer wrote:
>> On 5/9/23 23:07, Pillai, Aurabindo wrote:
>>>
>>> Sorry - the firmware in the previous message is for DCN32. For Navi2x,
>>> please use the firmware attached here.
>>
i, Aurabindo
> *Sent:* Tuesday, May 9, 2023 4:44 PM
> *To:* Michel Dänzer ; Zhuo, Qingqing (Lillian)
> ; amd-gfx@lists.freedesktop.org
> ; Chalmers, Wesley
> *Cc:* Wang,
pu]
__handle_irq_event_percpu+0x46/0x1b0
handle_irq_event+0x34/0x80
handle_edge_irq+0x9f/0x240
__common_interrupt+0x66/0x110
common_interrupt+0x5c/0xd0
asm_common_interrupt+0x22/0x40
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
nic when it hits an Oops (either via CONFIG_PANIC_ON_OOPS at build time, or
via oops=panic on the kernel command line). A kernel panic means that the
machine basically freezes from a user PoV, which would be worse as the default
behaviour for most users (because it would e.g. incur a higher risk of losing
file
at's how they get
>> the best outcome, e.g. no corruption. A soft reset that is unhandled by
>> userspace may result in persistent corruption.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
e robust against fatal resets, but it's taking time. Meanwhile, I
suspect most users would take the > 0 chance.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
ssion for a few days without any issues.
(Interestingly, Firefox reacts to the soft-resets by falling back to software
rendering, even when it's not guilty itself)
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
no shift instead of <<, shouldn't it? Multiplying a value
in bytes by the page size doesn't make sense.
I didn't check the rest of the patch in detail, but it's easy introduce subtle
regressions with this kind of change. It'll require a lot of review & testing
scrutiny.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
t sure which enum value (enum odm_combine_mode)true will be converted to,
probably dm_odm_combine_mode_2to1? Is that really appropriate everywhere true
is used? If so, again
dm_odm_combine_mode_2to1 would seem clearer.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
1 - 100 of 1908 matches
Mail list logo
