[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