Composite redraw speedup?

[Michel Dänzer]

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


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.


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