ONNX Runtime für Inferencing erstellen

Folgen Sie den untenstehenden Anweisungen, um ONNX Runtime für Inferencing zu erstellen.

Inhalt

CPU

Einfacher CPU-Build

Voraussetzungen

  • Source-Baum auschecken

     git clone --recursive https://github.com/Microsoft/onnxruntime.git
     cd onnxruntime
    
  • Installieren Sie Python 3.10+.

  • Installieren Sie cmake-3.28 oder höher.

    Unter Windows empfehlen wir, die neueste Version von WinGet zu beziehen. Bitte führen Sie aus:

      winget install -e --id Kitware.CMake
    

    Unter Linux können Sie es von pypi beziehen. Bitte führen Sie aus:

      python3 -m pip install cmake
      which cmake
    

    Wenn die obigen Befehle fehlschlugen, holen Sie sich CMake bitte manuell von https://cmake.org/download/.

    Nach der Installation können Sie Folgendes ausführen:

      cmake --version
    

    , um zu überprüfen, ob die Installation erfolgreich war.

Bauanleitungen

Windows

Öffnen Sie die Developer Command Prompt für die Visual Studio-Version, die Sie verwenden möchten. Dies richtet die Umgebung korrekt ein, einschließlich der Pfade zu Ihrem Compiler, Linker, Dienstprogrammen und Header-Dateien.

.\build.bat --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync

Der Standard-Windows-CMake-Generator ist Visual Studio 2022. Andere Visual Studio-Versionen werden nicht unterstützt.

Wenn Sie ein ARM64-Binary auf einer Windows ARM64-Maschine erstellen möchten, können Sie denselben Befehl wie oben verwenden. Stellen Sie einfach sicher, dass Ihr Visual Studio, CMake und Python alle ARM64-Versionen sind.

Wenn Sie ein ARM64- oder ARM64EC-Binary auf einer Windows x86-Maschine cross-kompilieren möchten, müssen Sie "–arm64" oder "–arm64ec" zum obigen Build-Befehl hinzufügen.

Bitte stellen Sie sicher, dass Ihr Python-Interpreter eine 64-Bit-Windows-Anwendung ist. Wir unterstützen 32-Bit-Builds nicht mehr.

Linux

./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync

macOS

Standardmäßig ist ONNX Runtime für eine minimale Ziel-macOS-Version von 13.3 konfiguriert. Die freigegebene Bibliothek in den Nuget(s) und das Python-Wheel können auf macOS-Versionen von 13.3+ installiert werden.

Wenn Sie Xcode verwenden möchten, um onnxruntime für x86_64 macOS zu erstellen, fügen Sie das Argument --use_xcode zur Befehlszeile hinzu.

Ohne dieses Flag wird der CMake-Build-Generator standardmäßig Unix makefile sein.

Heutzutage sind Mac-Computer entweder Intel-basiert oder Apple-Silicon-basiert. Standardmäßig generiert das Build-Skript von ONNX Runtime nur Bits für die CPU-ARCH, die die Build-Maschine hat. Wenn Sie cross-kompilieren möchten: generieren Sie arm64-Binaries auf einem Intel-basierten Mac-Computer oder generieren Sie x86-Binaries auf einem Mac-System mit Apple Silicon, können Sie die CMake-Variable "CMAKE_OSX_ARCHITECTURES" setzen. Zum Beispiel

Build für Intel-CPUs

./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync --cmake_extra_defines CMAKE_OSX_ARCHITECTURES=x86_64

Build für Apple-Silicon-CPUs

./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync --cmake_extra_defines CMAKE_OSX_ARCHITECTURES=arm64

Build für beide

./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync --cmake_extra_defines CMAKE_OSX_ARCHITECTURES="x86_64;arm64"

Der letzte Befehl generiert ein Fat-Binary für beide CPU-Architekturen.

Hinweis: Unit-Tests werden aufgrund des inkompatiblen CPU-Befehlssatzes beim Cross-Kompilieren übersprungen.

AIX

Unter AIX können Sie ONNX Runtime für 64 Bit erstellen mit

  • IBM Open XL Compiler Toolchain. Die minimal erforderliche AIX OS-Version ist 7.2. Sie benötigen die Compiler-PTF5-Version 17.1.2 (17.1.2.5).
  • GNU GCC Compiler Toolchain. Die minimal erforderliche AIX OS-Version ist 7.3. GCC-Version 10.3+ ist erforderlich.

Für IBM Open XL exportieren Sie untenstehende Umgebungseinstellungen.

