I've checked this on one of my Windows XP x64 hosts, and it has received the v9.18 (CUDA8.0) client.
Tasklist
Host details
EDIT: you may see this host as a Windows 10 PC, as right now I'm updating the "spare" Windows 10 OS on my hosts. But it had received the CUDA8.0 client before I begin to work with this host (i.e. under Windows XP x64, GTX 980 Ti, driver v358.50).

I have received two 9.18 CUDA 8.0 tasks on my xp computer, they errored out:


http://www.gpugrid.net/result.php?resultid=16246847

http://www.gpugrid.net/result.php?resultid=16246846



The computer has driver 355.82 CUDA 7.5.

I have 2 GTX460 cards (Hosts 317733 & 208443) that have been unable to get work since the changes over the weekend.
Both are running Driver ver. 378.92. According to GPU-Z these cards are sm 5.0.

The project will not send work saying no tasks available.

4/17/2017 6:07:42 PM | GPUGRID | update requested by user
4/17/2017 6:07:46 PM | GPUGRID | Sending scheduler request: Requested by user.
4/17/2017 6:07:46 PM | GPUGRID | Requesting new tasks for NVIDIA GPU
4/17/2017 6:07:49 PM | GPUGRID | Scheduler request completed: got 0 new tasks
4/17/2017 6:07:49 PM | GPUGRID | No tasks sent
4/17/2017 6:07:49 PM | GPUGRID | No tasks are available for Short runs (2-3 hours on fastest card)
4/17/2017 6:07:49 PM | GPUGRID | No tasks are available for Long runs (8-12 hours on fastest card)

Other computers running GTX750Ti & GTX1050Ti are reciving work without any problems.

I'm getting the same error of not receiving tasks for a GTX 570 with 381.65 Windows 8.1 However no problems with my other cards: GTX 770, and GTX 660TI.

Since the 570 and 460 cards are Fermi based, I am guessing that they might not be supported anymore. But that is speculation on my part as I am not an advanced computer user.

Based on the recent information that GPUGRID will run on Windows XP for one more year, I tried to continue crunching on my XP machine (driver 361.75).
However, BOINC says

18/04/2017 07:14:02 | GPUGRID | No tasks are available for Long runs (8-12 hours on fastest card)

although the Project Status Page shows 300+ unsent tasks.

What can I do to get the thing work?

What can I do to get the thing work?

I confirm too, that my Windows XP x64 hosts have received the 8.49 app, and it's working.

Suspending, with the 918 app, is not working correctly! It sometimes takes ~20+ seconds to see the app respond to a suspend request. It should be < 3 seconds!

Also, you mention "The peculiar exception for sm 3.0 devices is due to a compiler problem with CUDA 80" ....... so:
- Who is responsible for fixing that (you, or NVIDIA?)
- What steps are being taken to get it fixed (have you contacted the right people?)

Suspending, with the 918 app, is not working correctly! It sometimes takes ~20+ seconds to see the app respond to a suspend request. It should be < 3 seconds!

Also, you mention "The peculiar exception for sm 3.0 devices is due to a compiler problem with CUDA 80" ....... so:
- Who is responsible for fixing that (you, or NVIDIA?)
- What steps are being taken to get it fixed (have you contacted the right people?)

Suspending, with the 918 app, is not working correctly! It sometimes takes ~20+ seconds to see the app respond to a suspend request. It should be < 3 seconds!

Also, you mention "The peculiar exception for sm 3.0 devices is due to a compiler problem with CUDA 80" ....... so:
- Who is responsible for fixing that (you, or NVIDIA?)
- What steps are being taken to get it fixed (have you contacted the right people?)

I have the same issue on my windows 10 computer, running GTX980ti cards.

I upgraded both of my PCs to the 381.65 driver, and I am no longer getting work. It is a bit unclear to me whether I should be getting work. From what I understand, my 460 and 580 are fermi based, but from the announcement, I am lead to believe that Fermi is still supported. I do realize that there are others using similar cards and that they are not receiving work, either, so I am guessing that these cards are now no longer supported.

Matt, is it official that Fermi is no longer supported for gpugrid?

