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