e 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
t 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 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
'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 phase1, phase2, pha
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
eport, 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
gt; --
> 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.
>
&
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
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
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
ean 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 major loss if that wasn't exposed. There just needs to
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|
e 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
ments 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 th
t hitting 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.
--
Earthling Mich
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
>>>>> bl
tups, 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 between
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:
>>>&
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
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 board? After
> how many occurences?
>
> Basically, how can I see that the bug is indeed there (or got fixed
> since), and how to start fixing it?
Many o
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
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
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
VERLAP
> + *
> + *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 series, but my impression
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/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/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
] 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/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
MC (assuming its connector status is connected or unknown).
--
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
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
#comment_972234
/ 9deeb132-a317-7419-e9da-cbc0a379c...@daenzer.net .
--
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
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:
>>&
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
>
>>>>> 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 enough, but it
&
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
tty 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 react accordingly and ab
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
gain, 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.
>>>>
>
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 interrupts w
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 vblank events while in PSR (there might be some
infra
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:
>>
dc->caps.vbios_lttpr_aware;
>
> if (!vbios_lttpr_interop ||
> !link->dc->caps.extended_aux_timeout_support)
> - return false;
> + return DC_OK;
return status;
seems more appropriate. (Otherwise the status = DC_ERROR_UNEXPEC
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.
>>&
ve 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
amdgpu_cs_parser_bos(struct amdgpu_cs_parser
> *p,
> }
> mutex_unlock(>bo_list->bo_list_mutex);
> }
> + mutex_unlock(>bo_list->bo_list_mutex);
> return r;
> }
>
Looks doubtful that this is a correct backport
(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
t; 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.
--
Earthling Michel
e_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
k that
I happened to notice it fly by.
> On 2022-09-15 04:55, Michel Dänzer wrote:
>> On 2022-09-14 22:08, Alex Hung wrote:
>>> On 2022-09-14 10:55, Michel Dänzer wrote:
>>>> On 2022-09-14 18:30, Alex Hung wrote:
>>>>> On 2022-09-14 07:40, Michel Dänzer
flip while another one is still pending.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
as long as possible
for minimal latency).
>> For legacy, it seems like drivers do what they want. AFAIU, i915 will reject
>> (see intel_async_flip_check_uapi etc), and amdgpu will silently fall back to
>> vsync (see the `acrtc_state->update_type == U
er-dependent
jobs at once, and they would all run before any jobs from another queue get a
chance.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
libdrm changes are now reviewed and merged as GitLab merge requests:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
>
> XRGB1555 and RGB565 are probably the only RGB formats we care about.
> Or perhaps some of the *30 formats?
I'd say all of those, and any other formats with components straddling byte
boundaries (including formats with multi-byte components).
P.S. libdrm changes are now rev
1 - 100 of 2012 matches
Mail list logo
