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
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.