[Mesa-dev] [PATCH 00/14] vl dri3 support for vaapi and vdpau
Mike Lothian
mike at fireburn.co.uk
Thu May 12 02:41:37 UTC 2016
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.davy at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160512/8a702703/attachment.html>
More information about the mesa-dev
mailing list