【无标题】

IMX8 图像使用 — 2

第九章 通用缓冲区管理
GBM(图形缓冲区管理)API是DRM KMS (Linux直接呈现管理器-内核modeset API)上的一个薄层，它提供了一种为图形呈现分配缓冲区的机制。GBM旨在作为EGL在DRM上的原生平台。它创建的句柄可以用于初始化EGL和创建呈现目标缓冲区。这可以作为一个现代OpenGL ES FBDEV恢复，因为它允许完全使用DRM KMS API与OpenGL ES加速。
从i.MX 8开始，支持DRM，建议使用GBM。GBM还提供了分配修饰符固定表面的选项，供Wayland合成器和X11服务器渲染。
9.1 DRM格式修饰符简介
DRM格式修饰符是一个带有供应商前缀的64位半不透明无符号整数。大多数修饰符代表一种具体的、特定于供应商的图像平铺格式。一些例外是DRM_FORMAT_MOD_LINEAR(这不是供应商具体);DRM_FORMAT_MOD_NONE(这是一个别名的DRM_FORMAT_MOD_LINEAR由于历史事故);和DRM_FORMAT_MOD_INVALID(不表示平铺格式)。修饰符的供应商前缀由8个最高有效位组成。规范的修饰符和厂商前缀列表可以在Linux内核源代码的drm_fourcc.h中找到。
Linux生态系统中修饰器的一个目标是为每个供应商列举一组大小合理的平铺格式，这些格式适合于跨进程、api和/或设备共享的图像，其中每个参与组件可能来自不同的供应商。一个非目标是枚举所有供应商支持的所有平铺格式。一些由供应商内部使用的平铺格式不适合共享;这种平铺格式不应该使用任何修饰符。

修饰符值通常不描述内存布局。更精确地说，修饰符的下56位通常没有结构。
相反，修饰符命名内存布局;他们命名了一小部分供应商首选的图像共享布局。因此，在每个供应商名称空间中，修饰符值通常从1开始顺序分配。
每个修饰符通常由单个供应商支持，其名称与模式匹配
{供应商}FORMAT_MOD *或DRM_FORMAT_MOD_{供应商}_ *。例如DRM_FORMAT_MOD_VIVANTE_TILED和DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED。一个例外是DRM_FORMAT_MOD_LINEAR，它被大多数厂商支持。

