做班级相册网站的目的意义,高新区建设局网站,wordpress底部九栏,网站开发师贴吧目录 零、本文讨论问题的范围一、问题#xff1a;SurfaceFlinger图层合成选择实现方式的两难1.1 从OpenGL ES、HWC本身来讲1.2 以HWC为主导的判断逻辑 二、SurfaceFlinger与HAL层进行交互的具体实现框架2.1 SurfaceFlinger 调用 OpenGL ES 流程2.2 FrameBuffer2.3 SurfaceFlin… 目录 零、本文讨论问题的范围一、问题SurfaceFlinger图层合成选择实现方式的两难1.1 从OpenGL ES、HWC本身来讲1.2 以HWC为主导的判断逻辑 二、SurfaceFlinger与HAL层进行交互的具体实现框架2.1 SurfaceFlinger 调用 OpenGL ES 流程2.2 FrameBuffer2.3 SurfaceFlinger 调用 HWC 的流程 三、通过HAL定义理解上述概念3.1 hwcomposer.h3.2 fb.h3.3 gralloc.h 零、本文讨论问题的范围 上图表示了Surface 如何被渲染。 借用官网的一段话“无论开发者使用什么渲染 API一切内容都会渲染到 Surface 上。Surface 表示缓冲区队列中的生产方而缓冲区队列通常会被 SurfaceFlinger 消耗。在 Android 平台上创建的每个窗口都由 Surface 提供支持。所有被渲染的可见 Surface 都被 SurfaceFlinger 合成到屏幕。” 本文关注的范围是上图红框中部分SurfaceFlinger做Layer合成时如何与HAL层的交互 一、问题SurfaceFlinger图层合成选择实现方式的两难
在处理Layer合成时SurfaceFlinger会与OpenGL ES、HWC进行交互。对于HWC由于各OEM的实现不一样所支持的能力也不一样很难直接用API表示硬件设备支持合成的Layer数量Layer是否可以进行旋转和混合模式操作以及对图层定位和硬件合成的限制等。这就导致了SurfaceFlinger作为调用端很难做决策根据当前的要合成的Layer数量数据量大小我该选择使用OpenGL ES还是HWC
1.1 从OpenGL ES、HWC本身来讲
在Android系统中相对于HWCOpenGL ES并不很擅长Layer的合成。 因为OpenGL ES主要是为游戏开发和图形渲染而设计的它并不针对图层合成进行优化。如果使用OpenGL ES进行图层合成会占用大量的GPU资源导致应用程序无法使用GPU进行自己的渲染。因此在需要进行高效图层合成的场景下HWC更适合使用。
1.2 以HWC为主导的判断逻辑
既然各OEM提供的HWC的能力是不同的有强、有弱但Layer合成任务又想优先使用HWC那么SurfaceFlinger的选择策略就交给HWC判断好了 SurfaceFlinger根据HWC硬件能力决定使用OpenGL ES还是使用HWC来处理Layer合成任务。
具体逻辑如下 SurfaceFlinger向HWC提供所有Layer的完整列表让HWC根据其硬件能力决定如何处理这些Layer。 HWC会为每个Layer标注合成方式是通过GPU还是通过HWC合成。 SurfaceFlinger负责先把所有注明GPU合成的Layer合成使用OpenGL ES到一个输出Buffer然后把这个输出Buffer和其他注明HWC合成的Layer一起交给HWC让HWC完成剩余Layer的合成和显示。
二、SurfaceFlinger与HAL层进行交互的具体实现框架
2.1 SurfaceFlinger 调用 OpenGL ES 流程 Gralloc 即 Graphics Alloc 图形分配 。 Android 系统在HAL层中提供了一个 Gralloc 模块封装了对 Framebuffer 的所有访问操作。 Gralloc 模块包含 fb 和 gralloc 两个设备fb 负责打开内核中的 Framebuffer 、初始化配置以及提供 post, setSwapInterval 等操作它是底层显卡的HAL层抽象gralloc 则管理帧缓冲区的分配和释放上层应用只能通过 Gralloc 访问 fb。 Android12 的源码中HAL层头文件定义的路径在源码根目录/hardware/libhardware/include/hardware/*.h 2.2 FrameBuffer
FrameBuffer 机制模仿显卡的功能是显卡硬件的抽象可以将 FrameBuffer 看成是显存的一个映像将其映射到进程地址空间之后就可以直接进行读写操作简单理解就是一段内存。用户应用不停的向这段内存中写入数据显示控制器不停地从中读取数据并显示出来。
2.3 SurfaceFlinger 调用 HWC 的流程 三、通过HAL定义理解上述概念
3.1 hwcomposer.h
上面我们提到HWC会为每个Layer标注合成方式
typedef struct hwc_layer_1 {int32_t compositionType;
}结构体 hwc_layer_1 中定义了一个 compositionType 变量表示当前Layer 的合成类型。可选的常量有 HWC_BACKGROUND、HWC_FRAMEBUFFER_TARGET、HWC_FRAMEBUFFER、HWC_OVERLAY、HWC_SIDEBAND、HWC_CURSOR_OVERLAY。 其中HWC_FRAMEBUFFER是这么注释的节选 * Set by the HWC implementation during (*prepare)(), this indicates* that the layer will be drawn into the framebuffer using OpenGL ES.HWC在准备阶段可能会将Layer的类型设置成 HWC_FRAMEBUFFER表示这个Layer会使用OpenGL ES画到 framebuffer 中。 再看 HWC_BACKGROUND * Always set by the caller before calling (*prepare)(), this value* indicates this is a special background layer. The only valid field* is backgroundColor.* The HWC can toggle this value to HWC_FRAMEBUFFER to indicate it CANNOT* handle the background color.总是由调用者在调用(*prepare)()之前设置这个值表示这是一个特殊的“背景”图层。唯一有效的字段 backgroundColor。HWC可以将此值切换为HWC_FRAMEBUFFER来表示它不能处理背景颜色HWC处理不了就只能是用OpenGl ES来处理。这里的调用者应该就是SurfaceFlinger了。
Hardware Composer 必须支持事件其中之一是 VSYNC另一个是支持即插即用 HDMI 的热插拔
3.2 fb.h
我们抽出几个属性有个大体印象
typedef struct framebuffer_device_t {/* dimensions of the framebuffer in pixels */const uint32_t width;const uint32_t height;/* framebuffer pixel format */const int format;/* resolution of the framebuffers display panel in pixel per inch*/const float xdpi;const float ydpi;/* framebuffers display panel refresh rate in frames per second */const float fps;......
}FrameBuffer设备的属性有宽高、像素格式、以dip为单位的分辨率、fps。 再看一个方法 /** Post buffer to the display (display it on the screen)* The buffer must have been allocated with the* GRALLOC_USAGE_HW_FB usage flag.* buffer must be the same width and height as the display and must NOT* be locked.** The buffer is shown during the next VSYNC.** Returns 0 on success or -errno on error.*/int (*post)(struct framebuffer_device_t* dev, buffer_handle_t buffer);post函数会将 buffer post到display上显示在屏幕上。 buffer的宽度要与fb设备宽高一致不能被锁。 在下一个VSYNC信号到来时buffer会显示出来。
3.3 gralloc.h
/*** Name of the graphics device to open*/
#define GRALLOC_HARDWARE_GPU0 gpu0看出 gralloc操作的设备就是GPU
enum {/* buffer will be used as an OpenGL ES texture */GRALLOC_USAGE_HW_TEXTURE 0x00000100U,/* buffer will be used as an OpenGL ES render target */GRALLOC_USAGE_HW_RENDER 0x00000200U,/* buffer will be used by the 2D hardware blitter */GRALLOC_USAGE_HW_2D 0x00000400U,/* buffer will be used by the HWComposer HAL module */GRALLOC_USAGE_HW_COMPOSER 0x00000800U,/* buffer will be used with the framebuffer device */GRALLOC_USAGE_HW_FB 0x00001000U,/* buffer may be used as a cursor */GRALLOC_USAGE_CURSOR 0x00008000U,/* buffer will be used with the HW video encoder */GRALLOC_USAGE_HW_VIDEO_ENCODER 0x00010000U,/* buffer will be written by the HW camera pipeline */GRALLOC_USAGE_HW_CAMERA_WRITE 0x00020000U,/* buffer will be read by the HW camera pipeline */GRALLOC_USAGE_HW_CAMERA_READ 0x00040000U,......
}gralloc graphics allocation字面意思图形分配其实就是开辟一段内存操作的是GPU那就是显存。 这里定义了一个枚举为分配出的 buffer 标记了分类按使用用途分出的类别。 这里有做为 OpenGL ES texture 使用的、被 HWComposer HAL module 使用的、被硬件视频编码器使用的、被摄像头管道写入/读出的。还发现一个有意思的是GRALLOC_USAGE_CURSOR 光标竟然是单独一种类型的 buffer。
核心方法
typedef struct alloc_device_t {struct hw_device_t common;/* * (*alloc)() Allocates a buffer in graphic memory with the requested* parameters and returns a buffer_handle_t and the stride in pixels to* allow the implementation to satisfy hardware constraints on the width* of a pixmap (eg: it may have to be multiple of 8 pixels). * The CALLER TAKES OWNERSHIP of the buffer_handle_t.** If format is HAL_PIXEL_FORMAT_YCbCr_420_888, the returned stride must be* 0, since the actual strides are available from the android_ycbcr* structure.* * Returns 0 on success or -errno on error.*/int (*alloc)(struct alloc_device_t* dev,int w, int h, int format, int usage,buffer_handle_t* handle, int* stride);这个方法就是分配显存传入参数 宽、高、格式、使用用途。返回 buffer_handle_t、步长。 上述对 HAL层头文件简单浏览有助于我们对这几个概念有更深的印象。
