Playing nice With Others

[trleith]

I have F@H 8-4 on a Linux system that up until now hasn't used the GPU for very much at all -- F@H has basically gotten it all. But I have a new project where I need a GUI on the machine, right now Xorg + xrdp + GNOME. Today is the first day I've gotten that to work, with the invaluable assistance of one of the xrdp developers.

When F@H is running, it's typically using >95% of the NVIDIA 1060 GPU. I want it to render GUI windows as well. Rendering GUI resources isn't very taxing, I know. Sometimes the GPU transcodes video. Other times it's running ffmpeg. I going to install DaVinci Resolve or something similar that will make demands.

I am told that although I can nice -19 the F@H process that feeds the GPU, the scheduling available in the GPU itself is very limited and I don't know whether it's user-configurable at all. I don't know how long each "chunk" runs on the GPU, or whether GPU load figures into whether the system is "idle". How can I have F@H detect when there's another process, especially an interactive user who wants the GPU and throttle itself back? Or am I hollerin' before I'm hurt?

What's the wisdom?

Code: Select all

root@homeserver:~# nvidia-smi
Wed Apr 16 10:54:36 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 560.35.03              Driver Version: 560.35.03      CUDA Version: 12.6     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1060 3GB    Off |   00000000:0D:00.0 Off |                  N/A |
| 75%   82C    P2            103W /  120W |     306MiB /   3072MiB |     98%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A    972030      G   /usr/lib/xorg/Xorg                              4MiB |
|    0   N/A  N/A   2636737      C   ...2009-64bit-release-8.2.0/FahCore_26        204MiB |
|    0   N/A  N/A   2704684      G   /usr/lib/xorg/Xorg                              8MiB |
|    0   N/A  N/A   2704821      G   /usr/lib/xorg/Xorg                             36MiB |
|    0   N/A  N/A   2704939      G   gnome-shell                                    44MiB |
+-----------------------------------------------------------------------------------------+

[muziqaz]

None of what you are thinking is happening with GPUs. FAH does either 100% of the GPU or 0%. User intervention is required if one wants to use GPU for other things. Which means, you need to pause manually and un-pause manually

[BobWilliams757]

We run DaVinci Resolve, surf the web, convert music files, stream shows, and essentially anything else we would normally do in a day without ever pausing or even noticing that FAH is running in most cases. Windows takes cae of things fairly seemlessly, and the hit to folding is minor in most cases. Unless you are using some type of buggy software or need major demands for games or something, there is no need to pause folding.

As example, many claim DaVinci resolve is very resource hungry, but in fact it's really not. I've run it while folding while temporarily down to only 8 gigs of ram.

Unless a person is using some type of unstable software that crashes a system, there is no reason not to multitask on a stable computer. I've been doing it for decades.

[arisu]

Unless you are gaming, you are not likely to see much noticeable degradation of performance by folding. Not if all you want is for it to draw windows. And video transcoding won't suffer at all. Video encode and decode (nvenc and nvdec) uses dedicated silicon for that purpose, not the CUDA cores that folding uses. So there's no battle for resources even when encoding or decoding, so long as your GPU isn't overheating.

In theory you could reduce GPU utilization by applying a cpu.max cgroups policy to the CPU core. That will starve the GPU so it will be idling a higher percentage of the time. But it will be a bit of a guessing game because limiting the CPU core that feeds the GPU to 50% won't bring GPU usage down to 50%. It might go down to just 90%, or maybe it will fall all the way down to 10%. And it might be different for different WUs. Playing with niceness won't do anything btw and even changing it to SCHED_IDLE won't do anything. No change to the CPU scheduler will change how the GPU's (virtual lack of) scheduling works.

If you are having performance issues then you could try disabling DRI2 or whatever it is called in Xorg, which will make it fall back to software rendering. That's more taxing on the CPU but it won't be using the GPU much except to pass the pixels directly to your display.

[appepi]

