driver or bios has resized the PCI BAR, then
> the CPU can access the entire BAR, but if not you are generally
> limited to the first 256M of framebuffer.
FWIW, it's also possible to access all of VRAM via MMIO indirect registers.
That'll be slower than a direct CPU map, it might be
On 2024-09-13 19:28, Rob Clark wrote:
> On Fri, Sep 13, 2024 at 10:03 AM Michel Dänzer
> wrote:
>>
>> On 2024-09-13 18:53, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> Fixes a race condition reported here:
>>> https://github.com/AsahiLinu
can_queue(sched, entity))
> - drm_sched_run_job_queue(sched);
> + drm_sched_run_job_queue(sched);
> }
>
> /**
The entity parameter is unused now.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
#x27;s a WIP MR though:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2660)
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
implicit and explicit sync is gross, and I want the pain that is implicit
> sync to just go away forever. :-)
It can never go away, at least not in the drivers which have ever supported it.
We can never break compatibility.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa dev
is
> designed for,
> (sharing Qemu Guest FB with Host for GPU DMA), udmabufs are not created very
> frequently. And, I think providing CPU access via mmap is just a backup,
> mainly
> intended for debugging purposes.
FYI, Mesa now uses udmabuf for supporting dma-bufs with so
it's the same device driver connection (or in kernel speak underlying
> struct file) then you can optimize away importing and exporting of buffers
> for example.
It's not just about optimization. Mesa needs to know this for correct tracking
of GEM handles. If it guesses incorrectly, there can be misbehaviour.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
>
> 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
d be missing a lot of the point / benefit of CI.
A CI system which is separate from the kernel will tend to be out of sync, so
it can't gate the merging of changes and thus can't prevent regressions from
propagating.
--
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 are not d
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: Michel
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 storage
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
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 t
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_atta
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
waits for all fences to signal 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
;> I can't immediately think of something better, though.
>
> Yeah, I was wondering about that as well. Especially since I wanted to add
> some more flags in the future when for example a bandwidth quota how much
> memory can be moved in/out is exceeded.
>
> Something like
is issue was detected by using the Coccinelle software.
Either that's inaccurate then, or you should be able to provide the
corresponding output from Coccinelle.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
lle report, I'll assume that it didn't
actually call for this change.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
;
> }
> --
> 2.43.0
>
This change is pointless at best, kfree(NULL) works fine.
Out of curiosity, what exactly did Coccinelle report?
--
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.
>
> Wel
ugging?
>
> 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
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
g any prop = same value as
>> 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
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
l setting, 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
at all would be overkill, since it would mean you can't use the
> preblending
> scaler or tonemapper, and animation isn't necessary for that.
>
> The AMD 3DLUT is another example of a LUT that is slow to update, and it would
> obviously be a
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|
ernel kills its process.
The intended mechanism for this is SIGXCPU, but that can't work if the kernel
is stuck in a busy-loop. Ray's patch seems like one way to avoid that.
That said, as long as SIGXCPU can work as intended with the non-blocking
commits mutter uses for everything except modesets, mutter's workaround of
dropping RT priority for the blocking commits seems acceptable for the time
being.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
ycles
(in other words, energy) for constant amendments of atomic commits, in the hope
that one of them results in good latency.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
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
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/28/23 16:51, Christian König wrote:
> Am 28.09.23 um 15:37 schrieb Michel Dänzer:
>> On 9/28/23 14:59, Ray Strode wrote:
>>> On Thu, Sep 28, 2023 at 5:43 AM Michel Dänzer
>>> wrote:
>>>>>>> When it's really not desirable to account the C
itting it with DPMS off but
just starting a game, so there seem to be at least two separate causes of
exceeding 200ms for an atomic commit in DC)
It's not like GitLab issues get much if any attention by DC developers
though... So Ray tried to come up with some kind of solution.
--
Eart
On 9/28/23 14:59, Ray Strode wrote:
> On Thu, Sep 28, 2023 at 5:43 AM Michel Dänzer
> wrote:
>>>>> When it's really not desirable to account the CPU overhead to the
>>>>> process initiating it then you probably rather want to use an non
>>>>&g
ble to trigger the RLIMIT_RTTIME.
amdgpu DC exceeds 200ms on some setups, see the linked issue.
>> Regardless, this seems like a roundabout way to address a problem that
>> we could just ... fix.
Handling modesets asynchronously does seem desirable in mutter to me. E.g. it
would allow doing modesets in parallel with modesets or other atomic commits on
other GPUs.
> From what I know RLIMIT_RTTIME usually works in units of multiple seconds.
RealtimeKit seems to allow 200ms maximum.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
tate, i) {
> - if (!new_crtc_state->active)
> + if (new_crtc_state && !new_crtc_state->active)
> continue;
>
> ret = drm_crtc_vblank_get(crtc);
I'm not quite seeing the connection be
On 9/13/23 10:14, Jocelyn Falempe wrote:
> On 12/09/2023 17:57, Michel Dänzer wrote:
>> On 9/11/23 10:38, Pekka Paalanen wrote:
>>> On Fri, 8 Sep 2023 17:10:46 +0200
>>> Thomas Zimmermann wrote:
>>>> Am 08.09.23 um 16:41 schrieb Pekka Paalanen:
>>>&
se, that's more of a gut feeling
>>>> than hard data.
Jocelyn, have you measured if the XRGB -> RGB888 conversion copy takes
longer than a straight RGB888 -> RGB888 copy in the kernel?
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 9/11/23 14:51, Maxime Ripard wrote:
> On Mon, Sep 11, 2023 at 02:13:43PM +0200, Michel Dänzer wrote:
>> On 9/11/23 11:34, Maxime Ripard wrote:
>>> On Thu, Sep 07, 2023 at 01:40:02PM +0200, Daniel Stone wrote:
>>>>
>>>> Secondly, we will never be there
nel, I'd like to look into it,
> because it's seriously something that shouldn't fail, ever, the hardware
> isn't involved.
>
> How can I figure out now (or worse, let's say in a year) how to
> reproduce it? What kernel version was affected? With what b
o help for issues like
https://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
+ has_crtc_cm_degamma = (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
rge?
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
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
t the 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
he GL
implementation should do its best to keep the application running.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
AG_CMD_PREVENT_CDM_OVERLAP
> + *
> + *Disallow compute overlapped with this render.
Does this affect only compute from the same context, or also from other
contexts?
(Similar question for DRM_PVR_SUBMIT_JOB_COMPUTE_CMD_PREVENT_ALL_OVERLAP)
P.S. I mostly just skimmed the other patches of the ser
L context 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).
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'
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
>>>
ions/KHR/KHR_robustness.txt
> [2] 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 auto
On 7/13/23 11:09, Thomas Zimmermann wrote:
> Am 13.07.23 um 10:53 schrieb Michel Dänzer:
>> On 7/13/23 10:49, Thomas Zimmermann wrote:
>>> Am 13.07.23 um 10:32 schrieb Michel Dänzer:
>>>> On 7/12/23 17:25, Jocelyn Falempe wrote:
>>>>> On 12/07/2023 17:0
On 7/13/23 10:53, Jocelyn Falempe wrote:
> On 13/07/2023 10:32, Michel Dänzer wrote:
>> On 7/12/23 17:25, Jocelyn Falempe wrote:
>>> On 12/07/2023 17:05, Sui Jingfeng wrote:
>>>> On 2023/7/10 16:07, Jocelyn Falempe wrote:
>>>>
>>>>> O
On 7/13/23 10:49, Thomas Zimmermann wrote:
> Am 13.07.23 um 10:32 schrieb Michel Dänzer:
>> On 7/12/23 17:25, Jocelyn Falempe wrote:
>>> On 12/07/2023 17:05, Sui Jingfeng wrote:
>>>> On 2023/7/10 16:07, Jocelyn Falempe wrote:
>>>>
>>>>> O
non-existing BMC (assuming its connector status is connected or unknown).
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
ugh that 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 me
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.com&g
t() likely
results in losing 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
Note that this involves
some Wayland state management challenges for correct operation in all cases
though.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
ev=1#comment_972234
/ 9deeb132-a317-7419-e9da-cbc0a379c...@daenzer.net .
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
l risk can choose to make the kernel
panic 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
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
pace
components more 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
e GNOME session 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
On 4/11/23 11:10, Geert Uytterhoeven wrote:
> Hi Michel,
>
> On Wed, Apr 5, 2023 at 10:50 AM Michel Dänzer
> wrote:
>> On 4/4/23 14:36, Daniel Vetter wrote:
>>> There's a few reasons the kernel should not spam dmesg on bad
>>> userspace ioctl input:
>
\n",
> - info->fix.id,
> - var->xres_virtual, var->yres_virtual,
> - var->xres, var->yres);
> return -EINVAL;
> }
>
Make it pr_warn_once? 99.9...% of the benefit, without spam.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
k.
>>>>>
>>>>> The driver exposing those details would be quite useful for userspace
>>>>> though, so that it can delay committing updates to late, but not too
>>>>> late. Setting a deadline to be the vblank seems easy eno
his should be >> or 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
;m not 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
t;
>> This is a pretty clear NAK from my side to this approach. The KMD should
>> never mess with an userspace process directly in such a way.
>>
>> Instead use something like this "OpenGL: KMD signals the abortion of
>> submitted commands and the UMD should then
ots menu on each comments has an option to copy that link tag. That
>> also highlights the right comment.
>
> Thanks for the tips! Actually you need to sign in to reveal that 3 dots menu.
The date after the username at the top of each GitLab comment is a clickable
link for
tely unlocks vop->vop_lock again, seems a bit pointless. :)
AFAICT the self_refresh_active case should just return immediately, the out
label would also send any pending atomic commit completion event, which seems
wrong now that the vblank interrupt is left enabled. (I also wonder if
drm_crtc_vblank_off doesn't take care of that already, at least amdgpu doesn't
do this explicitly AFAICT)
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 12/23/22 20:10, Harry Wentland wrote:
> On 12/14/22 04:01, Pekka Paalanen wrote:
>> On Tue, 13 Dec 2022 18:20:59 +0100
>> Michel Dänzer wrote:
>>> On 12/12/22 19:21, Harry Wentland wrote:
>>>> This will let us pass kms_hdr.bpc_switch.
>>>>
>&g
On 1/4/23 03:11, Brian Norris wrote:
> On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
>> On 12/21/22 23:02, Brian Norris wrote:
>
>>> 3. leave vblank enabled even in the presence of PSR
>
> I'm leaning toward this.
If this means vblank interru
display is in self-refresh
>/ there are no new frames or vblanks)
FWIW, a couple more alternatives:
5. Go/stay out of PSR while vblank interrupts are enabled (probably want to
make sure vblankoffdelay is set up such that vblank interrupts are disabled
ASAP)
6. Use fallback timers for vbla
On 12/17/22 13:12, Michel Dänzer wrote:
>
> With the drm-next-2022-12-13 changes for 6.2 merged on top of a 6.1.0 kernel,
> I hit a GPU (Picasso APU) hang in the menu of Trackmania (free-to-play
> Windows game, running via Wine).
It happened again when starting Return to Monkey I
On 12/15/22 10:07, Michel Dänzer wrote:
> On 12/14/22 16:46, Alex Deucher wrote:
>> On Wed, Dec 14, 2022 at 4:01 AM Pekka Paalanen wrote:
>>> On Tue, 13 Dec 2022 18:20:59 +0100
>>> Michel Dänzer wrote:
>>>> On 12/12/22 19:21, Harry Wentland wrote:
>>
_cap(struct dc_link
> *link)
> bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
>
> if (!vbios_lttpr_interop ||
> !link->dc->caps.extended_aux_timeout_support)
> - return false;
> + return DC_OK;
On 12/15/22 18:42, Michel Dänzer wrote:
> On 12/15/22 18:33, Alex Deucher wrote:
>> On Thu, Dec 15, 2022 at 4:17 AM Pekka Paalanen wrote:
>>>
>>> On Wed, 14 Dec 2022 10:46:55 -0500
>>> Alex Deucher wrote:
>>>
>>>> On Wed, Dec 14, 2022 at
On 12/15/22 18:33, Alex Deucher wrote:
> On Thu, Dec 15, 2022 at 4:17 AM Pekka Paalanen wrote:
>>
>> On Wed, 14 Dec 2022 10:46:55 -0500
>> Alex Deucher wrote:
>>
>>> On Wed, Dec 14, 2022 at 4:01 AM Pekka Paalanen wrote:
>>>>
>>>>
On 12/14/22 16:46, Alex Deucher wrote:
> On Wed, Dec 14, 2022 at 4:01 AM Pekka Paalanen wrote:
>> On Tue, 13 Dec 2022 18:20:59 +0100
>> Michel Dänzer wrote:
>>> On 12/12/22 19:21, Harry Wentland wrote:
>>>> This will let us pass kms_hdr.bpc_switch.
>>&
the effective bpc lower than the maximum as needed
to make the rest of the atomic state work.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
t amdgpu_cs_parser_bos(struct amdgpu_cs_parser
> *p,
> }
> mutex_unlock(&p->bo_list->bo_list_mutex);
> }
> + mutex_unlock(&p->bo_list->bo_list_mutex);
> return r;
> }
>
Looks doubtful that this is a corr
(rst & RST_REG) && !(clk & CK_DISABLE))
>> return true;
In particular, it makes no sense in this specific place, since it cannot
directly affect the values of rst & clk.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
with a
> sub-optimal format choice. And it's a pile of code.
In addition to everything you mentioned, converting from XRGB2101010 to
XRGB loses the additional information, defeating the only point of using
XRGB2101010 instead of XRGB in the first place.
--
Ea
create_handle = drm_gem_fb_create_handle,
> + .dirty = drm_atomic_helper_dirtyfb,
> };
>
> uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
This patch has issues, see https://patchwork.freedesktop.org/patch/503749/ .
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
1 - 100 of 1011 matches
Mail list logo
