Project administrator
Project developer
Project tester
Project scientist
Help desk expert
Send message
Joined: 26 Oct 16
Posts: 321
Credit: 103,382
RAC: 0
The project is restarted with new native BOINC apps and additional computational scenario.
Now the large WUs can be assigned only to the GPU and the small ones only to the CPU.
GPU apps do not require dedicated CPU core by default anymore. If you notice any performance issues caused by this, consider using custom app configuration. Place this file in the project's folder.
The apps of this project do not make checkpoints. If stopped, the task will be restarted from the beginning. The task execution time should not exceed 10 minutes for moderate PCs. However, some tasks may take longer to complete on low-end PCs. This is particularly true for low-end GPUs. If the execution time of tasks is unacceptably high for your GPU, consider disabling it in the "Preferences for this project" in your profile page.
The project is in beta-testing stage. Bugs are more than likely. However, all the results obtained during this stage will be included in the final database If no critical errors are found.
Thank you for participating!
/ 
Reply
Quote
The first 18 work units ran perfectly on my GTX 1060 (Win7 6-bit, 373.06 drivers). The times ranged from 3 to 92 seconds, with the average being around 35 seconds. There were no problems with CPU support; it reserved a core on my i7-4771 while other cores were in use for other BOINC projects. But the weather is a little warm here, so I will give others the opportunity to get some for a while.
/ Reply
Quote
The times ranged from 3 to 92 seconds, with the average being around 35 seconds.
Yes, very variable lenght on my little gpu (from 25 seconds to 8 minutes).
But all wus seems to be ok, no bugs until now
/ Reply
Quote
GPU apps do not require dedicated CPU core by default anymore.
CUDA apps still use one full core.
/ Reply
Quote
Project administrator
Project developer
Project tester
Project scientist
Help desk expert
Send message
Joined: 26 Oct 16
Posts: 321
Credit: 103,382
RAC: 0
CUDA apps still use one full core.
Yes, this happens due to cudaThreadSynchronize() calls between kernel executions. I probably need to switch to cudaSetDeviceFlags(cudaDeviceBlockingSync). However, I meant that vacant CPU core is not required anymore to start the GPU app, so now the client will launch the GPU app even if all CPU cores are busy.
/ Reply
Quote
Welcome Back!
For those of who have closets full of Droid/ARM devices ;) ... any chance for clients for them?
/ Reply
Quote
Project administrator
Project developer
Project tester
Project scientist
Help desk expert
Send message
Joined: 26 Oct 16
Posts: 321
Credit: 103,382
RAC: 0
CUDA apps still use one full core.
Yes, this happens due to cudaThreadSynchronize() calls between kernel executions. I probably need to switch to cudaSetDeviceFlags(cudaDeviceBlockingSync). However, I meant that vacant CPU core is not required anymore to start the GPU app, so now the client will launch the GPU app even if all CPU cores are busy.
I've tested it. Indeed, CPU usage drops down to zero in cudaSetDeviceFlags(cudaDeviceBlockingSync) approach. However, if you run the computations and the diaplay on the same GPU, the system will be almost unusable during the computations. So, I don't know, what is better.
/ Reply
Quote
CUDA apps still use one full core.
Yes, this happens due to cudaThreadSynchronize() calls between kernel executions. I probably need to switch to cudaSetDeviceFlags(cudaDeviceBlockingSync). However, I meant that vacant CPU core is not required anymore to start the GPU app, so now the client will launch the GPU app even if all CPU cores are busy.
I've tested it. Indeed, CPU usage drops down to zero in cudaSetDeviceFlags(cudaDeviceBlockingSync) approach. However, if you run the computations and the diaplay on the same GPU, the system will be almost unusable during the computations. So, I don't know, what is better.
You probably would have to split one long running kernel into multiple short ones, so GPU would have chance to refresh display. Unfortunately GPUs does not support preemption like CPU does. BTW, some projects allows to configure kernel size, maybe you should go this way too?
____________
/ Reply
Quote
Project administrator
Project developer
Project tester
Project scientist
Help desk expert
Send message
Joined: 26 Oct 16
Posts: 321
Credit: 103,382
RAC: 0
You probably would have to split one long running kernel into multiple short ones, so GPU would have chance to refresh display. Unfortunately GPUs does not support preemption like CPU does. BTW, some projects allows to configure kernel size, maybe you should go this way too?
The kernel execution time is set to be less than 20 ms if the GPU runs both the computations and the display, otherwise the system would be unusable even with cudaThreadSynchronize() calls. Unfortunately, if I set blocking kernel calls via cudaSetDeviceFlags() and remove cudaThreadSynchronize(), refresh rate becomes very unstable despite short execution time of the kernels.
/ Reply
Quote