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

[Andy Furniss]

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.

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

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.