430_mic_support.doxy 4.7 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798
  1. /* StarPU --- Runtime system for heterogeneous multicore architectures.
  2. *
  3. * Copyright (C) 2009-2020 Université de Bordeaux, CNRS (LaBRI UMR 5800), Inria
  4. *
  5. * StarPU is free software; you can redistribute it and/or modify
  6. * it under the terms of the GNU Lesser General Public License as published by
  7. * the Free Software Foundation; either version 2.1 of the License, or (at
  8. * your option) any later version.
  9. *
  10. * StarPU is distributed in the hope that it will be useful, but
  11. * WITHOUT ANY WARRANTY; without even the implied warranty of
  12. * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  13. *
  14. * See the GNU Lesser General Public License in COPYING.LGPL for more details.
  15. */
  16. /*! \page MICSupport MIC Xeon Phi Support
  17. \section MICCompilation Compilation
  18. MIC Xeon Phi support actually needs two compilations of StarPU, one for the host and one for
  19. the device. The <c>PATH</c> environment variable has to include the path to the
  20. cross-compilation toolchain, for instance <c>/usr/linux-k1om-4.7/bin</c> .
  21. The <c>SINK_PKG_CONFIG_PATH</c> environment variable should include the path to the
  22. cross-compiled <c>hwloc.pc</c>.
  23. The script <c>mic-configure</c> can then be used to achieve the two compilations: it basically
  24. calls <c>configure</c> as appropriate from two new directories: <c>build_mic</c> and
  25. <c>build_host</c>. <c>make</c> and <c>make install</c> can then be used as usual and will
  26. recurse into both directories. If different \c configure options are needed
  27. for the host and for the mic, one can use <c>--with-host-param=--with-fxt</c>
  28. for instance to specify the <c>--with-fxt</c> option for the host only, or
  29. <c>--with-mic-param=--with-fxt</c> for the mic only.
  30. One can also run StarPU just natively on the Xeon Phi, i.e. it will only run
  31. directly on the Phi without any exchange with the host CPU. The binaries in
  32. <c>build_mic</c> can be run that way.
  33. For MPI support, you will probably have to specify different MPI compiler path
  34. or option for the host and the device builds, for instance:
  35. \verbatim
  36. ./mic-configure --with-mic-param=--with-mpicc="/.../mpiicc -mmic" \
  37. --with-host-param=--with-mpicc=/.../mpiicc
  38. \endverbatim
  39. In case you have troubles with the \c coi or \c scif libraries (the Intel paths are
  40. really not standard, it seems...), you can still make a build in native mode
  41. only, by using <c>mic-configure --enable-native-mic</c> (and notably without
  42. <c>--enable-mic</c> since in that case we don't need \c mic offloading support).
  43. \section PortingApplicationsToMIC Porting Applications To MIC Xeon Phi
  44. The simplest way to port an application to MIC Xeon Phi is to set the field
  45. starpu_codelet::cpu_funcs_name, to provide StarPU with the function
  46. name of the CPU implementation, so for instance:
  47. \verbatim
  48. struct starpu_codelet cl =
  49. {
  50. .cpu_funcs = {myfunc},
  51. .cpu_funcs_name = {"myfunc"},
  52. .nbuffers = 1,
  53. }
  54. \endverbatim
  55. StarPU will thus simply use the
  56. existing CPU implementation (cross-rebuilt in the MIC Xeon Phi case). The
  57. functions have to be globally-visible (i.e. not <c>static</c>) for
  58. StarPU to be able to look them up, and \c -rdynamic must be passed to \c gcc (or
  59. \c -export-dynamic to \c ld) so that symbols of the main program are visible.
  60. If you have used the starpu_codelet::where field, you additionally need to add in it
  61. ::STARPU_MIC for the Xeon Phi.
  62. For non-native MIC Xeon Phi execution, the 'main' function of the application, on the sink, should call starpu_init() immediately upon start-up; the starpu_init() function never returns. On the host, the 'main' function may freely perform application related initialization calls as usual, before calling starpu_init().
  63. For MIC Xeon Phi, the application may programmatically detect whether executing on the sink or on the host, by checking whether the \ref STARPU_SINK environment variable is defined (on the sink) or not (on the host).
  64. \section LaunchingPrograms Launching Programs
  65. MIC programs are started from the host. StarPU automatically
  66. starts the same program on MIC devices. It however needs to get
  67. the MIC-cross-built binary. It will look for the file given by the
  68. environment variable \ref STARPU_MIC_SINK_PROGRAM_NAME or in the
  69. directory given by the environment variable \ref STARPU_MIC_SINK_PROGRAM_PATH,
  70. or in the field
  71. starpu_conf::mic_sink_program_path. It will also look in the current
  72. directory for the same binary name plus the suffix <c>-mic</c> or
  73. <c>_mic</c>.
  74. The testsuite can be started by simply running <c>make check</c> from the
  75. top directory. It will recurse into both <c>build_host</c> to run tests with only
  76. the host, and into <c>build_mic</c> to run tests with both the host and the MIC
  77. devices. Single tests with the host and the MIC can be run by starting
  78. <c>./loader-cross.sh ./the_test</c> from <c>build_mic/tests</c>.
  79. */