On Sun, 19 Jul 2015 17:20:32 -0700 Stéphane Marchesin <stephane.marchesin@xxxxxxxxx> wrote: > On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > > On Thu, 16 Jul 2015 20:20:39 +0800 > > John Hunter <zhjwpku@xxxxxxxxx> wrote: > > > > > From: Zhao Junwang <zhjwpku@xxxxxxxxx> > > > > > > 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. If userspace wants to render lots of frames per second, IMO it should not be using vblank-synced operations in a way that may throttle it. The lots of frames use case is already non-working for the majority of the drivers without DRM_MODE_PAGE_FLIP_ASYNC, right? The problem here I see is that one DRM driver decides to work different to other DRM drivers. All real-hardware DRM drivers, when asked to do vblank-synced update, actually do throttle to the vblank AFAIK. Is it too much to assume, that the video mode set in a driver (refresh rate) corresponds to the vblank rate which implicitly delays the completion of vblank-sync'd operations to at least the next vblank boundary? I think, if the driver cannot implement proper semantics (which IMO includes the throttling) for vblank-sync'd operations and it does not want to fake them with a clock, it should just refuse vblank-synced operations. That would push the problem to userspace, and it would be obvious what's going wrong. Naturally, it would break some userspace programs that expect vblank-synced operations to work, but is that so much different to the current unfixed situation? Thanks, pq _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
