Applications that use coprocessors

This document describes BOINC's support for applications that use coprocessors such as

• GPUs
• Cell SPEs

We'll assume that these resources are allocated rather than scheduled: i.e., an application using a coprocessor has it locked while the app is in memory, even if the app is suspended by BOINC or descheduled by the OS.

Proposed design

The BOINC client probes for coprocessors and reports them in scheduler requests. The XML looks like:

<coprocs>
   <coproc_cuda>
      <count>1</count>
      <name>GeForce 8800 GT (1)</name>
      <totalGlobalMem>...</totalGlobalMem>
      ...
   </coproc_cuda>
</coprocs>

An app_version record (in the server DB) has a character string field class.

The scheduler is linked with a project-supplied function

bool analyze_app(HOST&, char* class, HOST_USAGE&);

struct HOST_USAGE {
   COPROCS coprocs;   // coprocessors used by the app (name and count)
   double ncpus;      // #CPUs used by app (may be fractional)
   double flops;      // estimated FLOPS
   char opaque[256];  // passed to the app in init_data.xml
};

The HOST argument describes the host's CPU(s), and includes a field 'coprocs' listing its coprocessors.

The function returns true if the host's resources are sufficient for the app version. If true, it populates the HOST_USAGE structure.

When deciding whether to send a job to a host, the scheduler examines all latest-version app_versions for the platform, and selects the one for which flops is greatest.

The scheduler reply includes, for each app version, an XML encoding of HOST_USAGE.

The client keeps track of coprocessor allocation, i.e. how many instances of each are free. It only runs an app if enough instances are available.

The client uses app_version.usage.flops to estimate job completion times.

Questions

• How does BOINC know if non-BOINC applications are using resources?

Possible future additions

• Allow app_versions to specify min and max requirements (and have a corresponding allocation scheme in the client).
• Let projects define their own resources, unknown to BOINC, and have "probe" programs (using the assigned-job mechanism) that surveys the resources on each host.
• Store the resource descriptions in the DB (or maybe flat files), so that you can study your host population.