On Tue, 21 Feb 2017 13:18:55 +0000 Mark Thompson <[email protected]> wrote:
> On 21/02/17 08:00, wm4 wrote: > > On Mon, 20 Feb 2017 23:06:21 +0000 > > Mark Thompson <[email protected]> wrote: > > > >>>> +#ifdef CL_ABGR > >>>> + if (0) > >>> > >>> wut > >> > >> CL_ABGR didn't exist in OpenCL 1.2, which is really the target. It's > >> present in later versions, though, so it's included here if possible for > >> symmetry. > > > > I meant what do the "if (0)"s do here? They're highly confusing at > > best. > > Avoiding more gotos? This function should really be a table, but it's just > tricky enough to make that annoying. I'll see if I can improve it. Yeah, I think that would be better. Also you could say you're using switch-case as some sort of computed goto, which it really is, but ugly and hard to read. > >>> Those complex command queue operations might need a lock around them to > >>> make them thread-safe. (I sure as hell don't want to need fragile > >>> external locking around this API just because I might do > >>> decoding/filtering/rendering on different threads to some degree.) > >> > >> OpenCL is meant to be thread-safe throughout - I don't think there is > >> anything more to do? (Assuming correctness of drivers, of course.) > >> > >> There may be surprises wrt ordering/blocking if you let everything operate > >> on the same command queue, but that is why the user-supplied command > >> queues exist. > > > > I don't know much about OpenCL thread-safety (which is why I'm > > inquiring). But the command queue that's used here is per hw device, so > > it's widely shared. > > > > Is it possible that multiple threads call av_hwframe_transfer_data() > > concurrently? (Of course only as long as there are no conflicting write > > accessed.) > > Yes, this is possible and fully allowed - all of the relevant OpenCL APIs are > explicitly thread-safe. > > > From OpenCL 1.2: > > (Section 2) > """ > Thread-safe: An OpenCL API call is considered to be thread-safe if the > internal state as > managed by OpenCL remains consistent when called simultaneously by multiple > host threads. > OpenCL API calls that are thread-safe allow an application to call these > functions in multiple > host threads without having to implement mutual exclusion across these host > threads i.e. they are > also re-entrant-safe. > """ > > (Appendix A) > """ > All OpenCL API calls are thread-safe except clSetKernelArg. clSetKernelArg is > safe to call > from any host thread, and is safe to call re-entrantly so long as concurrent > calls operate on > different cl_kernel objects. However, the behavior of the cl_kernel object is > undefined if > clSetKernelArg is called from multiple host threads on the same cl_kernel > object at the same > time. Please note that there are additional limitations as to which OpenCL > APIs may be called > from OpenCL callback functions -- please see section 5.9. > """ > > (We don't do anything with event callbacks, and any user who does must be > aware of any possible issues themselves.) OK, that's awesome. Sorry for making you dig out the OpenCL spec. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
