Composite redraw speedup?

Carsten Haitzler raster at rasterman.com
Wed Feb 12 17:42:00 UTC 2020


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.

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



More information about the xorg-devel mailing list