Composite redraw speedup?

[Carsten Haitzler]

On Thu, 13 Feb 2020 02:01:58 +0500 "Alexander E. Patrakov" <patrakov at gmail.com>
said:

> On Thu, Feb 13, 2020 at 1:12 AM Carsten Haitzler <raster at rasterman.com> wrote:
> >
> > On Wed, 12 Feb 2020 16:45:50 +0100 Michel Dänzer <michel at daenzer.net> said:
> >
> > > On 2020-02-12 4:34 p.m., Carsten Haitzler wrote:
> > > > On Wed, 12 Feb 2020 15:36:06 +0100 Michel Dänzer <michel at daenzer.net>
> > > > said:
> > > >
> > > >> On 2020-02-12 2:06 p.m., Carsten Haitzler wrote:
> > > >>> On Wed, 12 Feb 2020 13:23:28 +0200 Pekka Paalanen
> > > >>> <ppaalanen at gmail.com> said:
> > > >>>
> > > >>>> On Wed, 12 Feb 2020 11:07:56 +0000
> > > >>>> Carsten Haitzler <raster at rasterman.com> wrote:
> > > >>>>
> > > >>>>> On Wed, 12 Feb 2020 12:40:15 +0200 Pekka Paalanen
> > > >>>>> <ppaalanen at gmail.com> said:
> > > >>>>>
> > > >>>>>> On Wed, 12 Feb 2020 10:21:02 +0000
> > > >>>>>> Carsten Haitzler (The Rasterman) <raster at rasterman.com> wrote:
> > > >>>>>>
> > > >>>>>>> even better - if the /dev/dri/card0
> > > >>>>>>> device exists, dlopen libdrm and get some symbols from it and ...
> > > >>>>>>> use it to request the drm device sent you vsync events so you can
> > > >>>>>>> use the vsync interrupt as your frame event. this will be another
> > > >>>>>>> fd to listen on in select() and of course you can turn this
> > > >>>>>>> vblank event stream on and off.
> > > >>>>>>
> > > >>>>>> Please don't. Talk to the X server instead.
> > > >>>>>
> > > >>>>> and what vsync events does the xserver provide?
> > > >>>>
> > > >>>> You don't want vsync events. You have no idea what they
> > > >>>> correspond to, or even if you opened the right device.
> > > >>>>
> > > >>>> https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/presentproto.txt
> > > >>>
> > > >>> I wrote the drm support before the present extension existed. The drm
> > > >>> path is  easy to support - only open if a single card exists (if
> > > >>> multiple
> > > >>> - don't do it and fall back to timer based animation) and you can
> > > >>> filter for multiple screens as you get events for all screens. Yes -
> > > >>> you end up syncing with a single chosen screen if you filter for just
> > > >>> one of the vblank events, but it's better than using the system clock.
> > > >>
> > > >> You only get an event for the CRTC you ask for in the
> > > >> DRM_IOCTL_WAIT_VBLANK ioctl. How do yo know which CRTC to pick?
> > > >
> > > > drmVBlank vbl;
> > > > vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
> > > > vbl.request.sequence = 1;
> > > > vbl.request.signal = 0;
> > > > drmWaitVBlank(drm_fd, &vbl);
> > > >
> > > > has worked a charm for maybe give or take close to a decade (as i said -
> > > > before present existed).
> > >
> > > That selects the first CRTC. It'll work most of the time, except when
> > > the first CRTC isn't enabled for some reason.
> >
> > I've seen it select multiple crtc's as I get multiple vblank events with the
> > same frame number... (thus filter out the dups to only get one).
> >
> > > >>> I have found x present XPresentNotifyMSC() to be unreliable where the
> > > >>> drm back-door above is far more reliable. For example - on my amdgpu
> > > >>> driver here it just refuses to produce any events (yes - extension is
> > > >>> there), [...]
> > > >>
> > > >> I haven't seen any such reports, so I'm not aware of such issues with
> > > >> xf86-video-amdgpu.
> > > >
> > > > i'm staring at it not working :) admittedly it's a slightly older rx550
> > > > with amdgpu on an aarch64 host... :) i did play with xpresent in the
> > > > early days it came out and found it to be iffy and stuck to the
> > > > solution we already had (above) which is more reliable.
> > >
> > > A proper issue report with all the needed information will be needed to
> > > do anything about this.
> >
> > It hasn't been something I've needed to do as I have the other method above
> > and no xpresent one to have to support and make work :)
> >
> > > To be clear, even the Present extension is really too low level to be
> > > used directly for this by a compositor (unless it also uses it directly
> > > for the actual presentation). The DRM vblank ioctl even more so, it's
> > > for the display server.
> > >
> > > A compositor which uses GLX/EGL for presentation should use
> > > corresponding GLX/EGL (extension) APIs for this.
> >
> > Aaaah therein lies the rub. I need this to work with our without EGL/GLX. I
> > need it work for compositors and clients - the whole shebang as the same
> > library, infra etc. is used on both sides. There already is an "animator"
> > infra where you request a callback to be called whenever a frame needs to be
> > produced. The idea is that you just modify objects in the scene graph and
> > this then percolates down to there being changes that then results in a
> > render that may or may not use GL. at once point I had an xrender engine I
> > gave up on so i'm down to just software and GL (GLX or EGL and mostly a
> > gles2 susbset of GL). The animation is far removed from the rendering. In
> > the end the pipeline depends on their being some event to say "wake-up!
> > time to render!". The vblank events are just that. That means there is an
> > entire frame worth of budget to go set up the changes, render them and get
> > a swap or xshmputimage queued up and ready to go. The GL infra for this is
> > certainly not ideal and in most cases just hasn't been able to do this in
> > my experience in the past. I need this event even though I have not
> > actually rendered anything previously.
> 
> Please also consider the corner case of Xvfb, xf86-video-dummy, or
> maybe (untested) rendering on a headless GPU on a EC2 instance and
> displaying the result via VNC. In these cases, there will be no vblank
> events at all.

I know. That's why there is also a timeout if code has asked for vblank
interrupts and none come in within that timeout - it'll hiccup a bit then
switch over to timer based ticking, so it works regardless. 

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com