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. >>> 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.) _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
