On Thu, Feb 13, 2020 at 1:12 AM Carsten Haitzler <ras...@rasterman.com> wrote: > > On Wed, 12 Feb 2020 16:45:50 +0100 Michel Dänzer <mic...@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 <mic...@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 <ppaala...@gmail.com> > > >>> said: > > >>> > > >>>> On Wed, 12 Feb 2020 11:07:56 +0000 > > >>>> Carsten Haitzler <ras...@rasterman.com> wrote: > > >>>> > > >>>>> On Wed, 12 Feb 2020 12:40:15 +0200 Pekka Paalanen > > >>>>> <ppaala...@gmail.com> > > >>>>> said: > > >>>>> > > >>>>>> On Wed, 12 Feb 2020 10:21:02 +0000 > > >>>>>> Carsten Haitzler (The Rasterman) <ras...@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. -- Alexander E. Patrakov _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel