On Mon, 20 Feb 2017 23:06:21 +0000 Mark Thompson <s...@jkqxz.net> 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. > > Multiple API calls, looping over _all_ libavutil pixfmts... seems to do > > a lot of work for a call you'd expect to be fast and often called. > > Maybe not a problem. > > Often? I'd expect this to be called once in some setup function for each > component and never thereafter unless something changes. Also, nothing in > the loop calls anything external, except possibly realloc for valid formats. > (The opencl_get_plane_format() function is trying to be the one place where > you need to add new formats.) OK, never mind then. > >> + ++pix_fmts_found; > > > > (Don't mind me, just stylistically objecting to pre-decrement.) > > (Well, don't mind me not caring, then.) (OK, but still demonstratively frowning.) > > Can't comment much on the actual code here. > > > > Isn't it a bit strange that we also have hwcontext_cuda, and they don't > > interact at all? > > Someone should add mapping between them... That was just a brainfart of mine confusing those APIs (which I always do, I'll just blame nVidia). > > 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.) _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
