WARNING Do not upgrade to 375/376.xx drivers (for xx<48)

[Leonardo]

Very well then, I'll take the plunge and install 378.92. I have several GPUs folding. I'll report back if I see diminished production from my current drivers, 373.06.

[Leonardo]

Back to 373.06.

The experiment with 378.92 is over. Having run quite a few work units on several GTX 1080s and a GTX 1070, here are my observations concerning GPU Folding, 387.92 vs 373.06:

- all work units, all video cards, experienced lower performance, measured by higher frame completion times
- the more difficult work units - those which take the longest per frame, experienced proportionally greater production slowdowns
- increased frame times ranged from 3 to 10 seconds

[foldy]

So there are 2 explanations:
1) FAH workaround is still active and performance would increase when it gets removed again
2) FAH workaround is already removed and they changed something else in OpenCL driver which decreases FAH performance.
I hope for first because there the solution is known.

[SombraGuerrero]

There have now been a hand full of game ready driver updates since Core18 was fully deployed. I have read the release notes for each one since and there has been no indication of the JIT compiler's app profile for FAH being removed. I just wonder if Nvidia is still planning to remove it, if they still have another legitimate reason for keeping it in, or if they just plum forgot it was there

[Adam_Ford]

viewtopic.php?f=24&t=29633#p294232

[SombraGuerrero]

So, if we take that at face value, we would then have to conclude that the continued reduction in performance may be coming from elsewhere, which to foldy's point, sets us back to square one for anyone insistent on optimal PPD.

[bruce]

So, if we take that at face value, we would then have to conclude that the continued reduction in performance may be coming from elsewhere, which to foldy's point, sets us back to square one for anyone insistent on optimal PPD.

Testing (& development?) is still being done on OpenMM. NVidia's hotfix is in all of their current releases but that's temporary. At some point they plan to remove that code which MIGHT restore a fraction of the performance loss. Both the change introduced by the hotfix and by the change to OpneMM address the same issue but in somewhat different ways. The OpenMM guys expect that their fix will be more efficient, allowing NV to issue new drivers that remove the hotfix code. This should restore some portion of the performance loss.

[SombraGuerrero]

This is precisely why I don't like taking things at face value. This is at least very hopeful news!

[bruce]

The testing process of the OpenMM changes has (or will) ascertain that the hot-fix is nn longer needed. Part of that testing will gather performance data, too' It's reasonable to assume results will vary somewhat depending on which GPU and which Project is involved, so it'll be up to volunteers like yourself to report your findings of specific combinations.

[Aurum]

Back to 373.06.

The experiment with 378.92 is over. Having run quite a few work units on several GTX 1080s and a GTX 1070, here are my observations concerning GPU Folding, 387.92 vs 373.06:

- all work units, all video cards, experienced lower performance, measured by higher frame completion times
- the more difficult work units - those which take the longest per frame, experienced proportionally greater production slowdowns
- increased frame times ranged from 3 to 10 seconds

How were you able to so precisely measure this difference
Do you save a reference WU so it's apples and apples

[Leonardo]

The baseline, which I used to compare times-per-frame is a log I've been maintaining for a few months. The log documents work units' times per frame. As for measurements, I use FAHControl's Selected Work Unit monitoring utility. So yes, apples to apples, over and over again. Using five GPUs, I compared enough work units, some with multiple runs, that the trend stood out clearly. Not one work unit that processed with 387.92 completed as quickly as the baseline time for the same work unit documented in the log.

[Aurum]

The baseline, which I used to compare times-per-frame is a log I've been maintaining for a few months. The log documents work units' times per frame. As for measurements, I use FAHControl's Selected Work Unit monitoring utility. So yes, apples to apples, over and over again. Using five GPUs, I compared enough work units, some with multiple runs, that the trend stood out clearly. Not one work unit that processed with 387.92 completed as quickly as the baseline time for the same work unit documented in the log.

Thank you for doing that!!!
I've reverted my rigs back to 373.06. (Strangely, F@H shows them as 373.6 but before I had 369.30. What logic deletes an interior zero and not a trailing zero?)