Using Intel iGPU on Windows 10, anyone have advice?

Andrew Dicker
Andrew Dicker
Joined: 6 Apr 13
Posts: 18
Credit: 90041313
RAC: 0

http://einstein.phys.uwm.edu/

http://einsteinathome.org/host/8557502 with a HD4600 is on drivers 10.18.15.4256, and is working fine with win10

Der Mann mit der Ledertasche
Der Mann mit de...
Joined: 12 Dec 05
Posts: 151
Credit: 302594178
RAC: 0

...did you reserved cpu cores

...did you reserved cpu cores for the gpu wu's?

Greetings from the North

Holmis
Joined: 4 Jan 05
Posts: 1118
Credit: 1055935564
RAC: 0

RE: http://einstein.phys.uw

Quote:
http://einsteinathome.org/host/8557502 with a HD4600 is on drivers 10.18.15.4256, and is working fine with win10


Thank you for your report!
It does indeed return valid work with a recent driver, that bodes well for the future.

As to optimization I have to ask the same question as Der Mann mit der Ledertasche, do you reserve a cpu cores to support the GPU tasks.
My HD4000 runs BRP4 tasks in about 700s and your HD4600 run them in about 1100s!
Or are you running two tasks at a time on you iGPU?

Floyd1
Floyd1
Joined: 29 Jun 14
Posts: 14
Credit: 590463278
RAC: 0

I have a HD4600 and recently

I have a HD4600 and recently upgraded to Windows 10 without any significant issues.

The GPU driver appeared to upgrade with the Windows installation, but there was a newer version from AMD already.

My machine happily crunched the remaining WUs in my cache, but then refused to download any new ones.

The Sched Log reported "[version] Intel GPU device name: 'Intel(R) HD Graphics 4600' doesn't match 'HD Graphics [123]|HD Graphics 40'"

I found someone else suggested reverting to an older driver. After a quick Google, I found 10.18.10.3496 which is listed by Intel as suitable for Windows 8.1 but works for Windows 10. Installing this brings up the usual warning about newer drivers already installed etc.

I am now back to crunching, but it would be useful to get the Einstein server to allow the newer drivers (assuming the newer drivers work without too many problems of course).

For the record, my machine crunches a pair of WUs concurrently taking somewhere between 18 and 20 mins each.

Holmis
Joined: 4 Jan 05
Posts: 1118
Credit: 1055935564
RAC: 0

RE: I am now back to

Quote:
I am now back to crunching, but it would be useful to get the Einstein server to allow the newer drivers (assuming the newer drivers work without too many problems of course).


Well according to this post by Bernd all you'd have to do is opt in on beta apps and the newer drivers should not stop you from getting tasks.

Floyd1
Floyd1
Joined: 29 Jun 14
Posts: 14
Credit: 590463278
RAC: 0

Does the Beta app run on

Does the Beta app run on valid data producing usable results, and does the client rack up the points for doing the work?

I am happy to be at the bleeding edge, but not so hot on using the electricity on plain testing.

At the moment, I am getting quite frustrated that my machine is burning lots of watts for no purpose.

After a recent "upgrade" to Windows 10, I have been struggling to get Einstein@Home run as cleanly and efficiently as it was beforehand, although I don't believe it was in a pretty state even then.

I think that either there is a conflict between the iGPU and AMD drivers or else Windows itself is helpfully updating drivers silently after a reboot.

I have also found it difficult to get a reliable take on what driver versions are "allowed" (Beta notwithstanding).

As things stand my machine seems to be back to producing 100% invalids from the R9 290X running BRP6 tasks which is a huge waste of resource.

I'm sure I'm not the only person with a mixed iGPU and 290X setup, so I'm sure I'm not the only person with this problem.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109407781236
RAC: 35288581

RE: Does the Beta app run

Quote:
Does the Beta app run on valid data producing usable results, and does the client rack up the points for doing the work?


Yes and yes.

Quote:
I have also found it difficult to get a reliable take on what driver versions are "allowed" (Beta notwithstanding).


You could always go to your computer list on the website and click on the 'Last contact' link to get the scheduler log for the most recent contact. Here is an excerpt from your host which clearly defines the range of allowed drivers.

