OpenGL ES3.0

OpenGL ES3.0

前言

一、OpenGL ES3.0 基础概念

二、OpenGL ES3.0与2.0的区别

三、OpenGL ES 3.0 PBO 的使用

四、动效

---

---

Android渲染架构

• image stream produceers：渲染数据的生产者，如App的draw方法会把绘制指令通过canvas传递给framework层的RenderThread线程。
• native Framework：RenderThread线程通过surface.dequeue得到缓冲区graphic bufer，然后在上面通过OpenGL来完成真正的渲染命令。在把缓冲区交还给BufferQueue队列中。
• image stream consumers：surfaceFlinger从队列中获取数据，同时和HAL完成layer的合成工作，最终交给HAL展示。
• HAL：硬件抽象层。把图形数据展示到设备屏幕。

可以看出，这其实是个很典型的生产者消费者模式。

• 图像生产者：也就是我们的APP，再深入点就是canvas->surface

• 图像消费者：SurfaceFlinger

• 图像缓冲区：BufferQueue，一般是3缓冲区

  OpenGL、Vulkan、Skia的区别

  • OpenGL：是一种跨平台的3D图形绘制规范接口。OpenGL EL则是专门针对嵌入式设备，如手机做了优化。

  • Skia：skia是图像渲染库，2D图形绘制自己就能完成。3D效果（依赖硬件）由OpenGL、Vulkan、Metal支持。它不仅支持2D、3D，同时支持CPU软件绘制和GPU硬件加速。Android、flutter都是使用它来完成绘制。

  • Vulkan：最早由科纳斯组织（Khronos Group）Android引入了Vulkan支持。VulKan是用来替换OpenGL的。它不仅支持3D，也支持2D，同时更加轻量级

    UI 组件在绘制到屏幕之前，都需要经过 Rasterization（栅格化）操作，而栅格化又是一个非常耗时的操作。

    Rasterization 栅格化是绘制那些 Button、Shape、Path、String、Bitmap 等显示组件最基础的操作。栅格化将这些 UI 组件拆分到显示器的不同像素上进行显示。这是一个非常耗时的操作，GPU 的引入就是为了加快栅格化。

    

    从图中可以看到，软件绘制使用 Skia 库，它是一款能在低端设备，如手机呈现高质量的 2D 跨平台图形框架，类似 Chrome、Flutter 内部使用的都是 Skia 库。

    硬件绘制的思想就是通过底层软件代码，将 CPU 不擅长的图形计算转换成 GPU 专用指令，由 GPU 完成绘制任务。

    所以说硬件加速的本质就是使用GPU代替CPU完成Graphic Buffer绘制工作，以实现更好的性能，Android从4.0开始默认开启了硬件加速，但还有一些API不支持硬件加速，因此需要手动关闭硬件加速。需要注意的是，软件绘制使用的Skia库，但这不代表Skia不支持硬件加速，从Android 8开始，我们可以选择使用Skia进行硬件加速，Android 9开始就默认使用Skia来进行硬件加速。Skia的硬件加速主要是通过 copybit 模块调用OpenGL或者SKia来实现。

    VSYNC信号
    

    CPU/GPU的处理时间较长，超过了16.6ms时, 在第二个时间段内，但却因 GPU 还在处理 B 帧，缓存没能交换，导致 A 帧被重复显示。而B完成后，又因为缺乏VSync信号，它只能等待下一个signal的来临。于是在这一过程中，有一大段时间是被浪费的。

    当下一个VSync出现时，CPU/GPU马上执行操作（A帧），且缓存交换，相应的显示屏对应的就是B。这时看起来就是正常的。只不过由于执行时间仍然超过16ms，导致下一次应该执行的缓冲区交换又被推迟了——如此循环反复，便出现了越来越多的“Jank”。

    三缓冲就是在双缓冲机制基础上增加了一个Graphic Buffer缓冲区，这样可以最大限度的利用空闲时间，带来的坏处是多使用的一个Graphic Buffer所占用的内存。

    三缓冲机制有效利用了等待vysnc的时间，可以帮助减少jank。

    RenderThread

    经过 Android 4.1 的 Project Butter 黄油计划之后，Android 的渲染性能有了很大的改善。不过你有没有注意到这样一个问题，虽然利用了 GPU 的图形高性能运算，但是从计算 DisplayList，到通过 GPU 绘制到 Frame Buffer，整个计算和绘制都在 UI 主线程中完成。

    UI 线程任务过于繁重。如果整个渲染过程比较耗时，可能造成无法响应用户的操作，进而出现卡顿的情况。GPU 对图形的绘制渲染能力更胜一筹，如果使用 GPU 并在不同线程绘制渲染图形，那么整个流程会更加顺畅。

    正因如此，在 Android 5.0 引入两个比较大的改变。一个是引入了 RenderNode 的概念，它对 DisplayList 及一些 View 显示属性都做了进一步封装。另一个是引入了 RenderThread，所有的 GL 命令执行都放到这个线程上，渲染线程在 RenderNode 中存有渲染帧的所有信息，可以做一些属性动画，这样即便主线程有耗时操作的时候也可以保证动画流程。

    图像消费者

    SurfaceFlinger是Android系统中最重要的一个图像消费者，Activity绘制的界面图像，都会传递到SurfaceFlinger来，SurfaceFlinger的作用主要是接收GraphicBuffer，然后交给HWComposer或者OpenGL做合成，合成完成后，SurfaceFlinger会把最终的数据提交给FrameBuffer。

    SurfaceFlinger是图像数据的消费者。在应用程序请求创建surface的时候，SurfaceFlinger会创建一个Layer。Layer是SurfaceFlinger操作合成的基本单元。所以，一个surface对应一个Layer。当应用程序把绘制好的GraphicBuffer数据放入BufferQueue后，接下来的工作就是SurfaceFlinger来完成了。

    

    系统会有多个应用程序，一个程序有多个BufferQueue队列。SurfaceFlinger就是用来决定何时以及怎么去管理和显示这些队列的。

    SurfaceFlinger请求HAL硬件层，来决定这些Buffer是硬件来合成还是自己通过OpenGL来合成。最终把合成后的buffer数据，展示在屏幕上。

    总得来说，Android图像渲染机制是一个生产者消费者的模型，如下图所示：

