The hardware codec, hardware image scaling and other processes are carried out in a dedicated hardware unit, and the memory used is also dedicated memory, which is mostly the graphics memory in the SoC. It is so convenient to interact with functions such as hardware accelerated graphics rendering, image display, and hardware image acceleration processing.
When the above process uses graphics memory, it is naturally necessary to use the corresponding graphics memory management API. Common graphics memory management APIs are as follows:
1. DRM, mainly only the memory management part, including two types of interfaces of dumb-buffer and GEM (Graphics Execution Manager). The specific driver is implemented according to the support of the chip, and provides the corresponding API for the user mode.
1.1 dumb-buffer is more general. After allocation, it can do mapping processing to obtain a user-mode pointer, and then write data to the graphics memory based on this, but this method cannot guarantee the consistency of the data cache in the graphics memory. Its general use process is
a) open() drm device node, mostly /dev/dri/card0, etc., get the device operation fd handle
b) ioctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, ) creates a dumb-buffer and obtains the buffer handle. Need to specify parameters such as width and height/BPP
c) ioctl(fd, DRM_IOCTL_MODE_MAP_DUMB, ) according to the pseudo offset of the buffer object
d) mmap(, offset) maps the buffer object to user mode, obtains a pointer, and then writes data to it
e) ioctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, ) destroys the dumb-buffer object
1.2 In addition to the functions provided by dumb-buffer, GEM manufacturers provide additional proprietary APIs for creating and reading and writing operations. In this way, while reading and writing are completed, cache coherence operations can be performed in them; and GEM Each Buffer object can be assigned a 32-bit name for passing across processes.
Its use process is generally, with the power of Intel i915 series platform
a) open() drm device node, mostly /dev/dri/card0, etc., get the device operation fd handle
b) ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, struct drm_i915_gem_create) Create a GEM buffer object, get its handle, and simply specify the size.
c) ioctl (fd, DRM_IOCTL_I915_GEM_PREAD, struct drm_i915_gem_pread) / ioctl (fd, DRM_IOCTL_I915_GEM_PWRITE, struct drm_i915_gem_pwrite) read and write, ensures cache coherency
ioctl (fd, DRM_IOCTL_I915_GEM_MMAP, struct drm_i915_gem_mmap ) Get a pointer to map the user state, does not guarantee cache consistency
d) ioctl(fd, DRM_IOCTL_GEM_CLOSE, struct drm_gem_close) release the GEM buffer object just now
Get the GEM Buffer object name, and the cross-process transfer process is as follows
a) ioctl(fd, DRM_IOCTL_GEM_FLINK, struct drm_gem_flink) Get the name of the GEM Buffer
b) ioctl(fd, DRM_IOCTL_GEM_OPEN, struct drm_gem_open) According to the name, get the handle of the corresponding GEM Buffer object in the current process
The GEM Buffer object implementation is reference counted, and it is only released when all user mode handles are closed.
2, ION
ION is a set of pure graphics memory management API proposed by Google, which is widely supported in the current Android system. Its usage is somewhat similar to GEM, and the Buffer handle can also be passed across processes to distribute different graphics tasks into different processes (the Android system actually does this).
The basic usage process is as follows:
a) open() drm device node, mostly /dev/ion, get the device operation fd handle
b) ioctl(fd, ION_IOC_ALLOC, struct ion_allocation_data) Allocate, return struct ion_handle, simply specify the size information.
b) ioctl(fd, ION_IOC_FREE, struct ion_handle_data) 释放
c) ioctl(fd, ION_IOC_SHARE, struct ion_fd_data)/ioctl(fd, ION_IOC_MAP, struct ion_fd_data) Return the fd representation of the ION Buffer object, which
can then be used to call mmap() to obtain the user day pointer, or pass it across processes
d) ioctl(fd, ION_IOC_IMPORT, struct ion_fd_data) Get the local struct ion_handle according to the fd provided elsewhere
e) ioctl(fd, ION_IOC_SYNC, struct ion_fd_data) flushes the ION Buffer to ensure consistency.
3, Manufacturer's private API
3.1 Allwinner A20 platform, its hardware codec unit cedar, the interface of graphics memory provided in user mode is a private API, please see https://github.com/allwinner-zh/ The device node accessed by the API provided by media-codec/tree/master/sunxi-cedarx/SOURCE/common
is /dev/cedar_dev. For details, see the API and corresponding implementation in ve.h/ve_alloc.h.
3.2 Intel HD series integrated GPU platform, the management API of its graphics memory is in libva, and the specific hardware access is performed in libva's user-mode backend vaapi-driver.
The VASurface noun is used to represent the graphics memory object, and its creation requires the formulation of basic parameters of the width/height/pixel format. When using it, you need to obtain a VADisplay object first, and the entry to obtain the object has different entries on different display backends of Android/DRM/Wayland. See the API description of libva for details.
~~~ end ~~~