ulimit -m unlimited
ulimit -d unlimited
ulimit -n 2000
ulimit -f unlimited
export OBJECT_MODE=64
export BUILD_TYPE="Release"
export CC="/opt/IBM/openxlC/17.1.2/bin/ibm-clang" 
export CXX="/opt/IBM/openxlC/17.1.2/bin/ibm-clang++_r"
export CFLAGS="-pthread -m64 -D_ALL_SOURCE -mcmodel=large -Wno-deprecate-lax-vec-conv-all  -Wno-unused-but-set-variable -Wno-unused-command-line-argument -maltivec -mvsx  -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare"
export CXXFLAGS="-pthread -m64 -D_ALL_SOURCE -mcmodel=large -Wno-deprecate-lax-vec-conv-all -Wno-unused-but-set-variable -Wno-unused-command-line-argument -maltivec -mvsx  -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare"
export LDFLAGS="-L$PWD/build/Linux/$BUILD_TYPE/ -lpthread"
export LIBPATH="$PWD/build/Linux/$BUILD_TYPE/"

Für GCC exportieren Sie untenstehende Umgebungseinstellungen.

ulimit -m unlimited
ulimit -d unlimited
ulimit -n 2000
ulimit -f unlimited
export OBJECT_MODE=64
export BUILD_TYPE="Release"
export CC="gcc" 
export CXX="g++"
export CFLAGS="-maix64 -pthread -DFLATBUFFERS_LOCALE_INDEPENDENT=0 -maltivec -mvsx   -Wno-unused-function -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare -fno-extern-tls-init -Wl,-berok "
export CXXFLAGS="-maix64 -pthread -DFLATBUFFERS_LOCALE_INDEPENDENT=0 -maltivec -mvsx  -Wno-unused-function -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare -fno-extern-tls-init -Wl,-berok "
export LDFLAGS="-L$PWD/build/Linux/$BUILD_TYPE/ -Wl,-bbigtoc -lpython3.9"
export LIBPATH="$PWD/build/Linux/$BUILD_TYPE"

Um den Build zu starten, führen Sie den folgenden Befehl aus:

./build.sh \
--config $BUILD_TYPE\
  --build_shared_lib \
  --skip_submodule_sync \
  --cmake_extra_defines CMAKE_INSTALL_PREFIX=$PWD/install \
  --parallel  
  • Wenn Sie das Paket in einem benutzerdefinierten Verzeichnis installieren möchten, geben Sie den Verzeichnispfad als Wert von CMAKE_INSTALL_PREFIX an.
  • Bei der IBM Open XL Compiler Toolchain fehlen unter AIX 7.2 möglicherweise einige Laufzeitbibliotheken wie libunwind.a, die für onnxruntime benötigt werden. Um dies zu beheben, können Sie die relevanten Dateisätze installieren.
  • --parallel-Option in den Build-Optionen. Wie der Name schon sagt, ist diese Option für parallele Builds und ressourcenintensive Optionen gedacht. Wenn Ihr System nicht über genügend Arbeitsspeicher pro CPU-Kern verfügt, kann diese Option übersprungen werden.
  • --allow_running_as_root wird benötigt, wenn der Root-Benutzer den Build auslöst.

