[Mesa-dev] [PATCH 1/9] st/va: make the implementation thread save

[Christian König]

On 21.12.2015 11:05, Andy Furniss wrote:
> Julien Isorce wrote:
>> Hi Christian,
>>
>> I have 2 remarks:
>>
>> 1: I am sure you have the clear answer to the following questions, so
>> maybe add a comment in the commit message: Isn't the thread safety
>> delegated to the application that use vaapi ? like it is designed for
>> many libraries. I tried to find answer in vaapi-intel-driver and
>> libva but it is not obvious. I'll try the mailing list. For vdpau you
>> are right: "All VDPAU functionality is fully thread-safe; any number
>> of threads may call into any VDPAU functions at any time. VDPAU may
>> not be called from signal-handlers." I could not find something
>> equivalent for vaapi but I guess it would make sense if it was the
>> same.
>
> Oh, interesting as ffmpeg recently decided hwdec should be forced to
> single thread for some reason. It hurts perf for using ffmpeg cli.

Well I had to add this because of the simple reason MPV failed miserable 
in some circumstances because it assumed that VA-API is thread safe.

And yes Julien your suspicion is right that VA-API simply doesn't define 
this properly like VDPAU does.

>
>> 2: Sometimes lock/unlock is just surrounding the "get". Shouldn't the
>> mutex be kept locked until the function is done accessing the
>> resources returned by this "get". (if it was refcounted you would not
>> unref before you continue to access it) (Also I cannot see any
>> lock/unlock in vlVaQueryVideoProcPipelineCaps)
>
> On vaapi - well I can lock mt h/w with gstreamer - but then that may
> just be my setup or an amd thing.
>
> Slightly unrelated question = with vaapi using mpeg2 do you get the same
> result as vdpau or s/w?

Well MPEG2 actually defines that the resulting image doesn't need to be 
100% bit identical on all decoders. H.264 and others are way more strict 
regarding this.

Do you also see actually visible artifacts as well?

Regards,
Christian.


>
> I can't get either to be the same md5sum as s/w (I can with h264).
>
> Visually vaapi is noticeably worse than vdpau on my h/w so I wondered
> whether this was a s/w mesa/vl thing rather than h/w specific and
> whether you saw it on different h/w.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev