StarPU Handbook
|
SCC support just needs the presence of the RCCE library.
MIC Xeon Phi support actually needs two compilations of StarPU, one for the host and one for the device. The PATH environment variable has to include the path to the cross-compilation toolchain, for instance /usr/linux-k1om-4.7/bin
The script mic-configure
can then be used to achieve the two compilations: it basically calls configure
as appropriate from two new directories: build_mic
and build_host
. make
and make install
can then be used as usual and will recurse into both directories.
The simplest way to port an application to MIC Xeon Phi or SCC is to set the field starpu_codelet::cpu_funcs_name, to provide StarPU with the function name of the CPU implementation. StarPU will thus simply use the existing CPU implementation (cross-rebuilt in the MIC Xeon Phi case). The functions have to be globally-visible (i.e. not static
) for StarPU to be able to look them up.
For SCC execution, the function starpu_initialize() also has to be used instead of starpu_init(), so as to pass argc
and argv
.
SCC programs are started through RCCE.
MIC programs are started from the host. StarPU automatically starts the same program on MIC devices. It however needs to get the MIC-cross-built binary. It will look for the file given by the environment variable STARPU_MIC_SINK_PROGRAM_NAME or in the directory given by the environment variable STARPU_MIC_SINK_PROGRAM_PATH, or in the field starpu_conf::mic_sink_program_path. It will also look in the current directory for the same binary name plus the suffix -mic
or _mic
.
The testsuite can be started by simply running make check
from the top directory. It will recurse into both build_host
to run tests with only the host, and into build_mic
to run tests with both the host and the MIC devices. Single tests with the host and the MIC can be run by starting ./loader-cross.sh ./the_test
from build_mic/tests
.