I tested this "concurrent GPU demand" problem a little - but only for Windows - by running the Unigine Superposition 1.0 benchmark as the non-FaH demand, with and without a concurrent Core 22 Fah Project [19600 (796,0,5772)] on Z805, with an ASUS Turbo GTX 1080. I also ran it with GPU Tweak II OC mode settings, and then with the normal temperature/power limitations I use for FaH. I could not systematically assess the impact of Superposition on the Fah job, and thus inferred it from the reverse effect of concurrent Fah job on the Superposition Benchmarks. The settings for Superposition were 1080P High and DirectX API. Note that I am NOT using the new Fah Control. Note that Fah was loaded but paused for the "without concurrent Fah" runs.

Superposition, OC settings, without concurrent Fah: Score 7428 Min FPS 38/Avg FPS 56/Max FPS 88 Max temp 83 deg C
Superposition, Fah settings, without concurrent Fah: Score 8199 Min FPS 36/Avg FPS 61/Max FPS 90 Max temp 73 deg C

Superposition, OC settings, with concurrent Fah: Score 7155 Min FPS 28/Avg FPS 54/Max FPS 79 Max temp 84 deg C
Superposition, Fah settings, with concurrent Fah: Score 7215 Min FPS 22/Avg FPS 54/Max FPS 78 Max temp 73 deg C

There was presumably some competition for resources since the minimum and maximum FPS Superposition benchmarks were worse by about 10 FPS when Fah was running, but the averages were less affected. Note also that Superposition performance with and without temperature controls was much the same.

[arisu]

There won't be very much competition between the FAH and Uningine Superposition. FAH stresses the CUDA cores, recruiting as many as it can and trying to keep their clocks as high as they can go while staying within thermal and power limits. The Uningine benchmark is more representative of graphical loads. It will use CUDA cores to run shaders sure, but it will also make heavy use of available memory bandwidth, the RT cores, TMUs, and ROPs which FAH has no use for. It makes sense that the Uningine benchmark was not too severely affected by FAH.

And compared to that, rendering a simple GUI that's static most of the time is nothing.

[appepi]

In case it isn't obvious, I am utterly ignorant about how FaH uses my GPUs, but it don't make no never-mind as long as it rewards them with roughly the same PPD for the same cost in electricity across projects. But I figured the Superposition test would provide a fair indication of how gaming use might be affected by concurrent FaH use.

I have just repeated the sequence of tests - albeit with a different Core 22 project from the same family [19600(22,0,7348)] This time I used the Geekbench 6(.0.0) GPU Compute benchmark as the concurrent load, using both the OpenCL and Vulkan API's, and both the GPU Tweak O/C settings and my Fah Setting with temperature control. And, since (unlike Superposition) GB6 doesn't need to use the whole screen, I could also watch the TPF effect in FaHControl (7.6.21).

OpenCL API GB6 compute results:
O/C setting: GB6 Compute = 43,380 (-FaH) Vs 37,173 (+FaH)
FaH setting: GB6 Compute = 42,642 (-FaH) Vs 34,377 (+FaH)

Vulkan API GB6 compute results:
O/C setting: GB6 Compute = 64,394 (-FaH) Vs 52,511 (+FaH)
FaH setting: GB6 Compute = 59,626 (-FaH) Vs 48,099 (+FaH)

In both cases the TPF went from around 32 seconds to around 45 seconds when the GB6 load was on. According to LAR Systems the former is 6% better than average based on 2431 runs by 1080s on Project 19600, while the latter time is about 30% below average. The message I took away was that FaH GPU use politely moves into the background to let systems meet Higher priority tasks that need (some of) the same resources, but there is still a cost to both the Fah processes and the other/s.

[As a minor footnote, Z805 is an odd beast that is a dual boot W7Pro/W10Pro Z800 with only 1 channel of 4GB RAM and 1x Xeon 5620 (4C 8T), whose main task in my system is supporting 6x4TB NAS HDDs in a RAID10 array via a LSI 9261-8i card in the second PCIe2 x16 slot, as backup for my NAS. When I first fired it up for these tests it was in W7 and I had forgotten that it had the default Fah Settings and thus ran a CPU slot as well as the GPU slot. In those circumstances the Superposition performance was greatly degraded by concurrent FaH, with obvious stuttering. This was presumably competition for the CPU since it went away when I killed the CPU slot. Since I only do GPU folding these days that is neither here nor there for me but the result might be relevant to others.]