Phriction Machine Learning Platform Arm NN Arm NN Design Notes Dynamic Backend Loading History Version 1 vs 2
Version 1 vs 2
Version 1 vs 2
Edits
Edits
- Edit by • MatteoArm, Version 2
- Jun 10 2019 3:24 PM
- Edit by • MatteoArm, Version 1
- Jun 10 2019 3:17 PM
Original Change | Next Change » |
Edit Older Version 1... | Edit Older Version 2... |
Content Changes
Content Changes
**Technical Contact:** Matteo Martincigh
== Pre-Implementation Review ==
== Post-Implementation Review ==
= Abstract =
Provide a high level statement of the requirement.
This section also details the author, the version of the design note and names the contributors.
= Overview =
This section details the requirement and usually includes at least one diagram that graphically illustrates the requirement and the solution outlined in this design note.
= Detailed Design =
There will be one or more detailed design sections that provide the necessary detail to guide another developer on how to implement the feature. Where possible please use diagrams rather than text to convey the design intent.
**Technical Contact:** Matteo Martincigh
== Pre-Implementation Review ==
== Post-Implementation Review ==
= Abstract =
This is a design note to add to ability to dynamically load a backend in the ARmNN's runtime
| Version | Date | Changes | Author
|---|---|---|---
| 0.1 | 10/06/2016 | Initial draft | Matteo Martincigh
= Overview =
Enable ArmNN to discover all the backends available on a system and dynamically load any it might find during the runtime's startup. It should be possible for the same compiled libarmnn.so deployed on different systems to load different backends. The same backend can be loaded simultaneously be different runtimes.
The current way of statically adding a backend at compile time must be retained.
= Detailed Design =
Main specifications:
* Load the backends as shared libraries from a "backends" subdirectory in the path where libarmnn.so is
* Use dlopen, dlclose and dlsym to load, unload and obtain the address of a symbol in the shared object respectively
* All done in the Runtime constructor? Create a new "LoadBackends" method in the Runtime class. Or add to the IRunTime::Create factory method
* To be loaded properly, a shared object must implement all the methods defined by the IBackendInternal interface (rename it to IBackend once and for all?)
* The backends implementation must be thread-safe where necessary, as the same backend object can be loaded by multiple runtimes?
* If any backend fails to load, the error must be reported but the runtime should ignore the failing backend and continue to the next one, if any
* Provide detailed documentation for the users who want to create their own (dynamic) backend
**Technical Contact:** Matteo Martincigh
== Pre-Implementation Review ==
== Post-Implementation Review ==
= Abstract =
Provide a high level statement of the requirement.This is a design note to add to ability to dynamically load a backend in the ARmNN's runtime
| Version | Date | Changes | Author
|---|---|---|---
This section also details the author, the version of the design note and names the contributors.| 0.1 | 10/06/2016 | Initial draft | Matteo Martincigh
= Overview =
This section details the requirement and usually includes at least one diagram that graphically illustrates the requirement and the solution outlined in this design noteEnable ArmNN to discover all the backends available on a system and dynamically load any it might find during the runtime's startup. It should be possible for the same compiled libarmnn.so deployed on different systems to load different backends. The same backend can be loaded simultaneously be different runtimes.
The current way of statically adding a backend at compile time must be retained.
= Detailed Design =
There will be one or more detailed design sections that provide the necessary detail to guide another developer on how to implement the feature.Main specifications:
* Load the backends as shared libraries from a "backends" subdirectory in the path where libarmnn.so is
* Use dlopen, dlclose and dlsym to load, unload and obtain the address of a symbol in the shared object respectively
* All done in the Runtime constructor? Create a new "LoadBackends" method in the Runtime class. Or add to the IRunTime::Create factory method
* To be loaded properly, a shared object must implement all the methods defined by the IBackendInternal interface (rename it to IBackend once and for all?)
* The backends implementation must be thread-safe where necessary, as the same backend object can be loaded by multiple runtimes?
* If any backend fails to load, the error must be reported but the runtime should ignore the failing backend and continue to the next one, Where possible please use diagrams rather than texif any
* Provide detailed documentation for the users who want to conveyreate the design intent.ir own (dynamic) backend