there are two levels of reason: project-specific and global
(i.e. buffer full).
Check both reasons when in the no-fetch message.
Include CPU in type_name_to_num()
When showing a system size (total RAM or VRAM, disk, swap)
use GB (with %.2f) instead of MB.
When showing the RAM or disk usage of particular job, use MB.
by means other than OpenCL.
Do this using the Mac 'system_profiler' program, as suggested by Charlie.
Also:
- improve the comments in GPU detection code.
For something this complex, we need, at the minimum,
a comment saying what each function does.
- avoid field names like 'version' and 'name'.
Version of what? name of what?
For now, it's detected only via OpenCL (like Intel GPUs).
Eventually we'll detect via Metal as well.
Plan classes for Apple GPU must include 'apple_gpu' in their name.
The changes are mostly copy-and-paste of Intel GPU code.
I hate duplicate code but I don't know how to fix.
When the client reports an OpenCL GPU (other than NVIDIA/AMD/Intel)
in a scheduler request, the "type" field is the model name.
In the case of Apple GPUs this is "Apple M1" or "Apple M2"
(and other models as time goes on).
The type field is used in plan class descriptions.
In the case of Apple the models are (I think) equivalent software-wise,
and it would be a nuisance to have to make a new plan class
(and app versions) for each model.
So - in the case of Apple GPUs - use "Apple" as the type.
The model name is still available (as opencl_prop.name) if needed.
There were two problems:
1) We weren't fetching work unless benchmarks had been run
(since a scheduler request must include a p_fpops value).
Fix: if --skip_cpu_benchmarks set, pretend that we ran benchmarks
and p_fpops is 1 GFLOPS
2) adding a project via the cmdline (--attach_project)
wasn't setting a flag to fetch the project's scheduler list.
Also: the new way of clearing structures (copying a static instance to *this)
causes a startup hang if the default constructor calls clear().
To fix this, have the static instance use a constructor
that doesn't call clear()
Also: fix message about libc version.
"[foobar] ...." means that the message is conditional on <debug_foobar>
Instead: declare a static const instance (whose data members are zero)
and copy that.
This avoid the error-prone need to assign each member,
and it works even if there are virtual function tables.
If the calculated peak FLOPS is nonpositive or greater than 1000 TeraFLOPS,
use a default (100 GigaFLOPS) instead.
Server: use the value reported by client rather than recalculating it;
the client is probably more recent than you are.
Sanity-check it in any case.
A small attempt at future proofing things. The value is 1 on my new GPU, but might not be on higher end cards. Docs implies it should be part of the calculation.
Use AMD's vendor specific extension if it is available to calculate the total number of shaders and determine the peak FLOP rate from that.
My new GPU I got for Christmas was only reporting 30% of its peak FLOP rate and does not support CAL.
If an NVIDIA GPU is detected only by OpenCL we don't know how many
cores per proc it has.
Instead of assuming 8 (compute capability 1) assume 48 (CC 2).
We could assume 192 (CC 3) but better to err on the low side.
There was a bug where, when you suspend GPU activity,
GPU jobs show as suspended but are not actually suspended.
This was because of recent changes to distinguish GPU and non-GPU coprocs.
Change things so that coprocs are by default GPUs.
If you want to declare a non-GPU coproc in your cc_config.xml,
you much put <non_gpu/> in its <coproc> element.
I.e. treat miner ASICs as a distinct processor type;
send miner_asic jobs only if the client requests them.
Note: I was planning to do this in a more general way,
in which the scheduler wouldn't have a hard-wired list of processor types.
However, that would be a large code change,
so for now I just added miner_asic to the list of processor types
(nvidia, ati, intel_gpu),
and made various changes to get things to work.
Also: in the job dispatch logic, try to send coproc jobs
before CPU jobs.
That way if e.g. there's a limit on jobs in progress,
we'll preferentially send coproc jobs.
We weren't copying the request fields from RSC_WORK_FETCH to COPROC.
Do this, and clean up the code a bit.
Note: the arrays that parallel the COPROCS::coprocs array
are a bit of a kludge; that stuff logically belongs in COPROC.
But it's specific to the client, so I can't put it there.
Maybe I could do something fancy with derived classes, not sure.
A "generic" coprocessor is one that's reported by the client,
but's not of a type that the scheduler knows about (NVIDIA, AMD, Intel).
With this commit the following works:
- On the client, define a <coproc> in your cc_config.xml
with a custom name, say 'miner_asic'.
- define a plan class such as
<plan_class>
<name>foobar</name>
<gpu_type>miner_asic</gpu_type>
<cpu_frac>0.5</cpu_frac>
<plan_class>
- App versions of this plan class will be sent only to hosts
that report a coproc of type "miner_asic".
The <app_version>s in the scheduler reply will include
a <coproc> element with the given name and count=1.
This will cause the client (at least the current client)
to run only one of these jobs at a time,
and to schedule the CPU appropriately.
Note: there's a lot missing from this;
- app version FLOPS will be those of a CPU app;
- jobs will be sent only if CPU work is requested
... and many other things.
Fixing these issues requires a significant re-architecture of the scheduler,
in particular getting rid of the PROC_TYPE_* constants
and the associated arrays,
which hard-wire the 3 fixed GPU types.
For now, handle AMD/ATI, NVIDIA or Intel GPUs as before. But for other, "new" vendors, we treat each device as a separate resource, creating an entry for each instance in the COPROCS::coprocs[] array and copying the device name COPROC::opencl_prop.name into the COPROC::type field (instead of the vendor name.)
For devices from "new" vendors, set <gpu_type> field in init_data.xml file to the vendor string supplied by OpenCL. This should allow boinc_get_opencl_ids() to work correctly with these "new" devices without modification.
David Anderson