|
One can configure the app through some parameters in the supplied app_info.xml.
This is done by editing the line
<cmdline></cmdline>
There are several options one can put in there, the order does not matter. If the same argument
is given twice, the last one counts. Remember that for editing the app_info.xml one should take
the same precautions as for the installation of the application, i.e. one should stop BOINC
completely and restart it afterwards.
Options:
kernel frequency: f (default 30)
The application determines the size of the work packages sent to the GPU in a dynamic manner. It
tries to get the number of executed packages per second above the value specified here by
splitting them to smaller ones. The OS is completely blocked from accessing the graphics card for
the duration of one package leading to a somewhat sluggish behaviour of the user interface.
Limiting the size and therefore reducing the execution time per package creates more opportunities
for the OS to slip in between two work packages and to react to user input. The default value of
30 Hz is tuned for usability of the system. Reducing it could increase the throughput of the app
slightly.
Example:
<cmdline>f10</cmdline>
The app will try to run 10 work packages per second (limits the execution time to 100ms or shorter).
Wait factor: w (default 1.0)
The app tries to release the CPU during the the GPU computations. It does so by predicting
the runtime for the GPU calls and send the CPU thread to sleep for that time. One can manually
correct the prediction of the application with this factor. When raising it, the CPU thread
sleeps longer, decreasing the value will lead to a faster wakeup of the thread. After that time,
the polling of the GPU starts. Setting this value to 0.0 turns off the release of the CPU.
Default is of course a value of 1.0. If you see a low GPU load, you can try to decrease it (if
you have a load of 80%, set it to 0.8). If you see a high CPU load, a slight increase of this
value may help. Increase it too much and it will affect the crunching speed. You could use this
for throttling of the GPU in case the high GPU load leads to a very sluggish behaviour of the
user interface or even VPU recover events. Setting w1.1 could improve the situation (see also
the f, b and p options).
Example:
<cmdline>w1.3</cmdline>
This would increase the sleep time by 30% in relation to the prediction.
Maximum GPU RAM use: r (default 33.4)
The application allocates memory on the graphics card to store the calculated steps. Increasing
the size can offer more parallel data to process and the f option more room to get the real
setting closer to itS specified value. But you should not increase the RAM usage, if more than
one WU are processed concurrently. The value is given in percent relative to the installed amount.
Too high or too low values can crash the application, so be careful! See also the explanation
about the graphics RAM usage at the end of the readme.
Example:
<cmdline>r40</cmdline>
This would increase the maximum RAM usage to 40%.
priority: p (default 1)
All BOINC applications normally run with the lowest possible priority to not disturb other
applications. This can lead to a low GPU load, as it may be not possible to fire up the next tasks
if all cores of the CPU are under load. Raising the priority may help here. BOINC recommends a
slightly increased priority for GPU applications. This setting is the default. Possible values:
p0: idle priority, used by CPU BOINC applications
p1: normal priority in idle priority class, this is the default and recommended by BOINC for GPUs
p2: normal priority in normal priority class
p3: normal priority in high priority class, use with care!
The priority will affect how much time it takes for the the app to get back control if it releases
its time slice (see also option b).
Example:
<cmdline>p2</cmdline>
This raises the priority to normal (the same as all normal user applications have as default).
polling behavior of the GPU within the Brook runtime: b (default 1)
See the option w for starters. If that time has elapsed, the GPU polling starts. This can be done
by continously checking if the task has finished (b-1), enabling the fastest runtimes, but potentially
creating a high CPU load (a bit dependent on driver version). Second possibility is to release the time
slice allotted by the OS, so other apps can run (b0). The catch is that there is some interaction with
the priority. The time slice is only released to other tasks of the same priority. So raising the priority
effectively disables the release and the behavior is virtually identical to setting this parameter
to -1. If a raised priority and a low CPU time is wanted, one should leave it at the default of 1. This
suspends the task for at least 1 millisecond, enabling also tasks of lower priority to use the CPU in the
meantime.
Possible values:
b-1: busy waiting
b0: release time slice to other tasks of same priority
b1: release time slice for at least 1 millisecond
See also options p and w.
Example:
<cmdline>b-1</cmdline>
Enable busy waiting (no release of the time slice during polling).
The options can be combined in arbitrary order. Therefore the following argument list is valid:
<cmdline>w0.9 f20 r50 p2 b1</cmdline>
(wait factor 0.9, frequency 20Hz, 50% RAM used at max, normal priority, and CPU friendly polling) Deprecated options (use with extreme care, will likely be removed in future versions)
Number of concurrent WUs: n (default 3)
It is possible to define the maximum number of concurrently running WUs per GPU. Default value is
three. If the BOINC client schedules more WUs to run, they are put to a wait state and not crunched
until a GPU finishes another WU. Running more than a single WU can raise the efficiency of the GPU
as the remaining CPU calculations for one WU can be hidden during the wait for the GPU of another
WU. More than 2 WUs don't help anymore and running too many WUs concurrently first slow down the
calculation and finally crash if there is not enough memory. But as mentioned, more than 2 won't
help either way. If the high GPU load leads to a very sluggish behaviour of the user interface or
even VPU recover events, limiting the app to one WU (n1) could improve the situation (look also
into the w and f options). Do not use it with an ATI aware BOINC client! It should be ignored in
that case. If you run more than one GPU project (Collatz and Milkyway), this will be a shared
setting and should be the same for both in all cases!
Example:
<cmdline>n2</cmdline>
The app will run a maximum of two WUs per GPU.
Exclusion of GPUs: x (default none)
If a certain GPU should not be used by the app, one can exclude it. The GPU number has to be in
the range 0..31. The first GPU in the system has the number 0. This option can be used multiple
times. Per default, all supported ATI GPUs are used. Do not use it with an ATI aware BOINC client!
It should be ignored in that case. But there may be some unwanted side effects.
Example:
<cmdline>x1 x2</cmdline>
The app will not use the second and the third GPU in the system.
如果能全部翻译完,一定会帮助所有GPU加速的同学,请各位有时间的帮下忙
[ 本帖最后由 ledled 于 2009-10-3 20:48 编辑 ] |
|