onMeasure、onLayout计算出view的大小和摆放的位置，这都是UI线程要做的事情，在draw方法中进行绘制，但此时是没有真正去绘制。而是把绘制的指令封装为displayList,进一步封装为RenderNode，在同步给RenderThread。



RenderThread通过dequeue拿到graphic buffer（surfaceFlinger的缓冲区），根据绘制指令直接操作OpenGL的绘制接口，最终通过GPU设备把绘制指令渲染到了离屏缓冲区graphic buffer。



完成渲染后，把缓冲区交还给SurfaceFlinger的BufferQueue。SurfaceFlinger会通过硬件设备进行layer的合成，最终展示到屏幕。



**GPU处理关键步骤：**

顶点处理：这阶段 GPU 读取描述 3D 图形外观的顶点数据并根据顶点数据确定 3D 图形的形状
及位置关系，建立起 3D 图形的骨架。在现有的 GPU 中，这些工作由硬件实现的 Vertex Shader
（顶点着色器）完成。



光栅化计算：显示器实际显示的图像是由像素组成的，我们需要将上面生成的图形上的点和
线通过一定的算法转换到相应的像素点。把一个矢量图形转换为一系列像素点的过程就称为
光栅化。例如，一条数学表示的斜线段，最终被转化成阶梯状的连续像素点。



纹理帖图：顶点单元生成的多边形只构成了 3D 物体的轮廓，而纹理映射（texture mapping）
工作完成对多变形表面的帖图，通俗的说，就是将多边形的表面贴上相应的图片，从而生成
“真实”的图形。TMU（Texture mapping unit）即是用来完成此项工作。



