[FFmpeg-devel] Patch: Enable OpenCL with Win32 threads

[Matt Oliver]

On 16 April 2014 13:00, Matt Oliver <protogonoi at gmail.com> wrote:

> I don't know which version you used, but pthreads-w32 seems to work
>>  just fine for MSVC for me, I'm using it with VS2013 successfully, and
>> ffmpeg didn't change a bit in speed when changing between it and
>> native.
>
>
> pthreads-w32 for me to, but I use it with icl. Claiming performance
> difference on my part was probably a bit mean as FFmpeg only does some
> basic thread creation and locking so its nowhere near complicated enough to
> notice a real difference. I have used pthreads on other massively complex
> threaded projects and had serious issues with it and once you scale up it
> does slow things down. I know a few people who just wont touch it as a
> result, hence why I decided to make a w32 alternative. I have nothing
> against posix (it works great on linux) just on Windows I thought native
> could be useful (and also remove a dependency).
>
>
Oh and before things get off track with a pthread for/against discussion I
should point out that the previous patches static initialization uses what
is more correctly called poorly documented as opposed to undocumented
functionality.
For instance Wine uses a similar technique for initialization. The only
difference is that they explicitly create the debugInfo whereas this patch
sets it to -1 (this is default error value for uninitialized and is
supported by default win32 InitializeCriticalSection as it cant return an
error so it returns -1 instead).
For example see (line 136):
http://sourceforge.net/p/wine/code/ci/master/tree/dlls/msvcrt/file.c#l135

The debugInfo isnt really needed hence why I didnt initialise it. However
if the Wine technique is considered more suitable I could do it that way
aswell. Or if the way Wine does it is considered incorrect then I could
just leave it pthreads only.