Thanks.

____________

is it official that Fermi is no longer supported for gpugrid?

MJH said:

15 Apr 2017 | 21:43:26 UTC
http://www.gpugrid.net/forum_thread.php?id=4545&nowrap=true#46932

For some reason the sm 3.0 support (and only that sm version) is broken.

The peculiar exception for sm 3.0 devices is due to a compiler problem with CUDA 80 that affects only that hardware version. When that's fixed, hosts with a non-XP Windows will get 918.

is it official that Fermi is no longer supported for gpugrid?

Yes.
Fermi (GTX 4xx & GTX 5xx series) is CC2.0 and CC2.1 which is below the minimum required CC3.0 therefore they are no longer supported for GPUGrid.
Due to some undisclosed "compiler problems" the the lesser Kepler based cards (CC3.0, GTX 660Ti) will fail all tasks.
See the compute capability (CC, also known as Shader Model (SM)) table on Wikipedia.

is it official that Fermi is no longer supported for gpugrid?

Yes.
Fermi (GTX 4xx & GTX 5xx series) is CC2.0 and CC2.1 which is below the minimum required CC3.0 therefore they are no longer supported for GPUGrid.
Due to some undisclosed "compiler problems" the the lesser Kepler based cards (CC3.0, GTX 660Ti) will fail all tasks.
See the compute capability (CC, also known as Shader Model (SM)) table on Wikipedia.

What is interesting is that my GTX 660TI is working just fine.

Application version Long runs (8-12 hours on fastest card) v8.49 (cuda65)

MJH (et. al):

I have concluded my exhaustive Cuda 8.0 SDK testing. On my Win10 x64 Build 16184 PC (with GTX970, GTX660Ti, GTX660Ti), I installed VS2015 Community, installed the Cuda 8.0 Toolkit and samples, installed the DirectX SDK, then built all of the Cuda solutions.

There are 155 Cuda samples that I was able to compile and test with. And I went through them, 2 times:
1) 381.89 - GTX970, GTX660Ti, GTX660Ti
2) 381.89 - GTX660Ti, GTX660Ti (I pulled the GTX970 out of the system)

Out of the 155 samples, they all passed on both runs.. except VFlockingD3D10 did not look correct on my GTX660Ti but looked fine on my GTX970. All other calculations and samples worked fine, even on a GTX660Ti.

This leads me to believe that the GPUGrid problem with the "9.18 (cuda80)" app, where it errors out immediately on a system that has a CC3.0/SM3 GPU .... might not be an NVIDIA problem. It might be a problem with your app.

Is it possible you are calling some method or function, that isn't supported by CC3.0/SM3?

I'm desperately wanting you to provide more info. I'm spending considerable effort to help you solve this, yet my questions to you go on unanswered. I hope you're making progress with a fix - please consider chiming in with your findings.

Jacob Klein

Month 2.
The frustration continues.

Suspending, with the 918 app, is not working correctly! It sometimes takes ~20+ seconds to see the app respond to a suspend request. It should be < 3 seconds!

Also, you mention "The peculiar exception for sm 3.0 devices is due to a compiler problem with CUDA 80" ....... so:
- Who is responsible for fixing that (you, or NVIDIA?)
- What steps are being taken to get it fixed (have you contacted the right people?)

I have the same issue on my windows 10 computer, running GTX980ti cards.

Suspending has taken up to 5min on Win8.1.
Resume/suspend an issue where (15) WU error upon resume on same or different GPU.
WU need to run without interruption to get a proper validation.

what happens to my two hosts on Windows 10 with acemd 918.80 and driver 381.65, you can read here:

http://www.gpugrid.net/forum_thread.php?id=4571&nowrap=true#47261

