Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation

From: "Stéphane Marchesin" <stephane.marchesin@gmail.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation
Date: Sun, 19 Jul 2015 17:20:32 -0700	[thread overview]
Message-ID: <CACP_E+LDGE7uE0nRJEd3TfxSfF5chHU83_2DRr98k+mYW7ehyw@mail.gmail.com> (raw)
In-Reply-To: <20150717090809.6c9d7d02@gmail.com>

On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Thu, 16 Jul 2015 20:20:39 +0800
> John Hunter <zhjwpku@gmail.com> wrote:
>
> > From: Zhao Junwang <zhjwpku@gmail.com>
> >
> > This supports the asynchronous commits, required for page-flipping
> > Since it's virtual hw it's ok to commit async stuff right away, we
> > never have to wait for vblank.
>
> Hi,
>
> in theory, yes. This is what a patch to bochs implemented not too long
> ago, so AFAIK you are only replicating the existing behaviour.
>
> However, if userspace doing an async commit (or sync, I suppose) does
> not incur any waits in the kernel in e.g. sending the page flip event,
> then flip driven programs (e.g. a Wayland compositor, say, Weston)
> will be running its rendering loop as a busy-loop, because the kernel
> does not throttle it to the (virtual) display refresh rate.
>
> This will cause maximal CPU usage and poor user experience as
> everything else needs to fight for CPU time and event dispatch to get
> through, like input.
>
> I would hope someone could do a follow-up to implement a refresh cycle
> emulation based on a clock. Userspace expects page flips to happen at
> most at refresh rate when asking for vblank-synced flips. It's only
> natural for userspace to drive its rendering loop based on the vblank
> cycle.

I've been asking myself the same question (for the UDL driver) and I'm
not sure if this policy should go in the kernel. After all, there
could be legitimate reasons for user space to render lots of frames
per second. It seems to me that if user space doesn't want too many
fps, it should just throttle itself.

Stéphane

>
>
>
> Thanks,
> pq
>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Zhao Junwang <zhjwpku@gmail.com>
> > ---
> >  drivers/gpu/drm/bochs/bochs_mm.c |    9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
> > index c1d819c..37ac2ca 100644
> > --- a/drivers/gpu/drm/bochs/bochs_mm.c
> > +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> > @@ -545,8 +545,15 @@ bochs_user_framebuffer_create(struct drm_device *dev,
> >       return &bochs_fb->base;
> >  }
> >
> > +static int bochs_atomic_commit(struct drm_device *dev,
> > +                          struct drm_atomic_state *a,
> > +                          bool async)
> > +{
> > +     return drm_atomic_helper_commit(dev, a, false);
> > +}
> > +
> >  const struct drm_mode_config_funcs bochs_mode_funcs = {
> >       .fb_create = bochs_user_framebuffer_create,
> >       .atomic_check = drm_atomic_helper_check,
> > -     .atomic_commit = drm_atomic_helper_commit,
> > +     .atomic_commit = bochs_atomic_commit,
> >  };
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel