aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorGeorgios Pinitas <georgios.pinitas@arm.com>2018-10-11 15:33:11 +0100
committerAnthony Barbier <anthony.barbier@arm.com>2018-11-02 16:55:45 +0000
commit9da19e9da660057785fb736aba5c61b1ae773f2f (patch)
treeb51b30bed8266571178834367437bab0d8a7a517 /docs
parentffb57a05d624c2efe1b32cf6ece112ee28726058 (diff)
downloadComputeLibrary-9da19e9da660057785fb736aba5c61b1ae773f2f.tar.gz
COMPMID-1605: API alignment for the MemoryManager with ARMNN
Change-Id: Iac6a95ba7f388e65b7f1c8865c3e9bf289b233ea Reviewed-on: https://eu-gerrit-1.euhpc.arm.com/155490 Reviewed-by: Anthony Barbier <anthony.barbier@arm.com> Tested-by: bsgcomp <bsgcomp@arm.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/01_library.dox14
1 files changed, 4 insertions, 10 deletions
diff --git a/docs/01_library.dox b/docs/01_library.dox
index bd4b300d7d..189602046b 100644
--- a/docs/01_library.dox
+++ b/docs/01_library.dox
@@ -342,8 +342,6 @@ Requesting backing memory for a specific group can be done using @ref IMemoryGro
- @ref ILifetimeManager that keeps track of the lifetime of the registered objects of the memory groups and given an @ref IAllocator creates an appropriate memory pool that fulfils the memory requirements of all the registered memory groups.
- @ref IPoolManager that safely manages the registered memory pools.
-@note @ref IMemoryManager::finalize should be called once the configuration of all the memory groups, kernels and functions is done, so that the memory manager can allocate the appropriate backing memory.
-
@note @ref BlobLifetimeManager is currently implemented which models the memory requirements as a vector of distinct memory blobs.
@subsection S4_7_2_working_with_memory_manager Working with the Memory Manager
@@ -385,11 +383,9 @@ tmp3.allocator()->allocate(); // Flag that the lifetime of object tmp3 has
@warning The configuration step should be done sequentially by a single thread so that all the lifetimes are captured correclty.
-When configuration of all the operations is finished then the memory manager have to be finalized:
+When configuration of all the operations is finished then the memory manager have to be populated:
@code{.cpp}
-mm->set_allocator(&allocator); // Set allocator to use
-mm->set_set_num_pools(2); // Set number of pools to create in case parallel operations can be run
-mm->finalize(); // Finalize memory manager (Object lifetime check, Memory pool creation etc)
+mm->populate(&allocator), 2 /* num_pools */); // Populate memory manager pools
@endcode
Finally, during execution of the pipeline the memory of the appropriate memory group should be requested before running:
@@ -422,10 +418,8 @@ CLConvolutionLayer conv1(mm), conv2(mm);
conv1.configure(...);
conv2.configure(...);
-// Finalize memory manager
-mm->set_allocator(&allocator); // Set allocator to use
-mm->set_set_num_pools(1); // Set number of pools to create in case parallel operations can be run
-mm->finalize(); // Finalize memory manager (Object lifetime check, Memory pool creation etc)
+// Populate memory manager
+mm->populate(&allocator), 1 /* num_pools */); // Populate memory manager pools
// Run layers (Memory will be recycled for internal buffers for conv1 and conv2
conv1.run();