关于GPU图像处理下的DRM/RGA/MPP

直接渲染管理器(Direct Rendering Manager)是给予DRI客户端直接访问硬件的内核模块。
该模块处理DMA,AGP内存管理，资源锁和安全硬件访问。为了支持多个并发的3D应用，3D画图硬件必须以共享形式来看待。提供锁来保持互斥。DMA传输和AGP结构用来发送buffer和图像命令给硬件。最后，必须有安全保证，防止客户端使用图像硬件进行权限提升。因为Linux内核内部接口和数据结构随时可能改变，因此DRI内核模块对于特殊内核版本必须特别编译。DRI【Direct Rendering Infrastructure 可翻译为：直接着色基础结构（基层直接渲染）；DRI是一个安全且有效率的直接对显示硬件存取的方法。它包含对X server,一些client函数库、以及对内核的变更；DRI的一个主要目的就是提供高效能的OpenGL支持】内核模块放置目录为/lib/modules/.../kernel/drivers/gpu/drm,一般情况下，不管DRI模是否需要，X服务都自动加载. [1] 。DRI：Direct Rendering Infrastructure 可翻译为：直接着色基础结构（基层直接渲染）；DRI是一个安全且有效率的直接对显示硬件存取的方法。它包含对X server,一些client函数库、以及对内核的变更；DRI的一个主要目的就是提供高效能的OpenGL支持。DRM以如下三种主要方式支持DRI
　　(1)DRM提供图形硬件的同步访问
　　(2)DRM强制使用DRI安全规则访问图形硬件
　　(3)DRM提供通用的DMA引擎

如下结合图介绍几个概念：

 

       Each DRM device provides	access to manage which monitors	and displays
       are currently used and what frames to be	displayed. This	task is	called
       Kernel Mode-Setting (KMS). Historically,	this was done in user-space
       and called User-space Mode-Setting (UMS). Almost	all open-source
       drivers now provide the KMS kernel API to do this in the	kernel,
       however,	many non-open-source binary drivers from different vendors
       still do	not support this. You can use drmModeSettingSupported(3) to
       check whether your driver supports this.	To understand how KMS works,
       we need to introduce 5 objects: CRTCs, Planes, Encoders,	Connectors and
       Framebuffers.

       CRTCs
	   A CRTC short	for CRT	Controller is an abstraction representing a
	   part	of the chip that contains a pointer to a scanout buffer.
	   Therefore, the number of CRTCs available determines how many
	   independent scanout buffers can be active at	any given time.	The
	   CRTC	structure contains several fields to support this: a pointer
	   to some video memory	(abstracted as a frame-buffer object), a list
	   of driven connectors, a display mode	and an (x, y) offset into the
	   video memory	to support panning or configurations where one piece
	   of video memory spans multiple CRTCs. A CRTC	is the central point
	   where configuration of displays happens. You	select which objects
	   to use, which modes and which parameters and	then configure each
	   CRTC	via drmModeCrtcSet(3) to drive the display devices.

       Planes
	   A plane respresents an image	source that can	be blended with	or
	   overlayed on	top of a CRTC during the scanout process. Planes are
	   associated with a frame-buffer to crop a portion of the image
	   memory (source) and optionally scale	it to a	destination size. The
	   result is then blended with or overlayed on top of a	CRTC. Planes
	   are not provided by all hardware and	the number of available	planes
	   is limited. If planes are not available or if not enough planes are
	   available, the user should fall back	to normal software blending
	   (via	GPU or CPU).

       Encoders
	   An encoder takes pixel data from a CRTC and converts	it to a	format
	   suitable for	any attached connectors. On some devices, it may be
	   possible to have a CRTC send	data to	more than one encoder. In that
	   case, both encoders would receive data from the same	scanout
	   buffer, resulting in	a cloned display configuration across the
	   connectors attached to each encoder.

       Connectors
	   A connector is the final destination	of pixel-data on a device, and
	   usually connects directly to	an external display device like	a
	   monitor or laptop panel. A connector	can only be attached to	one
	   encoder at a	time. The connector is also the	structure where
	   information about the attached display is kept, so it contains
	   fields for display data, EDID data, DPMS and	connection status, and
	   information about modes supported on	the attached displays.

       Framebuffers
	   Framebuffers	are abstract memory objects that provide a source of
	   pixel data to scanout to a CRTC. Applications explicitly request
	   the creation	of framebuffers	and can	control	their behavior.
	   Framebuffers	rely on	the underneath memory manager for low-level
	   memory operations. When creating a framebuffer, applications	pass a
	   memory handle through the API which is used as backing storage. The
	   framebuffer itself is only an abstract object with no data. It just
	   refers to memory buffers that must be created with the drm-
	   memory(7) API.

fbdev 和 drm dev 有非常大的差别。

https://www.freebsd.org/cgi/man.cgi?query=drm-kms&sektion=7