NOT amusing at all :-( I cannot leave the two PCs unattended for lengthy time.

OK, finally know why I am not getting any work for GT 610. So, deleting the project from my client, no more reason to have it there.

GPUGrid:

Regarding the problem of your app immediately crashing on CC3.0/SM3 GPUs (like my 2 "GTX 660 Ti" GPUs)...

Is it a problem that GPUGrid must fix, or is it a problem that NVIDIA must fix?

I feel like nobody is trying to fix it. And if it is something NVIDIA must fix, and if GPUGrid gave me enough info to identify the problem, then I might be able to work with NVIDIA to fix it.

But you guys aren't forthcoming with details.

When can we expect some answers? My main question, above, is still unanswered.

Hello?

*tap tap* Is this thing on?

5 weeks have now gone by, with no response to my questions!
I hope I'm not being rude by asking admins to follow up, but needless to say I'm miffed about this lack of communication!
Especially since my GTX 660 Ti GPUs are still unusable due to bugs with your most recent 9.18 app version. :(

How may we help you resolve the bugs?

GPUGrid:

Regarding the problem of your app immediately crashing on CC3.0/SM3 GPUs (like my 2 "GTX 660 Ti" GPUs)...

Is it a problem that GPUGrid must fix, or is it a problem that NVIDIA must fix?

I feel like nobody is trying to fix it. And if it is something NVIDIA must fix, and if GPUGrid gave me enough info to identify the problem, then I might be able to work with NVIDIA to fix it.

But you guys aren't forthcoming with details.

When can we expect some answers? My main question, above, is still unanswered.

I'd love to help, somehow.

I think that the only possible way to help the team is making a lot of donations. They for sure need a lot of money to hire someone with good programming skills. Could we as a community aford that? Probably. Would we? I don't think so.
So it is time to accept the fact that the team is too small and too busy to do everything we want them to do. As long as there are new publications provig that the most important thing (science ftw!) is covered I will support the GPUGRID.


BTW it is a common problem, my girlfriend is a scientist, not working with BOINC but facing exacly the same problem.

And they appear to have enough support, even with the reduced output on Windows. The unsent tasks are down to zero, probably due to the summer lull. There is no point in increased crunching power for the moment.

I think that the only possible way to help the team is making a lot of donations. They for sure need a lot of money to hire someone with good programming skills. Could we as a community aford that? Probably. Would we? I don't think so.
So it is time to accept the fact that the team is too small and too busy to do everything we want them to do. As long as there are new publications provig that the most important thing (science ftw!) is covered I will support the GPUGRID.


BTW it is a common problem, my girlfriend is a scientist, not working with BOINC but facing exacly the same problem.

Jacob I'm really sorry for this. Matt has effectively left our team so now we have hired a new person to work on Acemd and it's replacement in Acemd3. I doubt it will be very efficient to solve this issue when we can hopefully transition to Acemd3 which will use a more stable code base. If it's something urgent or really annoying such as this case feel free to PM me where I will definitely see it sooner.

Jacob I'm really sorry for this. Matt has effectively left our team so now we have hired a new person to work on Acemd and it's replacement in Acemd3. I doubt it will be very efficient to solve this issue when we can hopefully transition to Acemd3 which will use a more stable code base. If it's something urgent or really annoying such as this case feel free to PM me where I will definitely see it sooner.

That would gen great; nothing worst then silence. It's ok to have problems, but sharing it will reduce noise and can activate support.

I'm glad it's working again as I prefer this GPu project to others on BOINC

That would be great; nothing worst then silence. It's ok to have problems, but sharing it will reduce noise and can activate support.

I'm glad it's working again as I prefer this GPu project to others on BOINC

Matt has effectively left our team so now we have hired a new person to work on Acemd and it's replacement in Acemd3.

Sounds interesting, I hope you can do it Stefan. I read briefly on OpenMM's site, it suggests a support for AMD, so maybe you will begin support for that? Not that I have any AMD cards myself, but it could open up for a larger userbase, which could give a shorter turnaround time for workunits in the end. A plus for your research I take it.

As for windowsXP, I don't use it myself, but maybe the more tech savvy users on XP, should consider a switch to linux eventually. I understand some users have trouble with the learning curve, if they are not familiar with linux though.

As for windowsXP, I don't use it myself, but maybe the more tech savvy users on XP, should consider a switch to linux eventually. ...

The main concern with GPUGrid is GPU utilization. SWAN_SYNC is a way to mitigate this with windows but definitely not solve it. From what I've found, using linux under the 9.14 application you will see 90%+ on high end GPUs with an appropriately fast cpu. On windows it is hard to match this, even with these techniques. It almost doesn't matter that SWAN_SYNC isn't on linux because the utilization is so high.

My experience with (or without) Swan_Sync in Windows is the following:
when I newly installed BOINC on one of my PCs recently and ran GPUGRID, I was wondering why in the Windows Task Manager, a CPU utilization by acemd.exe of only a few percent was shown.
I had forgotten the Swan_Sync setting.
After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

Yup, Swan_Sync on Windows was also something I tried, verified worked, then immediately undid. I like my CPUs keeping as busy as possible doing other projects, rather than "spin-waiting" on GPU kernels to make them only slightly faster.

can we exspect short run tasks to come in the near future?
____________

After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

That would be a show-stopper for me: I use my CPUs for other purposes.

After I had set Swan_Sync, acemd.exe was using nearly 100% of a CPU core.

That would be a show-stopper for me: I use my CPUs for other purposes.

Well, on all my PCs (all having a different number of CPU cores) with which I do GPU crunching, I dedicate 1 CPU core to 1 GPU. All other CPU cores are free for other activities.

The main concern with GPUGrid is GPU utilization.

SWAN_SYNC is a way to mitigate this with windows but definitely not solve it.

From what I've found, using linux under the 9.14 application you will see 90%+ on high end GPUs with an appropriately fast cpu. On windows it is hard to match this, even with these techniques.

It almost doesn't matter that SWAN_SYNC isn't on linux because the utilization is so high.

I haven't seen much difference(in tasks's execution speed) between using SWAN_SYNC and increasing priority(High:13) of process acemd-918-80.exe.
This approach eliminates the impact of any other programs on the GPU tasks.
IMG_01
I suggest to test the option of changing the priority.
That will free up additional processor core(if you specify CPU < 1.0 for GPU tasks) and would make the system more responsive(on my feeling).
To Automate the increase of priority of GPUGRID tasks use Process Hacker.
Using the shortcut menu we increasing the priority and save configuration.
IMG_02
Since Process Hacker must be running when new task started , it is best to run Process Hacker at system startup(in minimized state).
IMG_03

Sorry to interrupt, I just want to say that I have made a small (10 euros) donation. When I am sure that everything goes well I will make another.

I would like to encourage everyone to do at least a smallest one. You won't even notice this 10 euros, but en masse it could make a big difference for the team.

It's good to see more forum participation from project admins/scientists. Even a "We'll take a look at xx issue" comment here and there gives end users the confidence to keep donating processor cycles.

I still find it odd that a setting like swan_sync needs to be used at all. Other GPU apps do not need it. BOINC or FAH. Typically CPU apps get the Idle priority and GPU apps get Below Normal (1 step higher than idle) which will give CPU priority to GPU apps when both are running. I don't recall what it is set at and I'm not next to one of my PCs.

As long as the exes are different names I separate the GPU exe to it's own CPU core/thread affinity using Process Lasso. That is usually enough in Windows. Linux works well enough to not really need a program like Process Lasso. I would think if it has a higher priority and/or an open thread it would be like a virtual swan_sync setting.

Now that Matt has left GPUGRID, I hope that the team and the new person see the situation differently, and that the crunchers who still use Windows XP for good reason will get a crunching software beyond April 2018.

If we manage to make the switch to Acemd3 it will be based on OpenMM so it will only depend on where OpenMM can run on.

I still find it odd that a setting like swan_sync needs to be used at all.

I still find it odd that a setting like swan_sync needs to be used at all.

Other GPU apps do not need it. BOINC or FAH.

I think I read somewhere that the utilisation figures for NVidia GPUs are taken from the first shader multiplex (or render output unit, which seems to be the latest terminology): the rest of the card isn't measured or reported.

I hope that the team and the new person see the situation differently, and that the crunchers who still use Windows XP for good reason will get a crunching software beyond April 2018.

do any of the experts here know whether OpenMM can be run on WindowsXP ?
I was searching for this kind of information, but did not find anything.

OpenMM is optimized for the latest generation of compute hardware, including AMD (via OpenCL) and NVIDIA (via CUDA) GPUs. We also heavily optimize for CPUs using intrinsics

Sounds interesting, I hope you can do it Stefan. I read briefly on OpenMM's site, it suggests a support for AMD, so maybe you will begin support for that? Not that I have any AMD cards myself, but it could open up for a larger userbase, which could give a shorter turnaround time for workunits in the end. A plus for your research I take it.

You cannot install a pascal GPU into an XP machine, and there is no way to hack it like with the 980ti. For the future is 14nm and below, I don't see a point in running these 28nm GPUs for any longer than they have to.

I still find it odd that a setting like swan_sync needs to be used at all.

swan_sync isn't needed at all - I run GPUGrid under Windows without using it. But it is available for use, for those members who wish to arrange their processing priority that way.

I also use Process Lasso - there's one particular application, from one other BOINC project, which gains something like a six-fold increase in productivity from being run at real time priority, without having any ill-effects on the general use of the computer (Both GPUGrid and that other application are running on this computer as I type).

So I have nothing against using productivity tweaks where available: but they are choices, rather than requirements.

Fine I'll word it differently. It shouldn't be needed to fully utilize a GPU.

As I mentioned, other projects take what is needed before CPU apps. GPUGrid should be no different.

Absolutely it does NOT make any sense to crunch with XP in 2017.
2018.....why not 2020 with XP?

I have noticed an issue where GPUGRID fails to resume properly after being suspended. When BOINC suspends all current tasks due to the CPU being busy for a few seconds (like when launching a large program), your task doesn't resume when the CPU is free again. It says it is running and the elapsed time changes correctly, but no progress is made. However, it will successfully resume after a GPU exclusive task has been run.

This is a serious issue as it wastes tremendous amount of time and results in the task being completed after the deadline which renders it useless.

The task in question was a 918 version.

Are you aware of this issue? Is there any additional information I can provide?

John

... GPUGRID fails to resume properly after being suspended. ... The task in question was a 918 version.

Are you aware of this issue?

Is there any additional information I can provide?

It's really too bad that in April Matt put together, in a hurry, a rather buggy software, and short time later he left GPUGRID without eliminating all these bugs :-(

BTW, for this reason I had no other choice than abandoning crunching GPUGRID with one of my hosts :-(

Fine I'll word it differently. It shouldn't be needed to fully utilize a GPU.

In an ideal world that would be this way. Unfortunately the real world is far from the ideal, in many aspects. The GPUGrid app is one of these aspects. However, I still think that even other projects show 99% GPU usage, the GPUGrid app does more FLOPS than the others while showing "only" 90% GPU usage. There are users who have to throttle the GPUGrid client to avoid overheating their GPU.

As I mentioned, other projects take what is needed before CPU apps. GPUGrid should be no different.

Why not? The science and the methods are different for each project.

90% is a dream. Try in the 60s with a single task and low 80s with two tasks. Think of the flops that could be achieved if GPU util was above 95%.

Think of the flops that could be achieved if GPU util was above 95%.

The science and methods have nothing to with with the priority of the executable.

90% is a dream. Try in the 60s with a single task and low 80s with two tasks. Think of the flops that could be achieved if GPU util was above 95%.

Excellent detail there, especially the juicy innards of process priorities and the SWAN_SYNC variable!

Just one point of clarification - I believe BOINC CPU apps are set to run at "Idle" priority by default, instead of "Low".

Excellent detail there, especially the juicy innards of process priorities and the SWAN_SYNC variable!

Just one point of clarification - I believe BOINC CPU apps are set to run at "Idle" priority by default, instead of "Low".

Excellent detail there, especially the juicy innards of process priorities and the SWAN_SYNC variable!

Just one point of clarification - I believe BOINC CPU apps are set to run at "Idle" priority by default, instead of "Low".

The importance of PCIE & CPU rates/strengths/weaknesses might change as might the operating systems we can use...

... and if the WDDM overhead isn't an issue with OpenMM then supporting XP might be unnecessary.