Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi On Fri, Oct 13, 2023 at 5:41 AM Daniel Vetter wrote: > > I mean we're not talking about scientific computing, or code > > compilation, or seti@home. We're talking about nearly the equivalent > > of `while (1) __asm__ ("nop");` > > I don't think anyone said this shouldn't be fixed or improved.

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi, On Mon, Oct 09, 2023 at 02:36:17PM +0200, Christian König wrote: > > > > To be clear, my take is, if driver code is running in process context > > > > and needs to wait for periods of time on the order of or in excess of > > > > a typical process time slice it should be sleeping during the

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi, On Fri, Oct 6, 2023 at 3:12 AM Christian König wrote: > When the operation busy waits then that *should* get accounted to the > CPU time of the current process. When the operation sleeps and waits for > some interrupt for example it should not get accounted. > What you suggest is to put the

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi, On Thu, Oct 5, 2023 at 5:57 AM Daniel Vetter wrote: > So imo the trouble with this is that we suddenly start to make > realtime/cpu usage guarantees in the atomic ioctl. That's a _huge_ uapi > change, because even limited to the case of !ALLOW_MODESET we do best > effort guarantees at best.

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi, On Wed, Oct 4, 2023 at 1:28 PM Ville Syrjälä wrote: > No one really seemed all that interested in it. I'd still like to get > it in, if for no other reason than to make things operate more uniformly. > Though there are lots of legacy codepaths left that still hold the locks > over the whole

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

hI, On Thu, Sep 28, 2023 at 11:05 AM Ville Syrjälä wrote: > Here's my earlier take on this: > https://patchwork.freedesktop.org/series/108668/ Nice. Was there push back? Why didn't it go in? > execpt I went further and moved the flush past the unlock in the end. Is that necessary? I was

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi, On Thu, Sep 28, 2023 at 9:24 AM Christian König wrote: > If you see a large delay in the dpms off case then we probably have a driver > bug somewhere. This is something we both agree on, I think. >> I'm getting the idea that you think there is some big bucket of kernel >> syscalls that

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

hi, 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 > >>> blocking commit plus a dma_fence to wait for the work to end from > >>> userspace. > >>

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi, On Thu, Sep 28, 2023 at 2:56 AM Christian König wrote: > > To say the "whole point" is about CPU overhead accounting sounds > > rather absurd to me. Is that really what you meant? > > Yes, absolutely. See the functionality you try to implement already exists. You say lower in this same

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

Hi, On Wed, Sep 27, 2023 at 4:05 AM Christian König wrote: > I'm not an expert for that stuff, but as far as I know the whole purpose > of the blocking functionality is to make sure that the CPU overhead > caused by the commit is accounted to the right process. I'm not an expert either, but

[PATCH] drm/atomic: Perform blocking commits on workqueue

From: Ray Strode A drm atomic commit can be quite slow on some hardware. It can lead to a lengthy queue of commands that need to get processed and waited on before control can go back to user space. If user space is a real-time thread, that delay can have severe consequences, leading

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

Hi, On Wed, Dec 20, 2017 at 11:44 AM Max Staudt wrote: > It'd be nice to see this bug fixed, as it happens only occasionally (as is > the nature of a > race condition), and was thus really hard to debug. I'm sure it can drive > people insane, > as they try to find out whether

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Hi, > Actually, I don't want that :) > > This was a design decision that I've made to keep the code small and simple > to audit. > As it is, the simple bootsplash code will make 99% of people happy. You think only 1% of linux users have more than one monitor or a 4k screen? > I've made this

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

Hi, > The problem that I am stumbling upon is different: > - the system starts with an FB driver > - after the ShowDelay time, Plymouth opens /dev/fb0 > - the system finally loads the DRM driver, which tries to kick the previous > FB driver > - loading the DRM driver fails because Plymouth

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Hi, On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote: > I'm hooking into the in-kernel terminal emulator, because the bootsplash is a > functional extension of that. It just happens that fbcon sits on top of FB, > so I > work with what I get. > > And the console in turn

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

Hi, > For example, having a userspace splash that starts as early as it can > (thus on vesafb/efifb on a PC) will cause the KMS driver to fail > reserving the entirety of video RAM, and thus fail loading. This cannot be > fixed. well the fix there is to use drm devices... like this:

[PATCH v2 0/2] qxl cursor fixes

From: Ray Strode <rstr...@redhat.com> This series includes a small leak fix and a fix for an initial invisible cursor on wayland sessions. Ray Strode (2): drm/qxl: unref cursor bo when finished with it drm/qxl: reapply cursor after resetting primary drivers/gpu/drm/qxl/qxl_display.

[PATCH 1/2] drm/qxl: unref cursor bo when finished with it

From: Ray Strode <rstr...@redhat.com> qxl_cursor_atomic_update allocs a bo for the cursor that it never frees up at the end of the function. This commit fixes that. Signed-off-by: Ray Strode <rstr...@redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 4 +++- 1 file changed, 3 inse

[PATCH 2/2] drm/qxl: reapply cursor after resetting primary

From: Ray Strode <rstr...@redhat.com> QXL associates mouse state with its primary plane. Destroying a primary plane and putting a new one in place has the side effect of destroying the cursor as well. This commit changes the driver to reapply the cursor any time a new primary is c

Re: [PATCH] drm/qxl: reapply cursor after resetting primary

Hi, On Mon, Nov 27, 2017 at 4:07 PM Ray Strode <halfl...@gmail.com> wrote: ... > This commit changes the driver to reapply the cursor any time a new > primary is created. It achieves this by keeping a reference to the > cursor bo on the qxl_crtc struct. So i forgot this is on top

[PATCH] drm/qxl: reapply cursor after resetting primary

From: Ray Strode <rstr...@redhat.com> QXL associates mouse state with its primary plane. Destroying a primary plane and putting a new one in place has the side effect of destroying the cursor as well. This commit changes the driver to reapply the cursor any time a new primary is c

[PATCH] drm/qxl: reapply cursor after SetCrtc calls

From: Ray Strode <rstr...@redhat.com> The qxl driver currently destroys and recreates the qxl "primary" any time the first crtc is set. A side-effect of destroying the primary is mouse state associated with the crtc is lost, which leads to disappearing mouse cursors on