From: Aron Virginas-Tar Date: Tue, 20 Nov 2018 14:31:13 +0000 (+0000) Subject: Minor improvements and changes in backends/README.md X-Git-Tag: submit/tizen/20200316.035456~1052 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=a52809cc136a9854da5b66e989e24c5b6217e4ea;p=platform%2Fupstream%2Farmnn.git Minor improvements and changes in backends/README.md Change-Id: I55e27c50953c5e3f0b43bcd7aa8643015480181d --- diff --git a/src/backends/README.md b/src/backends/README.md index 125b41b05..ddd1bb6b9 100644 --- a/src/backends/README.md +++ b/src/backends/README.md @@ -4,9 +4,9 @@ ArmNN allows adding new backends through the 'Pluggable Backend' mechanism. ## How to add a new backend -Backends reside under [src/backends](./) in separate subfolders. For Linux builds they must have a ```backend.cmake``` file +Backends reside under [src/backends](./), in separate subfolders. For Linux builds they must have a ```backend.cmake``` file which is read automatically by [src/backends/backends.cmake](backends.cmake). The ```backend.cmake``` file -under the backend specific folder is then included by the main CMakeLists.txt file at the root of the +under the backend-specific folder is then included by the main CMakeLists.txt file at the root of the ArmNN source tree. ### The backend.cmake file @@ -14,8 +14,8 @@ ArmNN source tree. The ```backend.cmake``` has three main purposes: 1. It makes sure the artifact (a cmake OBJECT library) is linked into the ArmNN shared library by appending the name of the library to the ```armnnLibraries``` list. -2. It makes sure that the subdirectory where backend sources reside gets included in the build. -3. To include backend specific unit tests, the object library for the unit tests needs to be added to the ```armnnUnitTestLibraries``` list. +2. It makes sure that the subdirectory where backend sources reside gets included into the build. +3. To include backend-specific unit tests, the object library for the unit tests needs to be added to the ```armnnUnitTestLibraries``` list. Example ```backend.cmake``` file taken from [reference/backend.cmake](reference/backend.cmake): @@ -37,7 +37,7 @@ list(APPEND armnnLibraries armnnRefBackend armnnRefBackendWorkloads) # # Backend specific unit tests can be integrated through the # armnnUnitTestLibraries variable. This makes sure that the -# UnitTests executable can run the backend specific unit +# UnitTests executable can run the backend-specific unit # tests. # list(APPEND armnnUnitTestLibraries armnnRefBackendUnitTests) @@ -58,7 +58,7 @@ ArmNN on Android uses the native Android build system. New backends are integrat ```backend.mk``` file which has a single variable called ```BACKEND_SOURCES``` listing all cpp files to be built by the Android build system for the ArmNN shared library. -Optionally, backend specific unit tests can be added similarly, by +Optionally, backend-specific unit tests can be added similarly, by appending the list of cpp files to the ```BACKEND_TEST_SOURCES``` variable. Example taken from [reference/backend.mk](reference/backend.mk): @@ -134,21 +134,21 @@ it sees fit and it keeps these objects for a short period of time. Examples: * During optimization ArmNN needs to decide which layers are supported by the backend. To do this, it creates a backends and calls the ```GetLayerSupport()``` function and creates an ```ILayerSupport``` object to help deciding this. -* During optimization ArmNN can run backend specific optimizations. It creates backend objects +* During optimization ArmNN can run backend-specific optimizations. It creates backend objects and calls the ```GetOptimizations()``` function and it runs them on the network. * When the Runtime is initialized it creates an optional ```IBackendContext``` object and keeps this context alive for the Runtime's lifetime. It notifies this context object before and after a network is loaded or unloaded. -* When the LoadedNetwork creates the backend specific workloads for the layers, it creates a backend +* When the LoadedNetwork creates the backend-specific workloads for the layers, it creates a backend specific workload factory and calls this to create the workloads. ## The BackendRegistry As mentioned above, all backends need to be registered through the BackendRegistry so ArmNN knows -about them. Registration requires a unique backend id string and a lambda function that +about them. Registration requires a unique backend ID string and a lambda function that returns a unique pointer to the [IBackendInternal interface](backendsCommon/IBackendInternal.hpp). For registering a backend only this lambda function needs to exist, not the actual backend. This -allows dynamically creating the backend objects when it is needed. +allows dynamically creating the backend objects when they are needed. The BackendRegistry has a few convenience functions, like we can query the registered backends and are able to tell if a given backend is registered or not. @@ -174,27 +174,28 @@ the input and output tensor information and a workload specific queue descriptor ## The IMemoryManager interface -Backends may choose to implement custom memory management. ArmNN supports this concept through this mechanism: +Backends may choose to implement custom memory management. ArmNN supports this concept through the following +mechanism: * the ```IBackendInternal``` interface has a ```CreateMemoryManager()``` function which is called before creating the workload factory * the memory manager is passed to the ```CreateWorkloadFactory(...)``` function so the workload factory can - use it for creating the backend specific workloads + use it for creating the backend-specific workloads * the LoadedNetwork calls ```Acquire()``` on the memory manager before it starts executing the network and it calls ```Release()``` in its destructor ## The Optimizations -The backends may choose to implement backend specific optimizations. This is supported through the ```GetOptimizations()``` +The backends may choose to implement backend-specific optimizations. This is supported through the ```GetOptimizations()``` method of the IBackendInternal interface. This function may return a vector of optimization objects and the optimizer runs these after all general optimization is performed on the network. ## The IBackendContext interface -Backends may need to be notified when a network is loaded or unloaded. To support that one can implement the optional +Backends may need to be notified whenever a network is loaded or unloaded. To support that, one can implement the optional [IBackendContext](backendsCommon/IBackendContext.hpp) interface. The framework calls the ```CreateBackendContext(...)``` method for each backend in the Runtime. If the backend returns a valid unique pointer to a backend context, then the -runtime will hold this for its entire lifetime. It then calls these interface functions for each stored context: +runtime will hold this for its entire lifetime. It then calls the following interface functions for each stored context: * ```BeforeLoadNetwork(NetworkId networkId)``` * ```AfterLoadNetwork(NetworkId networkId)```