Nvidia opencl capability is not cleaned by Nvidia clean install

Richie
Richie
Joined: 7 Mar 14
Posts: 392
Credit: 1,516,772,584
RAC: 48
Topic 217783

I was forced to reinstall Windows 10 on my computer after it had a HDD disaster yesterday (an old 80GB WD sata1 disk didn't start up anymore after being shut down for a day).

OK, I installed Windows 10 (17763) on a new disk. Windows installed it's basic version of display driver for Nvidia (GTX 960). That driver is no good for Boinc and I was prepared to install a genuine Nvidia driver.

I downloaded and installed a 'hotfix' version 417.58. Installation went fine and then I forced a reboot.

I started Boinc and didn't read the log notes carefully enough. I just quickly looked  "Ok, the card is there... I see there's a line with GTX960". I tried to get new work for GPU, but no work was sent. I was scratching my head and thinking "stupid stupid setup, obey me already! ". After about half an hour I actually read some lines on the event log and server 'last contact' log. Work wasn't sent because opencl capability was missing. Also GPU-Z did show the opencl checkbox was empty.

Now I was like "HOOOW can opencl be missing here, because 2 other computers in front of me are running exactly that same Nvidia driver".

Had to try something... so I decided to install driver version 417.42. I had been running that previously and it had supported opencl for sure.

I chose 'clean install' on the Nvidia installer. After a reboot I was able to confirm there was opencl capability and Boinc could start running GPU tasks.

I was still like "I can't understand" ... and decided I should try installing 417.58 for the second time. I chose again 'clean install'.

Yes... after a reboot there suddenly was opencl capability.

 

This was a new experience for me. The other computers had been going through manual driver updates somewhat regularly and such they had inherited the opencl capability from an earlier driver (417.42 or earlier). That's why I thought also the hotfix driver would've had that opencl capability (and ALL other drivers coming from Nvidia). It doesn't.

The interesting observation for me  was that choosing the 'clean install' option in Nvidia installer doesn't seem to remove opencl capability, if it has been already installed. Otherwise my computer should've ended lacking opencl again after the second installation of 417.58.

This made me think if using DDU does wipe away also opencl. I assume it would do that. I haven't used DDU lately, but I've understood it to be more thorough than Nvidia 'clean install' so it should remove everything.

I know there could be a thing or two I missed or forgot while proceeding with my setup... or I've possibly misunderstood something completely.  Anyway... for me this was a new experience with the GPU drivers Surprised

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 1,912
Credit: 130,385,661
RAC: 73,126

The OpenCL capability doesn't

The OpenCL capability doesn't necessarily come from NVidia.

I performed a 'clean room' test of Windows 10 about (I think) 18 months ago - on a machine which could use either an NVidia GPU or an Intel GPU, but not both at the same time.

Starting with the NVidia GPU, Microsoft automatically sent me a CUDA driver. Check.

Removing the NV card, the Intel fired up and Microsoft automatically sent me an OpenCL driver. Check.

Replacing the NV card, I found I had OpenCL support for NV too, with no manual driver installation.

archae86
archae86
Joined: 6 Dec 05
Posts: 2,608
Credit: 2,084,647,988
RAC: 2,138,144

I harbor a suspicion from my

I harbor a suspicion from my experiences and other reports that the BOINC assessment of opencl capability may be as simple as checking a flag, somewhere.  Some of what gets reported here as drivers not capable of opencl may just be installations that failed to set that flag.  I somewhat doubt there is some other piece of actual software hovering on the fringes which conveys the actual capability.

Aside from the opencl matter, I've had card detection problems of the second card in a two-card installation for which the only successful resolution I stumbled on came from selecting "clean install" on the Nvidia driver installation (and this was a case where DDU had not resolved the matter).

As I don't know myself to make adjustments to the driver I ever want to keep, the above two beliefs have put in the routine practice of always selecting "clean install" every time I do Nvidia driver installs.

Jim1348
Jim1348
Joined: 19 Jan 06
Posts: 317
Credit: 175,432,529
RAC: 49

I had assumed that Win 10

I had assumed that Win 10 does not install OpenCl drivers.  At least I have heard that when Win 10 upgrades the drivers you have, it uninstalls the OpenCl capability (maybe CUDA too). 

But I just clean installed Win 10 (1809) on a new machine with a GTX 750 Ti, and was suprised to find in the BOINC log:

1/2/2019 3:33:54 PM    CUDA: NVIDIA GPU 0: GeForce GTX 750 Ti (driver version 388.13, CUDA version 9.1, compute capability 5.0, 2048MB, 1689MB available, 1472 GFLOPS peak)

    
 1/2/2019 3:33:54 PM    OpenCL: NVIDIA GPU 0: GeForce GTX 750 Ti (driver version 388.13, device version OpenCL 1.2 CUDA, 2048MB, 1689MB available, 1472 GFLOPS peak) 

Also, GPU-Z showed both  OpenCl and CUDA available.  So I decided to try it on Einstein, and it is running FGRPopencl1K-nvidia just fine. 

By the way, I have heard that the Nvidia drivers before the 400 series are a little faster, so I will stay with those.  Also, the GTX 750 Ti is arguably not a great card for Einstein (or at least not that fast), but it does seem to be efficient.

 

 

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,020
Credit: 102,340,840
RAC: 132,194

Richard Haselgrove wrote:The

Richard Haselgrove wrote:
The OpenCL capability doesn't necessarily come from NVidia.

Correct. FWIW here's a diagram of the generalities of who produces what components that make up OpenCL.

OCLGeneralities.jpg

It's also worth a mention that Khronos has a list of OpenCL conformant products that you can peruse. In the Windows registry look at 'HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors' to find out what dll's are installed.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Richie
Richie
Joined: 7 Mar 14
Posts: 392
Credit: 1,516,772,584
RAC: 48

Thank you for that diagram

Thank you for that diagram and others for other messages. I think I see opencl in a wider way now. There's more parts in it than  what the GPU drivers (AMD / Nvidia etc.) do include with their installers.

Mike Hewson wrote:
It's also worth a mention that Khronos has a list of OpenCL conformant products that you can peruse. In the Windows registry look at 'HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors' to find out what dll's are installed.

I was curious and looked at that registry location on the computer in question. There's only one REG_DWORD: C:\\Windows\System32\DriverStore\FileRepository\ ... ... \amdocl64.dll

Umm, the computer was running an AMD GPU before the disk crash and reinstall. I'm not sure anymore if I actually made the fresh Windows installation with that AMD GPU still in place. I might have replaced that with the GTX 960 only after the installation. Maybe that amd reg_dword would be missing if I installed with Nvidia GPU in the first place.

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,020
Credit: 102,340,840
RAC: 132,194

Richie wrote:Thank you for

Richie wrote:
Thank you for that diagram and others for other messages. I think I see opencl in a wider way now. There's more parts in it than  what the GPU drivers (AMD / Nvidia etc.) do include with their installers.

The main thing is that there are no static kernel compilations. It's done on the fly, as it were, by the runtime which presents a list of platforms ( host & one or more devices ) to the user/developer written host code. A choice is made and then specific devices are dealt with by vendor specific runtime components, especially by compiling said kernels* to match the hardware. That's where OpenCL portability comes from, and for that matter you don't have to use even GPUs. You could have a multicore processor as a platform, with one core acting as host and another core as the device. I don't know why you would do this, engaging all the OpenCL abstractive overhead for something you could do rather more directly. But the point to be made is that if some device software conformingly supports OpenCL then you can use it. Obviously the commonest is a CPU/GPU pairing.

Quote:

I was curious and looked at that registry location on the computer in question. There's only one REG_DWORD: C:\\Windows\System32\DriverStore\FileRepository\ ... ... \amdocl64.dll

Umm, the computer was running an AMD GPU before the disk crash and reinstall. I'm not sure anymore if I actually made the fresh Windows installation with that AMD GPU still in place. I might have replaced that with the GTX 960 only after the installation. Maybe that amd reg_dword would be missing if I installed with Nvidia GPU in the first place.

Firstly the registry entry is referring to a shared library offering OpenCL linkages for a specific device, it is not the device driver in toto. Secondly many OpenCL devices may be present in the one system, so you could easily have both AMD and NVidia OpenCL runtimes mentioned in the registry with each available to be incorporated into some platform. The riveting question is what device will an ( E@H ) application choose if there are several ....

Cheers, Mike. 

* A kernel isn't a program run on a GPU, so much as a special piece of ( OpenCL language ) code that one has chosen to represent the parallel part of some larger algorithm. For E@H that which can be readily parallelised is a type of Fourier Transform implementation called a Fast Fourier Transform. I think our developers use FFTW : the Fastest Fourier Transform in the West ! I think it has nearly the lowest O(N log2N) complexity currently available.

( edit ) I ought attribute my source of the diagram : "OpenCL Programming  by Example" by Ravishekhar Banger Koushik Bhattacharyya. The associated text is :

... Khronos also provides OpenCL header files. They are cl.h, cl_gl.h, cl_platform.h, and so on. An application programmer uses these header files to develop his application and the host compiler links with the OpenCL.lib library on Windows. This library contains the entry points for the runtime DLL OpenCL.dll. On Linux the application program is linked dynamically with the libOpenCL.so shared library. The source code for the OpenCL.lib file is also provided by Khronos. The different OpenCL vendors shall redistribute this OpenCL.lib file and package it along with their OpenCL development SDK. Now the application is ready to be deployed on different platforms. On Windows, at runtime the application first loads the OpenCL.dll dynamic link library which in turn, based on the platform selected, loads the appropriate OpenCL runtime driver by reading the Windows registry entry for the selected platform (either of amdocl.dll or any other vendor OpenCL runtimes). On Linux, at runtime the application loads the libOpenCL.so shared library, which in turn reads the file /etc/OpenCL/vendors/*.icd and loads the library for the selected platform. There may be multiple runtime drivers installed, but it is the responsibility of the application developers to choose one of them, or if there are multiple devices in the platforms, he may want to choose all the available platforms. During runtime calls to OpenCL, functions queue parallel tasks on OpenCL capable devices ... 

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Richie
Richie
Joined: 7 Mar 14
Posts: 392
Credit: 1,516,772,584
RAC: 48

Thank you Mike ! I'm a bit

Thank you Mike ! I'm a bit overwhelmed... but that was interesting information. The example that you gave about theoretically using only cpu's,  that was new to me. I haven't understood much anything about that "portable" nature in OpenCL and how it is constructed. I'm slowly starting to see better Smile

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,020
Credit: 102,340,840
RAC: 132,194

My understanding is truly

My understanding is truly pretty basic. This rabbit hole is a deep one, but try to think of OpenCL as a formalised attempt to get radically different hardware architectures to work together in parallel. Therein lies a natural complexity, but which can be managed by creating abstractions like 'host', 'device', 'program', 'kernel', 'queue' etc.

ASIDE : I believe someone has created a thin C++ layer over the OpenCL API in order to bury messy detail inside OOP objects. That's clever.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Jim1348
Jim1348
Joined: 19 Jan 06
Posts: 317
Credit: 175,432,529
RAC: 49

Mike Hewson wrote:My

Mike Hewson wrote:
My understanding is truly pretty basic. This rabbit hole is a deep one, but try to think of OpenCL as a formalised attempt to get radically different hardware architectures to work together in parallel.

I wonder how that compares to CUDA.  I have always thought of CUDA as similar to OpenCl, except limited to Nvidia GPUs, which allows for an increase in efficiency since they match the hardware with the software.

But it may be more than that - I really don't know.  There was an intriguing statement in the Wiki on OpenCl:

The fact that OpenCL allows workloads to be shared by CPU and GPU, executing the same programs, means that programmers can exploit both by dividing work among the devices. This leads to the problem of deciding how to partition the work, because the relative speeds of operations differ among the devices. Machine learning has been suggested to solve this problem: Grewe and O'Boyle describe a system of support vector machines trained on compile-time features of program that can decide the device partitioning problem statically, without actually running the programs to measure their performance. 

https://en.wikipedia.org/wiki/OpenCL

So can they do that with CUDA?  If not, the very generality of OpenCl might lead to an increase in overall efficiency, instead of a loss.

Since I don't know about any of this subject matter, I am free to speculate as I wish.

 

Keith Myers
Keith Myers
Joined: 11 Feb 11
Posts: 374
Credit: 315,566,534
RAC: 51,452

The OpenCL may be more

The OpenCL may be more general but it doesn't offer the performance in parallel computing that CUDA does.  So far.

Over at Seti, the CUDA90-CUDA10 application speed blows the doors off the OpenCL SoG application.  The SoG application developer has not figured out how to implement the synchronization necessary to speed up the OpenCL application that the CUDA development system allows easily for the CUDA apps.

BoincStats

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.