像素处理：这阶段（在对每个像素进行光栅化处理期间）GPU 完成对像素的计算和处理，从
而确定每个像素的最终属性。在支持 DX8 和 DX9 规格的 GPU 中，这些工作由硬件实现的 Pixel
Shader（像素着色器）完成。



最终输出：由 ROP（光栅化引擎）最终完成像素的输出，1 帧渲染完毕后，被送到显存帧缓
冲区。



GPU 的工作通俗的来说就是完成 3D 图形的生成，将图形映射到相应的像素点上，对每个像
素进行计算确定最终颜色并完成输出。

一、OpenGL ES3.0 基础概念

1、OpenGL 官网

OpenGL ES 官网： https://www.khronos.org/api/opengles

OpenGL ES 官方文档API： https://registry.khronos.org/OpenGL-Refpages/es3.0/

着色器语言说明：https://www.cnblogs.com/brainworld/p/7445290.html

OpenGLES 全称 OpenGL for Embedded Systems ，是三维图形应用程序接口 OpenGL 的子集，本质上是一个跨编程语言、跨平台的编程接口规范，主要应用于嵌入式设备，如手机、平板等。由 科纳斯（Khronos） 组织定义和推广，科纳斯是一个图形软硬件行业协会，该协会主要关注图形和多媒体方面的开放标准。

OpenGLES 3.0 实际上是 OpenGLES 2.0 的扩展版本，向下兼容 OpenGLES 2.0 ，但不兼容 OpenGLES 1.0

2、OpenGLES 3.0 主要新特性

纹理

• sRGB 纹理和帧缓冲区——允许应用程序执行伽马校正渲染。
• 2D 纹理数组——保存一组 2D 纹理的纹理目标。
• 3D 纹理。一些 OpenGL ES 2.0 实现通过扩展支持3D纹理，而 OpenGL ES3.0 将此作为强制的功能。
• 深度纹理和阴影比较——启用存储在纹理中的深度缓冲区。
• 无缝立方图。在 OpenGL ES 3.0 中，立方图可以进行采样如过滤来使用相邻面的数据并删除接缝处的伪像。
• 浮点纹理。

着色器

• 二进制程序文件。在 OpenGL ES 3.0 中，完全链接过的二进制程序文件可以保存为离线二进制格式，运行时不需要链接步骤。这有助于减少应用程序的加载时间。
• 非方矩阵。支持方阵之外的新矩阵类型，并在 API中 增加了相关的统一调用，以支持这些矩阵的加载。
• 全整数支持。支持整数（以及无符号整数）标量和向量类型以及全整数操作。
• 平面/平滑插值程序。 OpenGL ES 3.0 中插值程序可以显式声明为平面或者平滑着色。
• 统一变量块。统一变量值可以组合为统一变量块。统一变量块可以更高效地加载，也可在多个着色器程序间共享。
• 布局限定符。顶点着色器输入可以用布局限定符声明，以显式绑定着色器源代码中的位置，而不需要调用 API 。

几何形状

• 变换反馈。可以在缓冲区对象中捕捉顶点着色器的输出。
• 布尔遮挡查询。应用程序可以查询一个（或者一组）绘制调用的任何像素是否通过深度测试。
• 实例渲染。有效地渲染包含类似几何形状但是属性（例如变化矩阵、颜色或者大小）不同的对象。

缓冲区对象

• 统一变量缓冲区对象。为存储/绑定大的统一变量块提供高效的方法。统
• VAO 顶点数组对象。提供绑定和在顶点数组状态之间切换的高效方法。
• 采样器对象。将采样器状态（纹理循环模式和过滤）与纹理对象分离。
• 同步对象。为应用程序提供检查一组操作是否在GPU上完成执行的机制。
• 像素缓冲对象。使应用程序能够执行对像素操作和纹理传输操作的异步数据传输。
• 缓冲区对象间拷贝。提供了高效地从一个缓冲区对象向另一个缓冲区对象传输数据的机制，不需要CPU干预。

