@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった
ということで、ソースコードをちょこっと解析してみました。
どうやら、つぎの2つのパターンがあるみたい。
NNP-Iは、IceLake + アルファなので、IceLakeの部分で実行するのか？それとも、本当にホスト側のXeonで実行するのか？
全体的には、Arm NN SDKの中にある各種フレームワークのモデルを Import する感じでNNP-IのSDK内のAPIを使ってモデルを再構築をして、NNP-I内で実行するって感じです。
以下、NNP-IのSDK関連のキーワードです。
ヘッダファイル
- nnpi_inference.h
- nnpi_transformer.h
- nnpi_network_builder.h
- nnpi_network_builder_EXPERIMENTAL.h
ライブラリ
- libnnpi_transformer.so
- libnnpi_inference.so
型
- NNPINetwork
- NNPICompilationConfig
- NNPIDeviceContext
- NNPIInferCommand
- NNPIObjectName
- NNPIResourceDesc
- NNPIHandle
- NNPICopyCommand
- NNPIHostNetwork
- NNPIDeviceNetwork
- NNPIAdapter
関数
- nnpiNetworkOptimize
- nnpiGetDefaultCompilationConfig
- nnpiNetworkCompileToStream
- nnpiNetworkCompileToFile
- nnpiNetworkSetName
- nnpiNetworkCreate
- nnpiNetworkDestroy
- nnpiDeviceContextCreate
- nnpiDeviceContextDestroy
- nnpiAdapterCreate
- nnpiAdapterDestroy
- nnpiNetworkGetInputNum
- nnpiNetworkGetInputDesc
- nnpiNetworkGetOutputDesc
- nnpiHostNetworkCreateFromStream
- nnpiHostNetworkDestroy
- nnpiDeviceNetworkCreate
- nnpiDeviceNetworkDestroy
- nnpiInferCommandQueue
- nnpiInferCommandDestroy
- nnpiCopyCommandQueue
- nnpiCopyCommandDestroy
- nnpiCopyCommandCreateHostToDevice
- nnpiCopyCommandCreateDeviceToHost
- nnpiHostResourceCreate
- nnpiHostResourceDestroy
- nnpiHostResourceLock
- nnpiHostResourceUnlock
- nnpiDeviceResourceCreate
- nnpiDeviceResourceDestroy
- nnpiNetworkInferOnHost
デバイスのバージョンは、3つ ( 1, 2, 3 )
if (!deviceVersion.empty()) {
if (deviceVersion.compare("1") == 0) {
config_.deviceType = NNPI_DEVICE_M2_A;
} else if (deviceVersion.compare("2") == 0) {
config_.deviceType = NNPI_DEVICE_M2_B;
} else if (deviceVersion.compare("3") == 0) {
config_.deviceType = NNPI_DEVICE_M2_C;
} else {
LOG_IF_NOT_RETURN_LLVMERROR(
false, "INVALID NNPI_DEVICE_VERSION, valid values are 1,2,3");
}
}
- USE_ICE_T
- USE_INF_API
- ICE_T_FILE
- SYMLOWP_WA
もうちょっと詳しく見たら、他のBackendは、QueueBackedDeviceManager クラスを継承して DeviceManager クラスを定義しているが、NNP-IのBackendは、ただのDeviceManager クラスを継承しているんだね。対応が遅れているのかな？
1月には QueueBackendDeviceManager クラスあったんだけどね。
