[Mesa-dev] [PATCH 00/14] vl dri3 support for vaapi and vdpau

Leo Liu leo.liu at amd.com
Wed May 11 16:30:39 UTC 2016


Hi Axel,

Thanks for the comments. Inlines.

On 05/11/2016 11:57 AM, Axel Davy wrote:
> Hi,
>
> Do you have some local branch to review all at once (it is a bit hard 
> to follow with the patches) ?

The sequences of patches are based on existing vl/dri required 
functions, also follows vaapi and then vdpau.
I don't have local branch, but I am going to attach vl_winsys_dri3.c 
file, that might be easier.

>
> From a quick looks, it seems you inspired from the loader dri3 code.
>

That is quite inspiring. I do learn a lot from loader dri3 code. I 
should honor it in the commit message. Thanks.

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

I am using Tonga as well for the development, I haven't hit this, but 
definitely that's something to be considered, I will try more video clips.

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

Like said, definitely keep this in mind. File attached.

Thanks,
Leo

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vl_winsys_dri3.c
Type: text/x-csrc
Size: 19955 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160511/9d56bd97/attachment-0001.c>


More information about the mesa-dev mailing list