Difference between revisions of "LibSR:Memory"

From Maths
Jump to: navigation, search
(Created page with "LibSR is designed to run in ''constant'' memory (and be given an initial pool) this makes checking for failure codes very important. It is easy to Lib...")
 
m
 
Line 1: Line 1:
LibSR is designed to run in ''constant'' memory (and be given an initial [[LibSR:Memory pool|pool]]) this makes checking for failure codes very important.
+
[[LibSR:Project|LibSR]] is designed to run in ''constant'' memory (and be given an initial pool) this makes checking for failure codes very important.
  
It is easy to [[LibSR:Context memory API|query the context]]
+
At the time of writing (and probably quite far into the project) a {{C|CrappyAllocator}} is used. This allocator is just a front for {{C|malloc}} and {{C|free}} (and the aligned memory allocator)
  
==Notes==
+
All LibSR allocations are done via an allocator, so in the future a pool may be implemented.
* [[LibSR:Shader|Shaders]] do not come out of LibSR's memory budget
+
 
 +
The {{C|CrappyAllocator}} provides {{C|getAllocatedByteCount}} by using {{C|malloc_usable_size}} - a GNU extension to C's stdlib (from {{C|malloc.h}}.
 +
 
 +
If {{C|getAllocatedByteCount}} cannot be provided it ''should'' return 0. As an allocator should be created before the context (or even know about itself) we can never have an allocator and have 0 bytes allocated. Thus 0 means "not supported". This isn't implemented at the time of writing and both the context and the allocator are created using {{C|new}} - this is temporary, all other structures use allocators correctly.
  
 
[[Category:LibSR]]
 
[[Category:LibSR]]

Latest revision as of 10:14, 23 January 2016

LibSR is designed to run in constant memory (and be given an initial pool) this makes checking for failure codes very important.

At the time of writing (and probably quite far into the project) a CrappyAllocator is used. This allocator is just a front for malloc and free (and the aligned memory allocator)

All LibSR allocations are done via an allocator, so in the future a pool may be implemented.

The CrappyAllocator provides getAllocatedByteCount by using malloc_usable_size - a GNU extension to C's stdlib (from malloc.h.

If getAllocatedByteCount cannot be provided it should return 0. As an allocator should be created before the context (or even know about itself) we can never have an allocator and have 0 bytes allocated. Thus 0 means "not supported". This isn't implemented at the time of writing and both the context and the allocator are created using new - this is temporary, all other structures use allocators correctly.