Log in

View Full Version : OpenCL version for x264? (64-bit)


asarian
27th April 2016, 21:19
How do I get x264 (64-bit) to use the OpenCL DLL version that came with my NVIDIA card?! I have the following on my system (see below); but Microsoft is extremely aggressive towards changing them (it will just tell you your system is corrupted), so, simply overwriting them is an issue.


Volume in drive C is Win 10
Volume Serial Number is E822-318A

Directory of C:\Program Files\NVIDIA Corporation\OpenCL

22-Mar-16 06:08 201,664 OpenCL.dll
1 File(s) 201,664 bytes

Directory of C:\Users\User\Downloads\KNLMeansCL-v0.7.6\Windows\System32

25-Jan-15 13:20 80,384 OpenCL.dll
1 File(s) 80,384 bytes

Directory of C:\Users\User\Downloads\KNLMeansCL-v0.7.6\Windows\SysWOW64

25-Jan-15 13:18 70,144 OpenCL.dll
1 File(s) 70,144 bytes

Directory of C:\Windows\System32

25-Jan-15 13:20 80,384 OpenCL.dll
1 File(s) 80,384 bytes

Directory of C:\Windows\System32\DriverStore\FileRepository\rdvgwddmdx11.inf_amd64_c43edca0d0f250bb

30-Oct-15 11:07 34,816 opencl.dll
1 File(s) 34,816 bytes

Directory of C:\Windows\SysWOW64

30-Oct-15 11:07 27,136 opencl.dll
1 File(s) 27,136 bytes

Directory of C:\Windows\WinSxS\amd64_rdvgwddmdx11.inf_31bf3856ad364e35_10.0.10586.0_none_5fcf2a87752df0d7

30-Oct-15 11:07 34,816 opencl.dll
1 File(s) 34,816 bytes

Directory of C:\Windows\WinSxS\wow64_microsoft-windows-r..xwddmdriver-wow64-c_31bf3856ad364e35_10.0.10586.0_none_3dae054b56911c22

30-Oct-15 11:07 27,136 opencl.dll
1 File(s) 27,136 bytes

Total Files Listed:
8 File(s) 556,480 bytes
0 Dir(s) 95,011,758,080 bytes free

LoRd_MuldeR
27th April 2016, 21:31
Just put the "opencl.dll" that you want x264 to load into the same directory as the x264.exe program. This works, because DLL files in program directory have precedence over DLL files in System directory ;)

See also:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx#standard_search_order_for_desktop_applications

Of course 64-Bit x264 can only use 64-Bit DLL, and 32-Bit x264 can only use 32-Bit DLL. So, if you put a custom "opencl.dll" in x264 program directory, be sure to pick the correct one!

Also: When you install the graphics driver, it will place the proper "opencl.dll" file into "c:\Windows\SysWOW64" (32-Bit) and "c:\Windows\System32" (64-Bit), so all application will use that DLL by default. Normally no need to change this :confused:

asarian
27th April 2016, 21:43
^^ Thank you kindly! :)

Groucho2004
27th April 2016, 21:55
Also: When you install the graphics driver, it will place the proper "opencl.dll" file into "c:\Windows\SysWOW64" (32-Bit) and "c:\Windows\System32" (64-Bit), so all application will use that DLL by default. Normally no need to change this :confused:
If only...
I had to copy the Nvidia OpenCL.dll from "%ProgramFiles%\NVIDIA Corporation\OpenCL" to the system directory manually with my last driver update, the installer would not overwrite the existing file. Apparently, this only happens with some driver versions.

asarian
27th April 2016, 22:16
If only...
I had to copy the Nvidia OpenCL.dll from "%ProgramFiles%\NVIDIA Corporation\OpenCL" to the system directory manually with my last driver update, the installer would not overwrite the existing file. Apparently, this only happens with some driver versions.


The problem appears to be that MS reports your OpenCL.dll as corrupted when you start overwriting to default (Win) locations. This thread sheds some light on this:

SFC /SCANNOW report opencl.dll bad (http://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install/sfc-scannow-report-opencldll-bad/4209b042-1b7b-4fa2-a720-2c0e489d137b?auth=1)

Groucho2004
27th April 2016, 22:19
The problem appears to be that MS reports your OpenCL.dll as corrupted when you start overwriting to default (Win) locations. This thread sheds some light on this:

SFC /SCANNOW report opencl.dll bad (http://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install/sfc-scannow-report-opencldll-bad/4209b042-1b7b-4fa2-a720-2c0e489d137b?auth=1)
I highly doubt that this applies to XP32.

asarian
27th April 2016, 22:20
I highly doubt that this applies to XP32.

Probably not, no. :) But it does apply to Windows 10.

LoRd_MuldeR
27th April 2016, 22:30
I highly doubt that this applies to XP32.

Nope, instead WFP (https://en.wikipedia.org/wiki/Windows_File_Protection) will probably just silently restore the original file after a few seconds.

asarian
27th April 2016, 22:47
Just put the "opencl.dll" that you want x264 to load into the same directory as the x264.exe program. This works, because DLL files in program directory have precedence over DLL files in System directory ;)

Only, it seems, is you have disabled SafeDllSearchMode. Looking at Windows 10, I'm getting the impression SafeDllSearchMode was removed (See 'Removed settings'). Not sure whether that means SafeDllSearchMode is now simply always on, or just always off.

http://blogs.technet.com/b/secguide/archive/2015/11/19/changes-from-the-windows-8-1-baseline-to-the-windows-10-th1-1507-baseline.aspx

LoRd_MuldeR
27th April 2016, 23:02
The "SafeDllSearchMode" has existed since Windows XP at least (if not longer). And the only difference in that mode is that the "current" working directory will be searched later - it will still be searched though (so still not entirely "safe").

In any case – regardless of whether SafeDllSearchMode is used or not – "the directory from which the application loaded", i.e. the directory where the EXE file resides, is always searched first.

Note: It is a good practice for applications (and many do now) to call SetDllDirectory("") (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85%29.aspx) early in the program, which completely removes the "current" working directory from DLL search order, so you can actually get more "safe" DLL loading.

Still, even after SetDllDirectory("") was called by the application, "the directory from which the application loaded" is always searched first :devil:

Groucho2004
27th April 2016, 23:18
Nope, instead WFP (https://en.wikipedia.org/wiki/Windows_File_Protection) will probably just silently restore the original file after a few seconds.
I have WFP turned off. It was just my experience, other's mileage may vary.

asarian
28th April 2016, 01:20
The "SafeDllSearchMode" has existed since Windows XP at least (if not longer). And the only difference in that mode is that the "current" working directory will be searched later - it will still be searched though (so still not entirely "safe").

In any case – regardless of whether SafeDllSearchMode is used or not – "the directory from which the application loaded", i.e. the directory where the EXE file resides, is always searched first.

Note: It is a good practice for applications (and many do now) to call SetDllDirectory("") (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85%29.aspx) early in the program, which completely removes the "current" working directory from DLL search order, so you can actually get more "safe" DLL loading.

Still, even after SetDllDirectory("") was called by the application, "the directory from which the application loaded" is always searched first :devil:


It would appear things work as you say they do. :) I placed a OpenCL.dll file (hardlink to NVIDIA's OpenCL64.dll) in my x264 dir, and it seems to pick it up (interestingly enough, it's a hardlink to the system32 OpenCL dir as well):


https://onedrive.live.com/redir?resid=CC6AFE600F85B114!122&authkey=!ADYUZCKIk8tl-HQ&ithint=folder%2cjpg