帧缓冲区

• 多重渲染目标（MRT）。允许应用程序同时渲染到多个颜色缓冲区。

• 多重采样渲染缓冲区。使应用程序能够渲染到具备多重采样抗锯齿功能的屏幕外帧缓冲区。

• 帧缓冲区失效提示。

3、调试工具

GAPID

GAPID (Graphics API Debugger)是 Google 的一款开源且跨平台的图形开发调试工具，用于记录和检查应用程序对图形驱动程序的调用，支持 OpenGL ES 和 Vulkan 调试。

OpenGL Google官方工具地址：https://github.com/google/gapid/releases

GAPID 的主要功能：

• 查看 OpenGL ES 或 Vulkan 绘图接口的调用情况（调用顺序、流程）；
• 查看传入着色器程序的参数；
• 查看纹理，导出模型、贴图等资源；
• 查看、修改以及导出 shader 脚本。

编译完 shader 脚本生成的二进制代码，可以通过 GAPID 抓取到并反编译成原来的 shader 源码。总而言之就是，你的 shader 脚本实际上是在 GPU 上裸奔，尤其是对手机厂商来说。

shader 脚本在 GPU 层面上目前并没有有效的加密或混淆方法，比较通用的做法是将 shader 中的变量无意义化，比如用 var1、var2 等表示，或者将一个 shader 拆分成多个小 shader ，以达到降低可读性的目的。

获取opengl 实列网址： https://www.shadertoy.com/

调试工具Android官网地址：Android GPU Inspector (AGI) ：https://developer.android.com/agi#downloads

二、OpenGL ES3.0与2.0的区别

OpenGL ES 3.0与OpenGL ES 2.0在基础概念上存在一些显著的区别，这些区别主要体现在图形管线的可编程性、新增的功能和特性以及着色器脚本的编写方式等方面：

1、图形管线的可编程性

• OpenGL ES 2.0：引入了可编程图形管线，允许开发者自己编写顶点着色器（Vertex Shader）和片段着色器（Fragment Shader）的代码。这两个阶段的着色器允许开发者对顶点和像素进行更细致的控制，从而实现更复杂的视觉效果。
• OpenGL ES 3.0：继承了OpenGL ES 2.0的可编程图形管线，并进一步增强了这一特性。OpenGL ES 3.0是向后兼容OpenGL ES 2.0的，意味着使用2.0编写的应用程序可以在3.0中继续运行。

2、新增功能和特性

• OpenGL ES 3.0

  相比于OpenGL ES 2.0，引入了许多新的功能和特性，这些功能使得开发更加灵活和便捷：

  • 纹理功能增强：支持sRGB纹理和帧缓冲区、2D纹理数组、3D纹理、深度纹理和阴影比较、无缝立方图、浮点纹理、ETC2/EAC纹理压缩、整数纹理等。
  • 渲染管线增强：实现了遮挡查询、变缓反馈、实例渲染、四个或更多渲染目标支持等。
  • 着色语言增强：新版GLSL ES 3.0着色语言全面支持整数和32位浮点操作。
  • 精确尺寸纹理和渲染缓冲格式：提供了一系列广泛的精确尺寸纹理和渲染缓冲格式，便于移动应用。

3、着色器脚本编写方式

• OpenGL ES 2.0：着色器脚本使用attribute和varying关键字来处理顶点和片段之间的数据传递。

• OpenGL ES 3.0

  ：着色器脚本的编写方式发生了较大变化，主要体现在以下几点：

  • 版本声明：必须在着色器脚本中使用#version 300 es声明为指定使用OpenGL ES 3.0版本。
  • 关键字变化：新增了in、out、inout关键字，用来取代attribute和varying关键字。
  • 输出方式变化：片段着色器不再使用gl_FragColor，而是使用out声明字段进行输出。
  • 变量赋值：可以直接使用layout对指定位置的变量赋值。

4、其他区别

• 兼容性：Op