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.

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

Well, if you take a look at the performance page, you'll be surprised. Check the rankings of the PABLO_P01106_2 batch, and you'll find my GTX 980Ti at the 9th place, right above a GTX 1080, and a GTX TitanX (Pascal). If you check the rankings above my GTX 980Ti, you could see that a GTX 1080Ti (which costs 2.5 times as a 2nd hand GTX980Ti) is only 10-15% faster. So much for the WDDM (introduced in Windows Vista and all later versions have it). Oh, that GTX 980Ti runs under the obsolete Windows XP. I would instantly switch to Linux if the Linux app would have the SWAN_SYNC option. To be able to compare the performance of Windows XP with SWAN_SYNC, and Linux without SWAN_SYNC I will install Linux to one of my hosts, and put the same make / model GPU in it (MSI GTX980Ti Gaming 6G) as the one of my Windows XP host has.

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?

It's a know bug, seems to depend on the workunit batch.
A similar bug is when you (or the BOINC manager) suspend(s) the task, it could take a while when it really happens.

Is there any additional information I can provide?

No.

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.

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%.

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%.

I think it has long been recognized on some projects that the GPU% is just the value that some counter gives somewhere on the chip, but no one really knows what it is. If the software runs the desired science application as well as the compilers allow (of which I know nothing about), then it works well enough. And the scientists, worthy as they are, are not compiler specialists insofar as I can see, and they probably have better ways of spending their time anyway.

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

I think the total flops of a GPU driving all multiplexes at 85-90% (probably running into thermal or power throttling) would be much greater than a different app driving the first multiplex at 95% unthrottled, but leaving the rest to idle.

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

The GPUGrid app (just like any other GPU app) runs at "below normal" process priority, while CPU apps run at "low" process priority (which is one lower than "below normal"). Other processes usually run at "normal" piority.
SWAN_SYNC does not change the process priority level, it changes the behavior of the app.

With SWAN_SYNC off:
1. the app gives the control back to the OS
2. the GPU gives an interrupt (signaling that it has finished the tiny part of the calculation), and due to this interrupt the OS gives the control back to the GPUGrid app
3. The app reads the result, does some calculations in double precision (if needed), then sends the next piece of the calculation to the GPU.
4. it starts all over again, until the number of iterations has been reached

With SWAN_SYNC on:
1. the GPUGrid app continuously polls the GPU waiting for the GPU to finish the actual piece of calculation
2. the app reads the result, does some calculations in double precision (if needed), then sends the next piece of the calculation to the GPU.
3. it starts all over again, until the number of iterations has been reached

Now, with modern Windows OSes there's an extra time needed in every CPU-GPU interactions due to Windows Display Driver Model. That's why the GPUGrid app runs faster (has higher GPU utilization) under Windows XP and Linux.
This cycle has to run a couple of thousand times per second. If the given batch needs a lot of double precision calculations, the difference of overall processing speed between WDDM and non-WDDM OS will be larger, and with SWAN_SYNC on this difference is even higher (due to the missing step in the processing cycle)

Other GPU projects (like SETI@home, or Einstein@home) do not interact that frequently with the GPU, hence they can reach higher GPU utilization.

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%.

I have 95% GPU usage under Windows XP, so it's not the fault of the GPUgrid app alone.

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".

According to Process Explorer, my CPU apps are running at a priority of 1, on a scale that goes up to 16.

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".

You are right.
This is my mistake, as I use a localized OS (in Hungarian) and it calls this priority level "alacsony" which I've translated back to English ("low"), while originally this priority level is called "Idle".

Assuming an OpenMM based Acemd3 app turns up, all & any user side tweaks, modifications & optimizations will need to be reassessed, primarily to see if they work. Coolbits, nice, SWAN_SYNC, process lasso, priority, HT ON/OFF, freeing up a CPU/thread...
Which GPU models will work best/are the best value would need to be reassessed. Some may no longer work, some might be better...
The importance of PCIE & CPU rates/strengths/weaknesses might change as might the operating systems we can use...

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

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

no idea whether WDDM would then any longer play a role; and, subsequently, whether WindowsXP, due to it's lack of WDDM, would any longer have an advantage over the newer systems.

Besides the question whether OpenMM would run on WindowsXP at all.

Don't know what the situation is regarding a new app but if an OpenMM app was compiled using VS 2010, in theory it might still work on XP. The latest VS version doesn't support XP IIRC. Other factors (CUDA Drivers, a mainstream Volta release) might still prevent it working and if the WDDM overhead isn't an issue with OpenMM then supporting XP might be unnecessary.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

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

good point! The question though is whether WDDM overhead indeed is NOT an issue with OpenMM.
Is there anyone who can answer this question for sure?