Hinweise

  • Bitte beachten Sie, dass diese Anweisungen den Debug-Build erstellen, der Leistungseinbußen haben kann. Der Parameter "--config" hat vier gültige Werte: Debug, Release, RelWithDebInfo und MinSizeRel. Im Vergleich zu "Release" enthält "RelWithDebInfo" nicht nur Debug-Informationen, sondern deaktiviert auch einige Inlines, um das Binary leichter debuggen zu können. Daher ist RelWithDebInfo langsamer als Release.
  • Um die Version aus jedem Release zu erstellen (die Windows-, Linux- und Mac-Varianten enthält), siehe diese .yml-Dateien als Referenz.
  • Das Build-Skript führt standardmäßig alle Unit-Tests für native Builds aus und überspringt Tests standardmäßig für cross-kompilierte Builds. Um die Tests zu überspringen, führen Sie mit --build oder --update --build aus.
  • Wenn Sie Protobuf aus dem Quellcode installieren müssen, beachten Sie bitte
    • Öffnen Sie zuerst cmake/deps.txt, um zu prüfen, welche Protobuf-Version die offiziellen Pakete von ONNX Runtime verwenden.
    • Da wir Protobuf statisch verlinken, sollte unter Windows das CMake-Flag protobuf_BUILD_SHARED_LIBS auf AUS gesetzt sein. Unter Linux, wenn die Option AUS ist, müssen Sie auch sicherstellen, dass PIC aktiviert ist. Nach der Installation sollten Sie die ausführbare Datei "protoc" in Ihrem PATH haben. Es wird empfohlen, ldconfig auszuführen, um sicherzustellen, dass die Protobuf-Bibliotheken gefunden werden.
    • Wenn Sie Protobuf an einem nicht standardmäßigen Speicherort installiert haben, ist es hilfreich, die folgende Umgebungsvariable festzulegen: export CMAKE_ARGS="-DONNX_CUSTOM_PROTOC_EXECUTABLE=full path to protoc", damit der ONNX-Build es finden kann. Führen Sie auch ldconfig <protobuf lib folder path> aus, damit der Linker die Protobuf-Bibliotheken findet.
  • Wenn Sie onnx aus dem Quellcode installieren möchten, installieren Sie zuerst Protobuf und
      export ONNX_ML=1
      python3 setup.py bdist_wheel
      pip3 install --upgrade dist/*.whl
    

    Dann ist es besser, Protobuf zu deinstallieren, bevor Sie mit dem Erstellen von ONNX Runtime beginnen, insbesondere wenn Sie eine andere Version von Protobuf als ONNX Runtime installiert haben. —

Unterstützte Architekturen und Build-Umgebungen

Architekturen

  x86_32 x86_64 ARM32v7 ARM64 PPC64LE RISCV64 PPC64BE S390X
Windows JA JA JA JA NEIN NEIN NEIN NEIN
Linux JA JA JA JA JA JA NEIN JA
macOS NEIN JA NEIN NEIN NEIN NEIN NEIN NEIN
Android NEIN NEIN JA JA NEIN NEIN NEIN NEIN
iOS NEIN NEIN NEIN JA NEIN NEIN NEIN NEIN
AIX NEIN NEIN NEIN NEIN NEIN NEIN JA NEIN

Build-Umgebungen (Host)

OS Unterstützt CPU Unterstützt GPU Hinweise
Windows 10 JA JA VS2019 bis zum neuesten VS2022 werden unterstützt
Windows 10
Subsystem for Linux
JA NEIN  
Ubuntu 20.x/22.x JA JA Ebenfalls unterstützt auf ARM32v7 (experimentell)
CentOS 7/8/9 JA JA Ebenfalls unterstützt auf ARM32v7 (experimentell)
macOS JA NEIN  

GCC 8.x und darunter werden nicht unterstützt.
Wenn Sie ein Binary für eine 32-Bit-Architektur erstellen möchten, müssen Sie möglicherweise cross-kompilieren, da ein 32-Bit-Compiler möglicherweise nicht über genügend Speicher verfügt, um den Build auszuführen.
Das Erstellen des Codes unter Android/iOS wird nicht unterstützt. Sie müssen ein Windows-, Linux- oder macOS-Gerät verwenden, um dies zu tun.

Betriebssystem/Compiler Unterstützt VC Unterstützt GCC Unterstützt Clang
Windows 10 JA Nicht getestet Nicht getestet
Linux NEIN JA (gcc>=8) Nicht getestet
macOS NEIN Nicht getestet JA (Mindestversion nicht ermittelt)

Zielumgebungen

Sie können den Code für

  • Windows
  • Linux
  • MacOS
  • Android
  • iOS
  • WebAssembly

Laufzeit

  • Die minimal unterstützte Windows-Version ist Windows 10.
  • Die minimal unterstützte CentOS-Version ist 7.
  • Die minimal unterstützte Ubuntu-Version ist 16.04.

Allgemeine Build-Anweisungen

Beschreibung Befehl Zusätzliche Details
Grundlegender Build build.bat (Windows)
./build.sh (Linux)
 
Release-Build --config Release Release-Build. Andere gültige Konfigurationswerte sind RelWithDebInfo und Debug.
Build mit paralleler Verarbeitung --parallel Dies wird dringend empfohlen, um den Build zu beschleunigen.
Freigegebene Bibliothek erstellen --build_shared_lib  
Training-Unterstützung aktivieren --enable_training  

APIs und Sprachbindungen

API Befehl Zusätzliche Details
Python --build_wheel  
C#- und C-Nuget-Pakete --build_nuget Erstellt C#-Bindungen und erstellt ein Nuget-Paket. Impliziert --build_shared_lib
Detaillierte Anweisungen finden Sie weiter unten.
WindowsML --use_winml
--use_dml
--build_shared_lib
WindowsML hängt von DirectML und der freigegebenen ONNX Runtime-Bibliothek ab.
Java --build_java Erstellt ein onnxruntime4j.jar im Build-Verzeichnis, impliziert --build_shared_lib
Zum Kompilieren der Java-API ist Gradle v6.1+ zusätzlich zu den üblichen Anforderungen erforderlich.
Node.js --build_nodejs Erstellt Node.js-Bindung. Impliziert --build_shared_lib

Nuget-Pakete erstellen

Derzeit nur unter Windows und Linux unterstützt.

Voraussetzungen
  • dotnet wird zum Erstellen von C#-Bindungen und zum Erstellen von verwalteten Nuget-Paketen benötigt. Befolgen Sie die Anweisungen hier, um dotnet herunterzuladen. Getestet mit den Versionen 2.1 und 3.1.
  • nuget.exe. Befolgen Sie die Anweisungen hier, um nuget herunterzuladen.
    • Unter Windows ist das Herunterladen von nuget unkompliziert, und das Befolgen der obigen Anweisungen sollte ausreichen.
    • Unter Linux ist nuget auf Mono-Laufzeit angewiesen, daher muss dies ebenfalls eingerichtet werden. Der obige Link enthält alle Informationen zur Einrichtung von Mono und nuget. Die Anweisungen finden Sie direkt hier. In einigen Fällen ist es erforderlich, nach der Installation von mono sudo apt-get install mono-complete auszuführen.
Bauanleitungen
Windows
.\build.bat --build_nuget
Linux
./build.sh --build_nuget

Nuget-Pakete werden erstellt unter\nuget-artifacts


Weitere Build-Optionen

Build mit reduzierten Operator-Kernen

Reduzierte Operator-Kerne-Builds ermöglichen es Ihnen, die Kerne im Build anzupassen, um kleinere Binärgrößen zu erzielen.

DebugNodeInputsOutputs

OnnxRuntime unterstützt Build-Optionen zur Aktivierung des Debugging von Zwischen-Tensorformen und -daten.

Build-Anweisungen

Setzen Sie onnxruntime_DEBUG_NODE_INPUTS_OUTPUT, um mit aktivierter Funktion zu erstellen.

Linux
./build.sh --cmake_extra_defines onnxruntime_DEBUG_NODE_INPUTS_OUTPUTS=1
Windows
.\build.bat --cmake_extra_defines onnxruntime_DEBUG_NODE_INPUTS_OUTPUTS=1

Konfiguration

Das Verhalten des Debug-Dumps kann mit mehreren Umgebungsvariablen gesteuert werden. Details finden Sie unter onnxruntime/core/framework/debug_node_inputs_outputs_utils.h.

Beispiele

Um anzugeben, dass die Ausgabe von Knotendaten gedumpt werden soll (standardmäßig an stdout), setzen Sie diese Umgebungsvariable.

ORT_DEBUG_NODE_IO_DUMP_OUTPUT_DATA=1

Um anzugeben, dass Knotenausgabedaten für Knoten mit dem Namen "Foo" oder "Bar" in Dateien gedumpt werden sollen, setzen Sie diese Umgebungsvariablen.

ORT_DEBUG_NODE_IO_DUMP_OUTPUT_DATA=1
ORT_DEBUG_NODE_IO_NAME_FILTER="Foo;Bar"
ORT_DEBUG_NODE_IO_DUMP_DATA_TO_FILES=1

RISC-V

Die Ausführung auf einer Plattform wie RISC-V beinhaltet das Cross-Kompilieren von einer Host-Plattform (z. B. Linux) auf eine Zielplattform (eine spezifische RISC-V-CPU-Architektur und ein Betriebssystem). Befolgen Sie die untenstehenden Anweisungen, um ONNX Runtime für RISC-V 64-Bit zu erstellen.

Cross-Kompilierung unter Linux

  1. Laden Sie die GNU RISC-V Cross-Compile-Toolchain und den Emulator herunter und installieren Sie sie.

    Wenn Sie Ubuntu verwenden, können Sie eine vorcompilierte RISC-V GNU-Toolchain erhalten, indem Sie https://github.com/riscv-collab/riscv-gnu-toolchain/releases besuchen. Suchen Sie nach der entsprechenden Version, z. B. riscv64-glibc-ubuntu-22.04-llvm-nightly-XXXX-nightly.tar.gz. Extrahieren Sie nach dem Herunterladen das Archiv auf Ihre Build-Maschine und fügen Sie den Ordner "bin" zu Ihrer $PATH-Umgebungsvariable hinzu. Der QEMU-Emulator befindet sich ebenfalls im Toolchain-Ordner. Überspringen Sie diesen Schritt, wenn Sie diese Anweisungen befolgt haben.

    Für Benutzer mit anderen Linux-Distributionen besteht die Möglichkeit, GCC aus seinem Quellcode zu kompilieren. Es wird empfohlen, eine Compiler-Version zu wählen, die Ihrem Zielbetriebssystem entspricht, und die neueste stabile Version zu wählen.

    Wenn Sie den Compiler erhalten, führen Sie riscv64-unknown-linux-gnu-gcc -v aus. Dies sollte eine Ausgabe wie die folgende erzeugen:

        Using built-in specs.
        COLLECT_GCC=/path/to/riscv64-unknown-linux-gnu-gcc
        COLLECT_LTO_WRAPPER=/path/to/libexec/gcc/riscv64-unknown-linux-gnu/13.2.0/lto-wrapper
        Target: riscv64-unknown-linux-gnu
        Configured with: /path/to/riscv-gnu-toolchain/gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/opt/riscv --with-sysroot=/opt/riscv/sysroot --with-pkgversion= --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=.././gcc --disable-multilib --with-abi=lp64d --with-arch=rv64gc --with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2    -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2    -mcmodel=medlow'
        Thread model: posix
        Supported LTO compression algorithms: zlib zstd
        gcc version 13.2.0 ()
    
  2. Konfigurieren der RISC-V 64-Bit CMake-Toolchain-Datei

    Die CMake-Toolchain-Datei befindet sich unter ${ORT_ROOT}/cmake/riscv64.toolchain.cmake. Wenn es alternative Werte für die Variable gibt, die konfiguriert werden müssen, fügen Sie bitte die entsprechenden Einstellungen in diese Datei ein.

  3. Cross-Kompilierung unter Linux

    Führen Sie ./build.sh mit dem Flag --rv64 aus, geben Sie das RISC-V-Toolchain-Root mit --riscv_toolchain_root und den QEMU-Pfad mit --riscv_qemu_path als Build-Optionen an, um den Build-Prozess zu starten. Stellen Sie sicher, dass alle installierten Cross-Compiler von der Befehlszeile aus zugänglich sind, die zum Erstellen verwendet wird, indem Sie die PATH-Umgebungsvariable konfigurieren.

    (Optional) Wenn Sie xnnpack als Ausführungsanbieter verwenden möchten, stellen Sie sicher, dass Sie die Option --use_xnnpack in Ihre Build-Konfiguration aufnehmen.

    Beispiel für einen Build-Befehl

     ./build.sh --parallel --config Debug --rv64 --riscv_toolchain_root=/path/to/toolchain/root --riscv_qemu_path=/path/to/qemu-riscv64 --skip_tests
    

Arm

Es gibt mehrere Optionen zum Erstellen von ONNX Runtime für ARM®-basierte Geräte.

Zuerst können Sie dies auf einem echten ARM-basierten Gerät tun, oder auf einem x86_64-Gerät mit einem Emulator (wie qemu), oder auf einem x86_64-Gerät mit einem Docker-Container mit einem Emulator (Sie können einen ARM-basierten Container auf einem x86_64-PC ausführen). Dann sind die Build-Anweisungen im Wesentlichen dieselben wie die Anweisungen für Linux x86_64. Dies funktioniert jedoch nicht, wenn die CPU, auf die Sie abzielen, nicht 64-Bit ist, da der Build-Prozess mehr als 2 GB Speicher benötigt.

Cross-Kompilierung für ARM-basierte Geräte mit Simulation (Linux/Windows)

EINFACH, LANGSAM, EMPFOHLEN

Diese Methode basiert auf der Emulation im QEMU-Benutzermodus. Sie ermöglicht Ihnen, mit einer Desktop- oder Cloud-VM durch Instruktionslevel-Simulation zu kompilieren. Sie führen den Build auf einer x86-CPU aus und übersetzen jede ARM-Architektur-Instruktion in x86. Dies ist potenziell viel schneller als das native Kompilieren auf einem Low-End-Gerät. Die resultierende ONNX Runtime Python Wheel (.whl)-Datei wird dann auf ein ARM-basiertes Gerät bereitgestellt, wo sie in Python 3-Skripten aufgerufen werden kann. Der Build-Prozess kann Stunden dauern und es kann zu Speicherengpässen kommen, wenn die Ziel-CPU 32-Bit ist.

Cross-Kompilierung unter Linux

Schwierig, schnell

Diese Option ist sehr schnell und ermöglicht es, das Paket in wenigen Minuten zu erstellen, ist aber schwierig einzurichten. Wenn Sie eine große Codebasis haben (z. B. wenn Sie einen neuen Ausführungsanbieter zu onnxruntime hinzufügen), kann dies die einzig praktikable Methode sein.

  1. Holen Sie sich die entsprechende Toolchain.

    TLDR; Gehen Sie zu https://www.linaro.org/downloads/, holen Sie sich "64-Bit Armv8 Cortex-A, Little-Endian" und "Linux Targeted", nicht "Bare-Metal Targeted". Extrahieren Sie es auf Ihre Build-Maschine und fügen Sie den bin-Ordner zu Ihrer $PATH-Umgebungsvariable hinzu. Überspringen Sie dann diesen Teil.

    Sie können GCC oder Clang verwenden. Beide funktionieren, aber die Anweisungen hier basieren auf GCC.

    In GCC-Begriffen

    • "build" beschreibt die Art des Systems, auf dem GCC konfiguriert und kompiliert wird.
    • "host" beschreibt die Art des Systems, auf dem GCC läuft.
    • "target" beschreibt die Art des Systems, für das GCC Code erzeugt.

    Wenn nicht cross-kompiliert wird, ist normalerweise "build" = "host" = "target". Wenn Sie cross-kompilieren, ist normalerweise "build" = "host" != "target". Zum Beispiel können Sie GCC auf x86_64 erstellen, dann GCC auf x86_64 ausführen und dann Binaries generieren, die auf aarch64 abzielen. In diesem Fall ist "build" = "host" = x86_64 Linux, target ist aarch64 Linux.

    Sie können entweder GCC selbst aus dem Quellcode erstellen oder eine vorcompilierte Version von einem Anbieter wie Ubuntu oder Linaro erhalten. Die Wahl derselben Compilerversion wie Ihr Zielbetriebssystem ist am besten. Wenn dies nicht möglich ist, wählen Sie die neueste stabile Version und verlinken Sie statisch auf die GCC-Bibliotheken.

    Wenn Sie den Compiler erhalten, führen Sie aarch64-linux-gnu-gcc -v aus. Dies sollte eine Ausgabe wie die folgende erzeugen:

     Using built-in specs.
     COLLECT_GCC=/usr/bin/aarch64-linux-gnu-gcc
     COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/9/lto-wrapper
     Target: aarch64-linux-gnu
     Configured with: ../gcc-9.2.1-20190827/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/aarch64-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=aarch64-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=aarch64-linux-gnu --with-bugurl=https://bugzilla.redhat.com/bugzilla/ --with-gcc-major-version-only --with-isl --with-newlib --with-plugin-ld=/usr/bin/aarch64-linux-gnu-ld --with-sysroot=/usr/aarch64-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --enable-gnu-indirect-function --with-linker-hash-style=gnu
     Thread model: single
     gcc version 9.2.1 20190827 (Red Hat Cross 9.2.1-3) (GCC)
    

    Überprüfen Sie den Wert von --build, --host, --target und ob er spezielle Argumente wie --with-arch=armv8-a, --with-arch=armv6, --with-tune=arm1176jz-s, --with-fpu=vfp, --with-float=hard hat.

    Sie müssen auch wissen, welche Flags Ihre Zielhardware benötigt, was stark variieren kann. Zum Beispiel, wenn Sie nur den normalen ARMv7-Compiler erhalten und ihn direkt für Raspberry Pi V1 verwenden, funktioniert er nicht, da Raspberry Pi nur ARMv6 hat. Im Allgemeinen liefert jeder Hardwarehersteller eine Toolchain; prüfen Sie, wie diese erstellt wurde.

    Eine Zielumgebung wird identifiziert durch

    • Arch: x86_32, x86_64, armv6,armv7,arvm7l,aarch64,...
    • OS: bare-metal oder linux.
    • Libc: gnu libc/ulibc/musl/...
    • ABI: Arm hat mehrere ABIs wie eabi, eabihf...

    Sie können all diese Informationen aus der vorherigen Ausgabe erhalten, stellen Sie bitte sicher, dass sie alle korrekt sind.

  2. (Optional) Sysroot einrichten, um Python-Erweiterungen zu aktivieren. *Überspringen, wenn Sie kein Python verwenden.*

    Laden Sie das Root-Dateisystem des Zielbetriebssystems auf Ihre Build-Maschine. Wir nennen diesen Ordner "sysroot" und verwenden ihn für den Build der ONNX Runtime Python-Erweiterung. Bevor Sie dies tun, sollten Sie zuerst das Python3-Entwicklungspaket (das die C-Header-Dateien enthält) und das NumPy-Python-Paket auf der Zielmaschine installieren.

    Hier sind einige Beispiele.

    Wenn das Ziel-OS Raspbian-Buster ist, laden Sie bitte das RAW-Image von ihrer Website herunter und führen Sie dann aus:

     $ fdisk -l 2020-02-13-raspbian-buster.img
    

    Disk 2020-02-13-raspbian-buster.img: 3,54 GiB, 3787456512 Bytes, 7397376 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Disklabel-Typ: dos Disk-Identifikator: 0xea7d04d6

    Gerät Boot Start Ende Sektoren Größe ID Typ
    2020-02-13-raspbian-buster.img1   8192 532479 524288 256M c W95 FAT32 (LBA)
    2020-02-13-raspbian-buster.img2   532480 7397375 6864896 3,3G 83 Linux

    Sie werden feststellen, dass die Root-Partition bei Sektor 532480 beginnt, was 532480 * 512 = 272629760 Bytes vom Anfang entfernt ist.

    Führen Sie dann aus:

     $ mkdir /mnt/pi
     $ mount -r -o loop,offset=272629760 2020-02-13-raspbian-buster.img /mnt/pi
    

    Sie sehen alle Raspbian-Dateien unter /mnt/pi. Sie können es jedoch noch nicht verwenden. Da einige der Symlinks defekt sind, müssen Sie sie zuerst reparieren.

    Führen Sie unter /mnt/pi aus:

     $ find . -type l -exec realpath  {} \; |grep 'No such file'
    

    Dies zeigt, welche defekt sind. Dann können Sie sie reparieren, indem Sie ausführen:

     $ mkdir /mnt/pi2
     $ cd /mnt/pi2
     $ sudo tar -C /mnt/pi -cf - . | sudo tar --transform 'flags=s;s,^/,/mnt/pi2/,' -xf -
    

    Dann ist /mnt/pi2 der Sysroot-Ordner, den Sie im nächsten Schritt verwenden werden.

    Wenn das Ziel-OS Ubuntu ist, können Sie ein Image von https://cloud-images.ubuntu.com/ erhalten. Aber dieses Image ist im qcow2-Format. Konvertieren Sie es bitte, bevor Sie fdisk ausführen und mounten.

     qemu-img convert -p -O raw ubuntu-18.04-server-cloudimg-arm64.img ubuntu.raw
    

    Der restliche Teil ist ähnlich wie bei Raspbian.

    Wenn das Ziel-OS manylinux2014 ist, können Sie es erhalten durch: Installieren Sie qemu-user-static über apt oder dnf. Führen Sie dann den Docker aus:

    Ubuntu

     docker run -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -it --rm quay.io/pypa/manylinux2014_aarch64 /bin/bash
    

    Das Argument "-v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static" ist unter Fedora nicht erforderlich.

    Führen Sie dann innerhalb des Dockers Folgendes aus:

     cd /opt/python
     ./cp35-cp35m/bin/python -m pip install numpy==1.16.6
     ./cp36-cp36m/bin/python -m pip install numpy==1.16.6
     ./cp37-cp37m/bin/python -m pip install numpy==1.16.6
     ./cp38-cp38/bin/python -m pip install numpy==1.16.6
    

    Diese Befehle werden einige Stunden dauern, da NumPy noch kein vorcompiliertes Paket hat. Wenn sie abgeschlossen sind, öffnen Sie ein zweites Fenster und führen Sie aus:

     docker ps
    

    Aus der Ausgabe

     CONTAINER ID        IMAGE                                COMMAND             CREATED             STATUS              PORTS               NAMES
     5a796e98db05        quay.io/pypa/manylinux2014_aarch64   "/bin/bash"         3 minutes ago       Up 3 minutes                            affectionate_cannon
    

    Sie sehen die Docker-Instanz-ID: 5a796e98db05. Verwenden Sie den folgenden Befehl, um das Root-Dateisystem als Sysroot für zukünftige Verwendung zu exportieren.

     docker export 5a796e98db05 -o manylinux2014_aarch64.tar
    
  3. Generieren Sie CMake-Toolchain-Datei Speichern Sie den folgenden Inhalt als tool.cmake

     SET(CMAKE_SYSTEM_NAME Linux)
     SET(CMAKE_SYSTEM_VERSION 1)
     SET(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)
     SET(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)
     SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
     SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
     SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
     SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
     SET(CMAKE_FIND_ROOT_PATH /mnt/pi)
    

    Wenn Sie keinen Sysroot haben, können Sie die letzte Zeile löschen.

    Außerdem können Sie CMAKE_SYSTEM_PROCESSOR setzen. Die offizielle Dokumentation von CMake empfiehlt, bei der Cross-Kompilierung eine CMAKE_TOOLCHAIN_FILE-Datei zu verwenden, um die Variable CMAKE_SYSTEM_PROCESSOR auf die Zielarchitektur einzustellen, die sie angibt. Die Dokumentation listet jedoch keine gültigen Werte auf, und wir haben festgestellt, dass diese Einstellung nicht notwendig ist. Wenn Sie wissen, auf welchen Wert die Variable gesetzt werden sollte, fügen Sie die Einstellung dort hinzu. Die Build-Skripte von ONNX Runtime verwenden diese Variable nicht, aber die Abhängigkeiten von ONNX Runtime möglicherweise.

  4. Führen Sie CMake und Make aus

    Hängen Sie -Donnxruntime_ENABLE_CPUINFO=OFF -DCMAKE_TOOLCHAIN_FILE=path/to/tool.cmake an Ihre CMake-Argumente an, führen Sie CMake und Make aus, um es zu erstellen. Wenn Sie auch ein Python-Paket erstellen möchten, können Sie CMake-Argumente wie folgt verwenden:

    -Donnxruntime_GCC_STATIC_CPP_RUNTIME=ON -DCMAKE_BUILD_TYPE=Release -Dprotobuf_WITH_ZLIB=OFF -DCMAKE_TOOLCHAIN_FILE=path/to/tool.cmake -Donnxruntime_ENABLE_PYTHON=ON -DPYTHON_EXECUTABLE=/mnt/pi/usr/bin/python3 -Donnxruntime_BUILD_SHARED_LIB=OFF -Donnxruntime_DEV_MODE=OFF "-DPYTHON_INCLUDE_DIR=/mnt/pi/usr/include;/mnt/pi/usr/include/python3.7m" -DNUMPY_INCLUDE_DIR=/mnt/pi/folder/to/numpy/headers
    

    Nachdem Sie CMake ausgeführt haben, führen Sie aus:

    $ make
    
  5. (Optional) Python-Paket erstellen

    Kopieren Sie die setup.py-Datei aus dem Quellordner in den Build-Ordner und führen Sie aus:

    python3 setup.py bdist_wheel -p linux_aarch64
    

    Wenn Sie auf ManyLinux abzielen, funktionieren deren Tools im Cross-Kompilierungsszenario leider nicht. Führen Sie es in einem Docker wie diesem aus:

    docker run  -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -v `pwd`:/tmp/a -w /tmp/a --rm quay.io/pypa/manylinux2014_aarch64 /opt/python/cp37-cp37m/bin/python3 setup.py bdist_wheel
    

    Dies ist nicht erforderlich, wenn Sie nur eine bestimmte Linux-Distribution (z. B. Ubuntu) anvisieren möchten.

Cross-Kompilierung unter Windows

Verwendung von Visual C++ Compilern

  1. Laden Sie Visual C++ Compiler und Bibliotheken für Arm (64) herunter und installieren Sie sie. Wenn Sie Visual Studio installiert haben, verwenden Sie den Visual Studio Installer (suchen Sie im Abschnitt Individuelle Komponenten, nachdem Sie Visual Studio ändern ausgewählt haben), um die entsprechenden Arm (64)-Compiler und Bibliotheken herunterzuladen und zu installieren.

  2. Verwenden Sie .\build.bat und geben Sie --arm oder --arm64 als Build-Option an, um mit dem Erstellen zu beginnen. Bevorzugen Sie die Verwendung der Developer Command Prompt for VS oder stellen Sie sicher, dass alle installierten Cross-Compiler von der Befehlszeile, die zum Erstellen verwendet wird, über die PATH-Umgebungsvariable auffindbar sind.

  3. Fügen Sie --use_vcpkg zu Ihrem Build-Befehl hinzu, was die manuelle Handhabung von protoc.exe vermeiden kann.


Mobile

Bitte siehe Build für Android und Build für iOS.

Web

Bitte siehe Build für Web.