Hi Axel Is the thread_submit=true only for nine or does it work with all of DRI3?
I'm keen to get rid of the tearing on my Skylake/Tonga setup Thanks Mike On Wed, 11 May 2016 at 16:57 Axel Davy <axel.d...@ens.fr> wrote: > Hi, > > Do you have some local branch to review all at once (it is a bit hard to > follow with the patches) ? > > From a quick looks, it seems you inspired from the loader dri3 code. > > There is also another implementation you can inspire from: > https://github.com/iXit/wine/blob/master/dlls/d3d9-nine/dri3.c > Probably not much more you can get from it. > > I haven't checked the code yet, so I don't know if that applies, > something I have noticed on my tonga with games, is that (non-vsynced) > apps that get around 45 fps fell like 15 fps (above 50 or below 35 is > fine). > I guess this is due to the fact the screen buffer swap waits the buffer > has finished rendering to execute the swap, and some bad timing when > hitting 45 fps. > In fact for this specific case with gallium nine, I noticed the problem > disappear when using thread_submit=true. > thread_submit is an option that was designed for DRI_PRIME case in mind: > the driver spawns a thread that will wait the buffers we want to present > are finished rendering before sending them. That solves all the sync > issues a DRI_PRIME configuration can have. > I think in the case of the problem described, sending buffers that are > finished rendering prevents the screen buffer swap to have to wait > another vblank the buffer is rendered. > > I guess for video, you really don't want to hit the bad scenario > described. I'm not sure if you can possibly have the issue or not, but > that may be something to consider. In all cases, that seems a good thing > to look at if wanting to implement a good DRI_PRIME support, granting it > is possible: I don't know the user API, but if the user has guarantee > for example the updated content will be copied to some pixmap after some > call, you cannot delay the presentation for that case. > > Axel > > > On 11/05/2016 17:06, Leo Liu wrote : > > This series implement DRI3 supports for VA-API and VDPAU. It implements > > supports for DRI3 Open, PixmapFromBuffer, BufferFromPixmap, and for > > PRESENT including PresentPixmap, PresentNotifyMSC, PresentIdleNotify, > > PresentConfigureNotify and PresentCompleteNotify. > > > > It has been tested with player mpv and vlc with various clips from > > 480p to 4K with framerate from 24 to 60. Also includes window mode > > and fullscreen w/wo compositing manager. The test also includes VA-API > > glx extension. > > > > There's still some future work like DRI_PRIME different GPU support > > to be added. > > > > Leo Liu (14): > > vl: add DRI3 support infrastructure > > vl/dri3: implement dri3 screen create and destroy > > vl/dri3: set drawable geometry > > vl/dri3: register present events > > vl/dri3: implement flushing for queued events > > vl/dri3: add back buffers support > > vl/dri3: implement function for flush frontbuffer > > vl/dri3: implement funciton for get dirty area > > vl/dri3: add support for resizing > > vl/dri3: implement DRI3 BufferFromPixmap > > st/va: add dri3 support > > vl/dri3: handle PresentCompleteNotify event > > vl/dri3: implement functions for get and set timestamp > > st/vdpau: add dri3 support > > > > configure.ac | 7 +- > > src/gallium/auxiliary/Makefile.sources | 5 + > > src/gallium/auxiliary/vl/vl_winsys.h | 5 + > > src/gallium/auxiliary/vl/vl_winsys_dri3.c | 703 > ++++++++++++++++++++++++++++++ > > src/gallium/state_trackers/va/context.c | 6 +- > > src/gallium/state_trackers/vdpau/device.c | 6 +- > > 6 files changed, 729 insertions(+), 3 deletions(-) > > create mode 100644 src/gallium/auxiliary/vl/vl_winsys_dri3.c > > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
