Directfb Memory Allocation and Management: Surface pool

Prior to Version 1.1, DFB only had the basic concept of system memory, that is, using local or shared memory; or the concept of video memory, that is, a fixed physical address and a certain size of continuous memory blocks, the memory is directly mapped by the CPU or by the Memory Manager Surface Built in by DFB.
Manager. Surface manager is a one-dimensional Memory Manager that can be used to kick out of memory that is no longer needed. These memories are generally the memory of local backup. In rare cases, the system or driver module can control or implement memory allocation by itself. By calling the display layer (Display
Driver) driver API: allocatesurface (), reallocatesurface (), and deallocatesurface (). These memory allocation and release are generally not implemented by the driver, so standard allocation in the video memory is usually used.

After Version 1.1, DFB introduced the surface pool concept of the flat pool, so programmers can manage the surface cache in their own way.
Buffer ). The biggest advantage of the surface pool is the transfer of the hardcoded System <-> video heap logic (including sync, transfer, locking, and so on) to a general mechanism. You can create any number of heaps/pools.

Surface pool negotiation is a key step because it routes the surface buffer memory allocation requests to the correct pool. If multiple pools meet the conditions, select the most suitable one. These conditions include: support necessary access flag (Access
Flags, such as CPU/GPU), surface type tags (such as layer font), and other necessary standards.

After a coresurface is created based on the selected coresurfaceconfiguration, The coresurfacebuffer structure is allocated and added. However, no pixel data is actually allocated. The first lock or write operation triggers the negotiation operation.

 

 

For example, when a user needs to draw a picture, he/she first locks the buffer when obtaining the video card status. That is, he/she calls dfb_surface_buffer_lock. This function checks whether there is a suitable memory allocation object allocation. If not, call dfb_surface_pools_allocate (buffer, accessor, access, & allocation); To create an allocation object.

What operations will dfb_surface_pools_allocate do? The key step is to negotiate the surface pool negotiation through a flat pool. Call: dfb_surface_pools_negotiate (buffer, accessor, access, pools, pool_count, & num_pools ).

What is the main purpose of this negotiation? As mentioned above, it routes the surface buffer memory allocation request to the correct pool. What is the correct pool? Of course, these are the pools that can meet the memory allocation requirements. therefore, we can see that in this negotiation function, it will traverse various pools to find the pool that meets our needs. it will call testconfig of the system module (such as fbdev. testconfig calculates the buffer size to be allocated and uses the ioctrl of the framebuffer driver to check whether the memory allocation is sufficient.

When the pool is found, the next step is to call dfb_surface_pool_allocate (pool, buffer, & allocation) to create an allocation object for these pools. What exactly is this allocation object? See.

Let's assume that the system module uses fbdev. Then, in the above allocate function, there will be funcs-> allocatebuffer (pool, pool-> data, get_local (pool), buffer, allocation, allocation-> data) such code will eventually call fbdevallocatebuffer to allocate memory. The buffer, surface, pool, access, size, and offset members of allocation are assigned values. The size and offset are transmitted through the allocatebuffer of fbdev.
And assign values through ioctrl. Then we call dfb_surface_allocation_update to update the buffer's allocation, mainly written and read members.

After creating and updating allocation, we will lock the allocation. Its implementation is completed by dfb_surface_pool_lock (allocation-> pool, allocation, lock. The lock parameter is of the coresurfacebufferlock type and is the abstraction of the read and write locks. It is a member variable of the video card status.

It can be seen that the allocation Member of the lock is first associated with the allocation object we allocate. Then, call the fbdevlock function to assign values to other members. For example:

 

The above alloc is obtained from the underlying layer through ioctrl in fbdevallocatebuffer. It is passed through the allocation member variable data.

 

 

Source: http://blog.csdn.net/acs713/article/details/7879545