[Mesa-dev] [PATCH 1/9] st/va: make the implementation thread save
adf.lists at gmail.com
Mon Dec 21 02:05:37 PST 2015
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
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.
More information about the mesa-dev