Composite redraw speedup?

[Carsten Haitzler]

On Thu, 13 Feb 2020 09:11:36 +0100 Michel Dänzer <michel at daenzer.net> said:

> On 2020-02-12 6:42 p.m., Carsten Haitzler 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).
> 
> Sounds like something's wrong.

Well... maybe, but I've seen it and I've had to put in filters to skip
duplicate frame events because of this. I am not seeing it here now so maybe
it was fixed, or maybe it was on another driver stack or both. :)

> Try setting vbl.request.signal to a unique (e.g. monotonically
> increasing) value for each drmWaitVBlank call. The value is replicated
> in the user_data field of the corresponding event. If you get multiple
> events with the same user_data value, that indicates a kernel bug.

I'd have to find a place where it happens first - I don't see it right now. It
may have been a bug like 8-10 years ago or so when I implemented this vsync
animation support and so I had to work with what I saw. Just keep in mind that
this code is rather long lived by now and still works well/reliably today which
is great for me. It was a bit of whack-a-bug at the time. :)

> -- 
> Earthling Michel Dänzer               |               https://redhat.com
> Libre software enthusiast             |             Mesa and X developer
> 


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