Linux中的许多api使用修饰符来协商和指定共享映像的内存布局。例如，Wayland合成器和Wayland客户端可以通过在Wayland协议zwp_linux_dmabuf_v1上中继修饰符，为共享的wl_buffer协商特定于供应商的平铺格式。客户端可以使用GBM为wl_buffer分配底层内存，并为gbm_bo_create_with_modifiers提供所选择的修饰符。然后，客户端可以将wl_buffer导入Vulkan以生成图像内容，并将资源的dma_buf提供给VkImportMemoryFdInfoKHR及其修饰符VkImageDrmFormatModifierExplicitCreateInfoEXT。然后，排序器可以将wl_buffer导入OpenGL进行采样，并为eglCreateImage提供资源的dma_buf和修饰符。合成器也可以绕过OpenGL，直接将wl_buffer提交给内核的显示API，通过drm_mode_fb_cmd2提供dma_buf和修饰符。
第十章 Wayland and Weston
10.1概述
Wayland是合成器与客户端通信的协议，也是该协议的C库实现。Wayland是X的一个更简单的替代品，更容易开发和维护。合成器可以是一个独立的显示服务器，运行在Linux内核模式设置和evdev输入设备上，一个X应用程序，或者一个Wayland客户端本身。客户机可以是传统的应用程序、X服务器(无根或全屏)或其他显示服务器。
10.2 Wayland EGL
Wayland-EGL是Wayland的客户端实现，它将EGL堆栈和缓冲区共享机制绑定到通用Wayland API。前端的wayland-egl现在是wayland的一部分，i.MX图形驱动支持缓冲区共享机制的实现。
10.3 Weston Compositor
Weston是Wayland合成器的参考实现。Weston合成器是最小和轻量级的，适合许多嵌入式和移动用例。Weston支持多种渲染器和后端，需要根据处理器配置进行适当的选择。这通常是在i.MX图像中预设的。
10.3.1Weston后端
Weston有实现来支持不同的显示api，这被称为后端。i.MX 8支持KMS/DRM，因此使用DRM后端，而i.MX 6/7使用FBDEV后端。i.MX graphics继续支持FBDEV后端图形加速。
10.3.2 Weston渲染器
10.3.2.1 GL渲染器
GL (GLES)渲染器实现是Weston的默认实现。GL渲染器将从克隆和地图传递的缓冲区作为纹理。在初始设置之后，客户端只需要告诉合成器使用哪个缓冲区，以及何时何地向其中呈现了新内容。
10.3.2.2 G2D渲染器
G2D是2D API，关于G2D API的详细信息请参见第2章。G2D渲染器提供了2D GPU加速Weston的机制。2D图形引擎减少了3D GPU的负担，节省了功耗，并与SoC的视频功能很好地集成在一起。G2D排版器可以提高系统带宽利用率，因此在复杂的用例环境下，其性能将优于GL排版器。
打开Linux镜像文件中的文件:/etc/xdg/weston/weston.ini。
use-g2d = 1
10.3.3 Weston Shells
Weston支持多个shell，每个shell都有自己的客户端公共协议接口。这意味着必须专门为shell协议编写客户机。否则，它将不起作用。下面是当前支持的shell。
10.3.3.1桌面shell
桌面外壳就像一个典型的X桌面环境，专注于传统的键盘和鼠标用户界面以及熟悉的桌面式窗口管理。桌面外壳由桌面外壳插件桌面外壳组成。特殊的客户端weston-desktop-shell提供壁纸、面板和屏幕锁定对话框。
10.3.3.2全屏壳
全屏shell用于需要接管整个输出的客户端，通常是所有输出。这主要是为了在Weston上运行另一个合成器。另一个排序器不需要处理任何平台细节，如DRM/KMS或evdev/libinput。这个外壳只包含外壳插件fullscreen-shell.so。
10.3.3.3 IVI-shell
车载信息娱乐外壳是一个特殊用途的外壳，暴露了一个GENIVI层管理器兼容的API到控制器模块，和一个非常简单的外壳协议的客户端。IVI-shell从加载IVI-shell开始。然后是一个控制器模块它可以启动助手客户端。这个shell提供了设置窗口位置的选项，需要从客户端应用程序进行编程。
第十一章 X窗口加速度

X11在i.MX 8上通过Xwayland加速。不支持i.MX 6。
第十二章 高级的GPU配置
12.1 GPU伸缩调节器
i.MX 8QuadMax GPU设计支持不同的运行模式:超速、标称和欠驱动。默认为标称模式，超速模式被认为是性能/基准模式，而欠驱动模式被认为是节能模式。
3种模式可以通过命令行切换，不需要重新编译GPU驱动程序。

$ echo "overdrive" > /sys/bus/platform/drivers/galcore/gpu_govern 
$ echo "nominal" > /sys/bus/platform/drivers/galcore/gpu_govern 
$ echo "underdrive" > /sys/bus/platform/drivers/galcore/gpu_govern

查看当前运行的模式，使用如下命令行:

$ cat /sys/bus/platform/drivers/galcore/gpu_govern

12.2 GPU设备散热
i.MX设备支持热驱动，可以向GPU驱动发送过热事件信号，一旦GPU驱动接收到事件，可以启用GPU DFS特性，将GPU频率降低为原来指定时钟的N/64。
在原BSP版本中，缺省的N因子为1，终端用户可以通过以下命令重新配置:

echo N >/sys/bus/platform/drivers/galcore/gpu3DMinClock

用户也可以查看已经存在的配置，如下所示:

cat /sys/bus/platform/drivers/galcore/gpu3DMinClock

