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. 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) Otherwise this patch is: Reviewed-by: Julien Isorce <j.iso...@samsung.com> Tested-by: Julien Isorce <j.iso...@samsung.com> Cheers Julien On 18 December 2015 at 15:08, Emil Velikov <emil.l.veli...@gmail.com> wrote: > Hi Christian, > > I've just sent a few comments/suggestions. With or without the > nitpicks (but the remaining addressed) the series is > Reviewed-by: Emil Velikov <emil.l.veli...@gmail.com> > > Thanks > Emil > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
