Composite redraw speedup?

[Carsten Haitzler]

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).

> > 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.

> -- 
> Earthling Michel Dänzer               |               https://redhat.com
> Libre software enthusiast             |             Mesa and X developer
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel


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