第十三章 Vivante IDE
13.1 VivanteIDE概述
VivanteIDE为一组应用程序提供了单一的接口，用于图形、计算、视觉和神经网络应用程序开发人员快速开发和移植独立或作为IDE的一部分的应用程序。VivanteIDE构建在Eclipse之上，CDT VivanteIDE功能包括以下关键特性。
•项目管理
项目经理支持每个文件的单独编译选项。此外，工作区选项定义了项目依赖关系，从而消除了手动管理文件构建的需要。
•源代码智能编辑和分析
VivanteIDE Editor提供了节省时间的编辑功能，如提前输入结构、单词补全和自动代码缩进，以实现可读的格式化代码视图。
•自动代码生成
内核开发向导可以根据简单的输入自动生成内核代码。
•性能和带宽分析
选项卡窗口提供分析器信息。每当分析器被怀疑时，累积的统计信息就会被更新。对于OGL应用，提供了VPD分析仪。
•事后性能分析
VPD Analyzer将GPU应用程序运行时记录的硬件数据可视化。
•纹理浏览和转换
纹理浏览器和转换器支持纹理文件预览和格式转换。
•用于OGL, OCL和OVX编译的命令行工具。
用于Vulkan应用程序开发的命令行工具。
•用于纹理压缩/解压和平铺/去平铺的命令行工具。
13.1.1 VivanteIDE组件概述
VivanteIDE为执行不同的活动提供了命令行工具和GUI“透视”视图。有些功能可以通过GUI和命令行使用，而像vCompiler和vcCompiler这样的工具只能通过命令行语法使用。

第十六章 应用程序编程建议
下面列出的建议采用了一种整体的方法，以平衡图形和系统资源的整体系统级优化为中心。
16.1了解系统配置和目标应用
了解关于应用程序和用例的细节可以让开发人员在理想的访问模式中正确地利用硬件资源。例如，如果绘制调用序列顺序正确，2D或3D GUI的实现可以在单个传递中呈现，而不是多个传递。此外，了解最常见的图形函数调用允许开发人员并行化呈现以最大化性能。
使用Vivante和特定于厂商的SoC分析工具，您可以确定GPU和CPU中的瓶颈，并根据需要进行更改。例如，在3D游戏中，大多数CPU周期可能会花在音频处理、AI和物理上，而很少花在GPU的渲染或场景设置上。在这种情况下，应用程序是cpu绑定的，需要检查和修改处理非图形任务的配置。如果系统是GPU绑定的，分析器可以指出GPU编程代码瓶颈的位置，以及优化哪些部分以消除限制。
16.2优化片外数据传输，如访问片外DDR内存/移动DDR内存
任何芯片外的数据传输都会占用SoC中其他功能块的带宽和资源，增加功耗，并导致额外的延迟周期，因为GPU管道需要等待数据从内存返回。使用片上缓存并编写应用程序以更好地利用缓存的局部性和一致性来提高性能。此外,从CPU访问GPU帧缓冲(不推荐)导致司机冲洗所有排队渲染命令在命令缓冲区,减速性能随着GPU等部分由于命令队列是空的(资源利用效率低)和CPU-GPU同步不是并行。
16.3避免应用程序中出现w -clip问题
w-剪裁溢出问题通常发生在以下三个因素中:
具有非常大的原语的对象。
在3D场景中，这通常是天空、外部世界或一条延伸到镜头后面和镜头前面很远的漫长道路。与此同时，物体也可能在x或y方向上扩展得很远。
•值很小的近平面
通常这个值非常接近于零。一个例子是10-4
•大屏幕分辨率
在IEEE单精度浮点格式中，这三个因素会导致最终窗口坐标溢出24位尾数精度。
为避免应用程序溢出，建议修改方法如下:

1. 对于带有非常大的原语(如sky或world)的绘制调用，将近平面设置为0.99作为初始值。
2. 如果这消除了渲染错误，并且整个场景被正确渲染，这个问题就可以被认为解决了。
   3.如果渲染错误仍然存在，并且没有需要的对象被剔除(或者没有缺少的对象)，那么增加近平面值，直到渲染错误消失。