2015-08-26 05:01:30.9181 [PID=29147]    [version] Checking plan class 'opencl-intel_gpu-new'
2015-08-26 05:01:30.9181 [PID=29147]    [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2015-08-26 05:01:30.9181 [PID=29147]    [version] [HOST#11741374] device name: 'Intel(R) HD Graphics 4600'; OpenCL driver version: 10.18.10.3496; platform version: OpenCL 1.2; device version: OpenCL 1.2
2015-08-26 05:01:30.9181 [PID=29147]    [version] driver version 1018103496, min: 0, max: 1018103906
2015-08-26 05:01:30.9181 [PID=29147]    [version] Peak flops supplied: 1.92e+11
2015-08-26 05:01:30.9181 [PID=29147]    [version] plan class ok

This excerpt shows the scheduler checking the opencl-intel_gpu-new plan class and determining that the plan class is OK because your driver version 10.18.10.3496 lies within the min (=0) to max (=1018103906, which is 10.18.10.3906) range. If you allow beta test apps, I'm guessing this range check is not applied - I don't know for sure because I'm running Linux and therefore can't use the iGPU on any of my hosts.

Quote:
As things stand my machine seems to be back to producing 100% invalids from the R9 290X running BRP6 tasks which is a huge waste of resource.


Are you running multiple concurrent tasks? There are quite a few reports of invalids on 290X and Fury when doing so. There are two recent threads, one for each of these GPUs, that contain posts about this.

Quote:
I'm sure I'm not the only person with a mixed iGPU and 290X setup, so I'm sure I'm not the only person with this problem.


I don't recall any such reports. People with high end discrete GPUs probably don't try to use the internal one for fear of compromising the performance of the external one.

Cheers,
Gary.

Floyd1
Floyd1
Joined: 29 Jun 14
Posts: 14
Credit: 590463278
RAC: 0

I'm guessing that Windows 10

I'm guessing that Windows 10 has become a cat amongst the pigeons.

I have twice downgraded my iGPU driver to comply with the demands of E@H, but some time later, the driver has been silently upgraded to the most recent version without seeking permission.

I have carefully uninstalled the newer version on both occasions, but not manually removed the driver files from the Windows System folder, so I assume there is some auto-detection going on.

In the meantime, it appears that the BOINC client is now able to download and process iGPU tasks despite the warning in the Sched Log.

I am still seeing the noted error message:-

"[version] Intel GPU device name: 'Intel(R) HD Graphics 4600' doesn't match 'HD Graphics [123]|HD Graphics 40'"

And I am also seeing "[version] driver version required max: 1018103906, supplied: 1018154256"

So my client should refuse to collect new tasks, right? It was refusing just a few days ago.

However, it is happily downloading and crunching away to its heart's content.

I think it's about time for the SysAdmins to setup and maintain some basic requirements such as required driver versions and also perhaps to announce when they change the rules, as they must have done to permit the higher version driver.

Holmis
Joined: 4 Jan 05
Posts: 1118
Credit: 1055935564
RAC: 0

There are statements all over

There are statements all over the web that Windows 10 Home will install all updates including drivers automatically with no built in way to stop it. In the Pro version there should be an option to delay the updates for some months and in the Enterprise version there's supposedly a way to opt out of updates at will.

Microsoft has released a tool to opt out of driver updates but I haven't tested it. You should be able to find it if you search for it.

The latest contact log when composing this message states that the scheduler refused to give you work for the iGPU because your host did not match the requirements for any of the three plan classes. Go to your Einstein@home preferences and opt in to run beta apps and you should get new work for it with the latest driver.

The work you have already been assigned would probably have been assigned when you were running the older driver.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109407781236
RAC: 35288581

RE: I am still seeing the

Quote:

I am still seeing the noted error message:-

"[version] Intel GPU device name: 'Intel(R) HD Graphics 4600' doesn't match 'HD Graphics [123]|HD Graphics 40'"


It doesn't have [ERROR] anywhere in the string so it is an informational message and not an error message. This message is simply informing you that your "HD Graphics 4600" doesn't match HD Graphics 1... or 2... or 3... or 40.., which it certainly doesn't :-). Holmis mentions the three possible plan classes that are checked to determine which one is suitable to use for your iGPU. He provided a link to Bernd's 'announcement' which in turn referred to the applications page where you can see the plan classes, listed in brackets after any particular app version.

Unfortunately, this doesn't tell you about driver versions and it never will. Things change so rapidly that even a team of 'documentation producers' couldn't keep up and the project doesn't have any such team. You just have to try things, ask questions, and repeat the cycle until you figure it out and get something that works - at which point you write about it to help others.

In your case, if you go through the scheduler log you will see these three plan classes as "opencl-intel_gpu-Beta" (can't be used unless you allow beta apps), "opencl-intel_gpu" (which seems to be for HD 4000 or earlier iGPUs), and "opencl-intel_gpu-new" (not restricted to HD 4000 or earlier but includes the driver version check). So, as Holmis points out, with the latest driver and no beta apps, your HD 4600 doesn't match any of these plan classes without having to fight with Windows all the time over driver version.

You have two options. Spend your time fighting with Windows to have the old driver for long enough to stock up with work before the driver is upgraded again (which you seem to have done rather nicely, judging by the number of tasks on board) :-) -OR- just allow beta test apps and use the new driver until it is 'trusted' by the Devs. Sure seems to be much simpler to do this if the results are validating. That should help provide evidence of the efficacy of the latest driver.

Cheers,
Gary.

Comment viewing options

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