3. 如果接近平面的值已经很大(>10.0)，问题仍然存在，一些理想的对象正在被剔除，减少接近平面的值，直到理想的对象再次出现，然后执行下一步。
4. 将较大的对象镶嵌成较小的原语，直到渲染错误消失。
   请注意，建议的近平面调整可以在每次绘制调用的基础上完成，并且只需要对具有非常大的原语的对象进行修改。一些应用程序通过减少顶点着色器中的w值来缩放对象，因为改变w值最终会影响到近平面，这是不推荐的，一个更好的缩放对象的方法是缩放x, y, z坐标，而不是w。
   16.4使用遮挡查询时，避免GPU挂起和数据损坏
   描述:
   在i.MX 6Dual/Quad GPU IP中，Hz (Hierarchical Depth)写和OQ (Occlusion Query)写共用一个端口。如果开启了HZ Fast Clear (FC)， OQ使用HZ端口写操作，可能会导致HZ FC数据损坏，甚至导致GPU异常挂起。
   软件解决方案:
   建议针对此问题使用软件解决方案，从L4.9 bsp版本可获得。因为这个问题很少发生，所以针对每个应用程序的工作是最有效的。软件将通过每个应用程序检测禁用HZ，并提供一个新的环境变量控制(VIV_DISABLE_HZ)。
   16.5避免随机访问cache或内存
   缓存抖动、未命中以及需要访问外部内存中的数据会导致性能下降。一个例子是随机纹理缓存访问，因为如果纹理单元需要随机访问缓存，并且如果缓存缺失就会离开芯片，那么在执行逐像素纹理读取时将非常昂贵。
   16.6优化系统内存使用
   内存是一种宝贵的资源，需要在GPU(帧缓冲区)、CPU、系统和其他应用程序之间共享。如果你为你的OpenGL ES应用程序分配了太多的内存，那么系统剩余部分的可用内存就会减少，这可能会影响系统性能。请求应用程序所需的足够内存，然后在应用程序不再需要它时释放它。例如，您可以只在需要或应用程序只需要部分资源时才分配深度缓冲区，首先加载必要的项，然后再加载其余的项。
   16.7瞄准固定的帧速率，明显平滑
   平滑的帧率是通过固定的FPS和视觉上可接受的最低FPS(帧每秒)的组合来实现的。因为帧率越高，图像引擎的负载就越高，所以功耗和帧率之间存在一个权衡。如果应用程序在30帧/秒的情况下是流畅的，并且在50帧/秒的情况下没有视觉差异，那么开发者应该将FPS限制在30，因为额外的20帧/秒不会产生视觉差异。FPS限制也保证了在任何时候都可以达到帧率。FPS的节省有助于降低GPU和系统功耗。
   16.8最小化GL状态变化
   在绘制调用之间设置状态值会增加应用程序性能的大量开销，因此必须将它们最小化。大多数这些调用设置都是多余的，因为在绘制之前要保存/恢复状态。尽量避免在绘制调用之间设置多个状态调用或为多个调用设置相同的值。有时，当使用一个特定的纹理时，最好是围绕该纹理排序绘制调用，以避免纹理抖动，从而抑制性能。应用程序开发人员还应该尝试对状态更改进行分组。
   16.9批处理原语，以减少绘制调用的数量
   当你的应用程序提交原语供OpenGL ES处理时，CPU会花时间准备命令供GPU硬件执行。如果您将绘制调用批量处理为更少的调用，则可以减少CPU开销并提高绘制调用的效率。
   批处理允许快速执行一组绘制调用，而不需要任何来自CPU(驱动程序或应用程序)的干预。
   批处理原语的一些例子有:
   •着色器中的分支可能允许更好的批处理，因为每个分支可以被分组在一起执行
   •对于像三角形条这样的基本类型，开发人员可以将多个共享相同状态的条组合在一起，以保存连续的绘制调用(和状态更改)，为多个三角形使用相同状态(单个设置)的单个批处理调用。
   •开发人员还可以整合近距离绘制的原语，以利用空间关系。如果批处理的原语距离太远，如果它们在框架中不可见，应用程序就很难有效地剔除它们。
   16.10执行每个顶点的计算，而不是每个片段/像素
   由于顶点的数量通常比碎片/像素的数量少得多，因此对每个顶点进行计算以节省处理能力会更便宜。
   16.11启用early-Z、hierarchy - z和背面剔除
   硬件支持深度测试来确定对象是否在用户的视场中，用于节省顶点和像素处理的工作量和处理。如果对象在视图中，那么顶点将被发送到管道中进行处理。如果对象是隐藏的或不可见的，三角形将被剔除，不发送到管道。这提高了图形性能，因为计算只花费在可见对象上。如果应用程序已经知道场景或屏幕中物体的内容和相对位置的细节，开发人员可以使用该信息自动绑定不需要触摸的区域(例如，具有多层表盘的汽车应用程序，其中底层表盘的部分被遮挡，可以让应用程序从一开始就避免遮挡区域)。另一种优化是在CPU上执行基本的剔除，因为CPU拥有关于场景细节和对象位置的第一手信息，所以它知道将哪些场景数据发送给GPU。
   16.12谨慎使用分支
   静态分支表现良好，因为状态是已知的，但它们倾向于使用许多通用寄存器。一个例子是一个长着色器，它将多个着色器组合成一个单一的，大的着色器，减少状态变化和批处理绘制调用。动态分支的开销是非恒定的，因为它将多个像素作为一个处理，并且无论是否使用分支，所有内容都将执行。换句话说，动态分支并行地通过不同的排列/分支来获得正确的结果。如果所有像素都走相同的路径，那么性能就很好。处理的像素越多就意味着更高的开销和更低的性能。对于动态分支，较小的像素大小/组对于吞吐量是最优的。开发人员需要注意代码中的分支，以确保过度的计算和分支是有效的。分析工具可以帮助确定代码的某些部分是否得到了优化。
   16.13使用VBOs代替静态或堆栈数据作为顶点数据
   一个顶点缓存对象(VBO)是一个缓冲区对象，它提供了顶点阵列和显示列表的优点，并允许在向GPU上传数据(顶点位置、颜色、法线和纹理坐标)时获得大量的性能收益。VBOs在内存中创建缓冲区对象，并允许GPU直接访问内存，而无需CPU干预(DMA)。内存管理器可以使用应用程序的反馈来优化缓冲区的位置。VBOs还可以处理静态和动态数据集，并由Vivante驱动程序管理。每一种方法的好处是:
   •顶点数组减少了函数调用的数量，并允许冗余数据在相关的顶点之间共享，而不是每次重新发送所有的数据。可以通过数组索引引用对数据的访问。
   •显示列表允许命令存储以供以后执行，可以在多个帧中重复使用，而无需重新传输数据，从而最大限度地减少CPU传输数据的周期。显示列表也可以被多个OpenGL / OpenGL ES客户端共享，这样它们就可以访问具有相应标识符的相同缓冲区。如果你把昂贵的计算操作(如照明或材料计算)放在显示列表中，那么这些计算将被处理
   当列表创建后，最终结果可以多次重用，而不需要再次计算。
   如果您通过使用VBO将两者的优点结合起来，那么与静态数据集或堆栈数据集相比，性能将得到增强。
   16.14在数据逐帧变化的情况下使用动态VBO
   在GPU使用静态顶点缓冲区时锁定它会造成性能损失，因为GPU需要在返回调用应用程序之前完成从缓冲区中读取顶点数据。每帧多次从静态缓冲区锁定和渲染也会阻止GPU缓存渲染命令，因为它必须在返回锁指针之前完成命令。如果没有缓冲命令，GPU将一直处于空闲状态，直到应用程序填充顶点缓冲区并发出绘制命令。
   如果场景数据从不从一帧到另一帧变化，那么一个静态缓冲区就足够了。对于更新的应用程序(如游戏、地图)，它们具有动态视图，其中顶点数据每帧或帧到帧多次更改，然后需要一个动态VBO来确保性能仍然满足。当一个锁被调用时，如果当前的缓冲区正在被GPU使用，一个指向新的缓冲区位置的指针会返回给应用程序，以确保更新的数据被写入新的缓冲区。当应用程序将更新的数据放入新的缓冲区时，GPU仍然可以访问旧的数据(当前缓冲区)。Vivante内存管理单元和驱动程序自动负责分配、重新分配或销毁缓冲区。
   您可以根据自己的喜好实现动态VBO，但有一种建议是分配1 MB的动态VBO块，并为每个动态缓冲区使用不同的偏移量来上传数据。如果缓冲区溢出，则可以循环回去并再次使用位置偏移0。
   16.15镶嵌你的数据使分层Z (HZ)工作
   我们可以将其分解为OpenGL和OpenGL ES如何处理这个用例。
   OpenGL只渲染简单的凸多边形(边只在顶点相交，没有重复的顶点，只有两条边在任何顶点相交)，此外还有点、线和三角形。如果应用程序需要凹多边形(有孔或相交边的多边形)，这些多边形需要细分为简单的凸多边形，这称为镶嵌(将一个多边形网格细分为一堆较小的网格)。一旦你将所有网格放置到位，我们的HZ硬件便能够自动剔除隐藏的多边形去有效地处理帧，并有效地将帧分割成能够快速处理的较小块。
   OpenGL ES只渲染三角形、线条和点。OpenGL的概念和OpenGL是一样的，为了避免非常大的多边形，我们将它们分解成更小的多边形，我们的内部GPU调度程序可以将它们分布到多个线程中，以完全并行化进程并移除隐藏的多边形。
   16.16使用动态纹理作为纹理缓存(纹理图集)
   使用动态纹理作为缓存的主要原因是，应用程序开发人员可以创建一个更大的纹理，它被细分为不同的区域(纹理图集)。应用程序可以将数据上载到每个区域，并使用应用程序侧纹理图集来访问数据。每个动态纹理和子区域可以根据需要锁定、写入和解锁每一帧。这种分配一次的方法比使用多个较小的纹理更有效，这些纹理需要每次分配，生成，然后销毁。
   16.17将小三角形条缝在一起
   最好将几个空间相关的小三角形条组合成一个更大的三角形步长，以最小化开销并提高性能。对于每个三角形带，CPU和GPU都需要额外的开销和启动成本，包括状态负载。如果需要加载的小三角形条太多，会影响性能。应用程序开发人员可以通过添加一个退化三角形来将多个三角形条组合在一起。重新启动多个新条带的开销比添加退化三角形要高得多。
   16.18精确地指定EGL配置属性
   为了获得一个16位/像素的窗口缓冲区用于渲染，需要根据EGL规范精确地指定EGL配置属性。指定不准确的EGL属性可能会导致获得一个32位/像素的窗口缓冲区，这将使渲染所需的带宽增加一倍，从而导致较低的性能。
   16.19使用对齐的纹理/渲染缓冲区
   gpu工作在缓冲区与硬件特定的宽度/高度对齐，以获得更好的效率。使用可用的API来查询GPU缓冲区对齐，并分配纹理/渲染缓冲区来满足这些要求，以避免对齐阴影内存的拷贝成本。
   16.20禁用MSAA渲染，除非需要高质量
   虽然MSAA渲染可以实现更平滑的线条和三角形边缘的更高的图像质量，但它需要更高的(4x, 8x)带宽，因为它必须渲染单个像素4倍/8倍。因此，如果不需要高渲染质量，则应禁用MSAA。
   16.21避免部分清除
   大多数gpu都有特殊的硬件逻辑来快速清除整个缓冲区。因此，最好使用快速清除函数来清除整个缓冲区，然后再次呈现图形，而不是执行部分清除来保留图形区域。如果应用程序需要部分清除，请确保清除区域按照gpu特定的要求对齐。未对齐的部分清除代价很高，应该避免。
   16.22避免掩码操作
   不要使用蒙版，除非蒙版为0(除非你需要特定的渲染质量)。使用掩模(颜色/深度模板掩模)清除表面可能会影响性能。在某些gpu上，像素掩码操作通常是非常昂贵的，因为掩码操作必须在每个像素上执行。
   16.23使用MIPMAP纹理
   MIPMAP纹理使应用程序采样较低分辨率的纹理图像(1/2,1/4,1/ 8,1 /16，…原始纹理图像的大小)，当三角形在距离视点更远的地方渲染时。因此，减少了读取纹理图像所需的带宽，从而获得了更好的性能。
   16.24使用压缩纹理，如果RAM/ROM预算受限
   压缩纹理通常只是原始纹理大小的一个分数(高达1/8)。当使用硬件支持的格式时，使用压缩纹理可以减少内存中的存储需求，还可以减少所需的纹理上传带宽。
   压缩纹理不应该被选择，如果只是为了在渲染过程中减少纹理采样所需的内存带宽。这是因为来自GPU的读取请求大小固定，内存控制器负载与未压缩的纹理相同。
   16.25尽可能从近到远绘制对象
   从近到远绘制物体通常有更好的性能，因为近前景中的物体可以遮挡背景中的整个或部分物体。大多数gpu都有早期Z拒绝逻辑来拒绝Z比较失败的像素。GPU可以跳过对这些被拒绝的像素进行分片着色计算。
   16.26避免索引三角形带
   索引三角形带通常可以最大化顶点缓存的利用率，因为每组顶点数据可以在两个三角形中使用。然而，在GC2000和GC880 gpu中有一个勘误，它需要在驱动程序中将索引的三角形带转换为三角形列表。对于小的条带，转换开销可以忽略不计，但是对于大的几何图形，应该使用不同的原始类型。
   16.27限制顶点属性步长小于256字节
   大多数Vivante gpu提供了对256字节顶点属性跨步的本地支持。如果顶点属性步幅大于256字节，那么驱动程序必须复制顶点数据。硬件版本v55及更高版本(如GC7000L v55)支持OES3.1规范中要求的2048字节顶点属性跨步。
   16.28避免将缓冲区绑定到混合索引/顶点数组
   大多数Vivante gpu本身并不支持混合索引/顶点数组。因此，Vivante驱动必须复制索引和顶点数据，为GPU形成单独的顶点数据流。避免索引和顶点数据混合，这样驱动程序在执行这个任务时就不会受到性能的影响。
   16.29避免在渲染时使用CPU来更新纹理/缓冲区上下文
   不要在渲染过程中使用CPU来更新纹理/缓冲区上下文。使用CPU来更新纹理/缓冲区会导致渲染管道刷新和暂停，这样CPU就可以安全地更新缓冲区内容。管道刷新/暂停/恢复会对性能造成重大影响。
   16.30避免频繁切换上下文
   上下文切换是一个固有的昂贵操作，因为许多GPU状态需要重置来启动一个新的渲染上下文。因此，频繁的上下文切换会对应用程序性能产生负面影响。
   16.31优化shader中的资源
   大多数gpu对有限的资源(统一的，变化的，等等)有最优的支持。使用超出最佳工作集的资源会导致GPU从性能较低的内存池中获取/存储资源，从而对着色器性能产生负面影响。
   16.32小区域避免使用glScissor Clear
   对于小区域(小于16x8对齐窗口)，glScissor Clear会退回到CPU，所以性能不是最优的。
   16.33使用PRE加速数据传输
   PRE是一个优化的硬件，可以将平铺格式的图像转换为线性帧缓冲。使用PRE, GPU只能输出平铺的渲染目标，而不需要解决它。要启用PRE特性，设置环境GPU_VIV_EXT_RESOLVE变量为1;否则设置为0。它在FB后端的默认值是1，这意味着PRE在FB上是默认启用的。
   16.34 i.MX 8QuadMax双gpu性能
   对于一些纹理/渲染尺寸较小、着色器不那么复杂的遗留应用，双GPU的性能可能会比单GPU模式更差，因为双GPU编程需要更多的CPU努力，驱动开销比硬件管道中的GPU负载更重要。
   对于这样一种遗留的情况，用户可以单gpu在i.MX 8QuadMax上实现更好的性能。