• Variable%20Rate%20Shading

Variable%20Rate%20Shading(VRS，可变率着色)允许像素着色器一次着色一个或多个像素，这样一个着色计算可以代表一个像素或一组像素。VRS是反锯齿技术的逆解。抗锯齿技术通过平滑高变化的内容，更频繁地采样每个像素，以避免走样（aliasing）和锯齿（jagged）边缘。然而，如果要渲染的表面没有高的颜色变化或将在随后的通道上被模糊(例如，运动模糊)，在每个像素都一个着色计算的操作通常是低效的。

VRS允许开发者指定着色率，其中只对一个像素执行一个着色器计算，结果操作应用于指定的像素组配置。如果使用得当，应该不会导致视觉质量下降，同时显著减轻GPU渲染的负担，从而节省功耗并提高性能。

VRS示意图。画面根据颜色变化频率采用不同的着色率，变化高的采用高着色率（如汽车），反之用低着色率（如左下和右下路面）。

VRS支持的常见着色率和运行机制。其中黄点是着色坐标，绿点是直接复用黄点的着色结果。

VRS在渲染管线的工作机制。VRS在光栅化阶段采用指定着色率执行光栅化，进入PS之后再放大。

UE可以给每个材质设定1个着色率，在材质属性模板中：

VRS优化的核心思想在于减少计算次数并复用周边计算点的结果，从而达到提升渲染效率的目的。适合使用VRS的情形：

• 颜色变化率低的物体。
• 处于运动模糊区域的物体。
• 景深范围之外的物体。

使用移动端的VRS需要依赖不同图形API的扩展：

// ------ OpenGLES ------// Qualcomm QCOM_shading_rateGL_SHADING_RATE_1X1_PIXELS_QCOMGL_SHADING_RATE_1X2_PIXELS_QCOM......// Arm / Imagination Tech(不支持)// ------ Vulkan ------VK_KHR_fragment_shading_rate

• 使用Vulkan代替OpenGL。

相比OpenGL等传统API，Vulkan支持多线程，轻量化驱动层，可以精确地管控GPU内存、同步等资源，避免运行时校验，基于命令队列的机制，没有全局状态等等（下图）。

得益于Vulkan的先进设计理念，使得它的渲染性能更高，通常在CPU、GPU、带宽、能耗等指标都优于OpenGL。但如果是应用程序本身的CPU或者GPU负载高，则使用Vulkan的收益可能没有那么明显：

• 使用遮挡剔除。

遮挡剔除可以提前剔除掉被遮挡的物体或者远处占屏幕很小的物体，避免进入GPU管线，占用带宽和计算资源。UE在移动端的遮挡剔除延迟了两帧（因为BasePass结束之后才有深度缓冲，需要再增加一帧延迟确保结果可用）：

然后是在RHI线程等待遮挡查询的结果，遮挡查询的结果是在渲染线程使用，由于延迟了两帧，所以渲染线程在计算可见性时不需要等待：

使用遮挡剔除时，需要遵循以下建议：

1、只在需要时返回查询结果，不要等待它，因为同步等待是非常低效的。

2、对于遮挡，只在必要时使用精确计数选项。OpenGL ES使用GL_ANY_SAMPLES_PASSED,、Vulkan使用VK_QUERY_CONTROL_PRECISE_BIT = false，除非确实需要知道遮挡的数量。

3、不要修改正在绘制调用中引用的资源。

4、不要将GL_MAP_INVALIDATE_BUFFER /GL_MAP_INVALIDATE_RANGE与glMapBufferRange()一起使用，因为这些标志在某些版本的驱动会触发创建一个不必要的资源拷贝。

12.6.1.2 管线优化

• 曲面细分期间消除子像素。

曲面细分增加细节级别，并可以通过允许其他游戏子系统在低分辨率的网格表示上操作来减少内存带宽和CPU周期。然而，高级别的曲面细分可以产生子像素三角形，这导致光栅化利用率降低。利用距离、屏幕空间大小或其他自适应度量来计算避免子像素三角形的曲面细分因子是很重要的。

• 曲面细分期间开启背面剔除。

图元的背面剔除可以防止冗余的像素进入像素着色器中，从而提升性能。

• 删除未使用的render target或shader资源。

操作更多的RT或shader资源，会增加带宽，降低性能。故而尽量删除未引用的资源。

• 避免GMEM加载。

在每个Pass渲染之前，需要调用图形API明确清理RT。

OpenGL ES: glClear()

Vulkan: LOAD_OP_CLEAR / LOAD_OP_DONT_CARE

• 使用subpass或PLS。

Vulkan的subpass（或OpenGL ES的PLS）可以让多个pass的数据持续保存在GMEM（Tile缓冲区）中，避免数据反复从GMEM和全局内存之间传输，从而降低带宽和延时。

• 使用PSO缓存。运行时创建PSO对象比较消耗CPU性能，如果在离线阶段收集、编译材质使用的Shader并保存成二进制文件，以便下次运行时调用时直接读取Cache文件并转成PSO对象，可以降低CPU负载。下图是UE的PSO缓存机制图示：

更多详情请参看UE官方文档：PSO%20Caching。

• 使用仅深度（Z-only）渲染。

GPU有一种特殊的模式，可以以两倍于正常模式的速率写入Z-only像素，例如应用程序渲染阴影图。

有两种方式可以让GPU进入此模式：

1、图形API明确指示，硬件才能进入这个特殊的渲染模式。

2、应用程序通过特定的渲染状态提示驱动程序。比如：使用一个空的片元着色器和禁用Frame%20Buffer（帧缓冲区）写掩码。

一些渲染程序或引擎（如UE）会使用专用的PrePass来渲染深度，以充分利用Early-Z计算。不过对于移动端GPU需要谨慎对待，应以实际测试为准。

• 使用间接索引（indirect%20indexed）的绘制接口。

间接绘制调用将开销从CPU转移到GPU，从而减少CPU和GPU的带宽。例如，在加载时缓存绘制调用参数，以便在缓冲对象存储中渲染网格。这些缓存数据可以作为glDrawArraysIndirect%20或glDrawElementsIndirect的输入参数。

需要OpenGL%20ES%203.1才支持。

• Draw%20Call优化。
  • 合并几何物体，同时合并它们的材质。
  • 使用批处理，即便不是CPU受限，也可以减少能耗。
  • 使用实例化（instance）。
  • 使用非直接索引绘制。
  • 避免多次绘制小量物体。
  • 根据高中低画质设定合理的Draw%20Call数量。

使用批处理时，要注意顶点总数限制，不能超过索引的表达范围（通常最大是65k）。另外，如果合并或批处理之后的物体包围盒过大，反而会造成性能下降，因为无法有效使用Frustum%20Cullinig、遮挡剔除等技术进行剔除。

另外，需要注意提交的几何物体具有相邻性，尽量落在同一个Tile内，以减少覆盖的Tile数量，降低带宽，提升缓存命中率：

上：良好的几何物体提交顺序；下：错误的几何物体提交顺序。

• 禁用Alpha Test / Discard。

Alpha Test会打乱TBR的正常流程，造成渲染管线Stall，在PowerVR尤为明显（Alpha Test阶段会写回深度到HSR阶段）。

因为TB(D)R在渲染不透明物体时普遍开启了Early-Z技术和特殊的隐藏面消除技术（HSR、FPK），在此阶段会开启深度测试，并写入通过了深度测试的片元深度。但是，如果开启了Alpha Test或Shader中使用了Discard，无法在Early-Z/隐藏面消除技术阶段就确定该片元的深度是否有效，必须等执行完PS、Alpha Test等阶段才行：

这样就无法充分发挥HSR技术的优势，从而降低渲染性能。

可以使用Alpha Blend代替Alpha Test。如果确实需要Alpha Test，则物体的渲染顺序需尊照此顺序：Opaque -> Alpha-tested -> Blended。

• 尽量减少Alpha Blend。

原因是延迟渲染器，比如PowerVR GPU，在片元着色器处理它之前计算片元的可见性，防止输出图像中的不可见片元被不必要地处理。如果需要透明对象，请尽量减少透明对象的数量。

由于Alpha Blend不能写入深度，不能充分利用HSR/FPK，会引发Overdraw，提升带宽和数据传输量。

如果确实需要，有以下优化建议：

1、优先使用unorm格式，而不是浮点数。（注意：此条来自Arm Mali的建议，其它GPU可能不一样，以实测为主）

2、如果是不透明物体，应禁用Blend和alpht to coverage。

3、不要在携带MSAA数据的浮点frame buffer上使用混合。

4、避免过高的OverDraw。监控每像素基础上生成的混合层数量，即使是简单的着色器，混合层数量高会因为片元数量多而快速消耗时钟周期。

5、考虑将大型UI元素分成不透明和透明部分。然后可以分别绘制不透明部分和透明部分，允许Early-ZS或FPK/HSR删除不透明部分下面的OverDraw。

6、不要仅仅在片元着色器中将alpha设置为1.0来禁用混合。

• 充分利用Early-Z和FPK/HSR剔除被遮挡的像素。

为了充分利用Early-Z，物体绘制顺序应该如下所示：

1、绘制不透明物体。从前向后绘制。

2、绘制镂空（Masked）物体。从前向后绘制。

3、绘制半透明物体。从后向前绘制。

对于广泛支持TBR架构的移动端GPU，不建议开启Prepass绘制专用的深度，否则反而会增加带宽和Draw Call。

另外，在绘制不透明物体时，尽量做到以下几点：

1、禁用discard语句。

2、禁用Alpha to Coverage。

3、禁止在片元着色器中修改深度。

若是违反以上任意一条，便会使Early-Z失效，强制使用Late-Z，从而降低渲染效率。

• 充分开启裁剪和测试。

裁剪技术包含遮挡剔除、视锥体裁剪、Scissor、距离裁剪、LOD等等。

测试包含背面测试、深度测试、模板测试等，但禁用透明度测试。

• 禁用Z-Prepass。

移动端GPU基于TBR结构通常内置了像素级的剔除，无需再专门绘制一次深度。UE在移动端默认禁用了Z-Prepass。

• 最小化模板缓冲的更新。

1、如果值相同，则使用KEEP而不是REPLACE。

2、有些渲染器（如UE）使用光照绘制Pass对（pair）：第一个Pass用于创建模板缓冲，第二个Pass用于给未蒙版的片元着色。可以在第二个Pass重置模板值，以便为下一个光照配对做好准备，这样可以避免多带带的模板清理操作。

UE的移动端场景渲染器在绘制光照时正是使用了此种模板清理优化方式。

• 正确调用图形API。

  • 除非达到了目标性能，否则不要以导致GPU空闲的方式使用API。

  • 不要过早等待渲染管线中的围栏（fence）和查询（query）对象的查询结果。

  • 调用glMapBufferRange()时使用GL_MAP_UNSYNCHRONIZED标记开启异步，防止渲染管线卡顿。

  • 避免同步方式调用以下接口：

    • glFlush()。但是，某些GPU（如PowerVR）由于使用了双缓冲机制，不会卡调用线程。
    • glFinish()
    • glReadPixels()
    • glWaitSync()
    • glClientWaitSync()
    • eglClientWaitSync()
    • 没有GL_MAP_UNSYNCHRONIZED标记的glMapBufferRange()

    避免不必要地调用以上接口，调用次数越少越好。

  • 避免使用glFlush()来分割渲染通道，因为驱动程序（Mali）会在需要时自动刷新。

  • 尽可能执行Clear。在绘制前或渲染通道开始时，使用glClear/glDiscardFramebufferEXT/glInvalidateFramebuffer执行渲染纹理的清理，防止GPU读取上一帧的数据到Tile缓冲区中，节省带宽。Vulkan则使用loadOp。

  • 尽可能使用glColorMask屏蔽不需要写入的颜色通道。

如果违反以上建议，有可能导致以下结果：

1、如果管道被耗尽，GPU在产生气泡期间部分空闲，导致性能损失。

2、根据与系统动态电压和频率缩放电源管理逻辑的相互作用，可能会有一些性能不稳定。

• 优化Command Buffer。

1、要获得最佳性能，请设置ONE_TIME_SUBMIT_BIT标志。不要设置SIMULTANEOUS_USE_BIT，除非确实需要。

2、构建每帧命令缓冲区，而不是使用同步命令缓冲区。

3、如果替代方法是每次在应用程序逻辑中重放相同的命令序列，则使用SIMULTANEOUS_USE_BIT。它比应用程序手动重放命令更有效，但比一次性提交缓冲区更低效。

4、不要使用设置了RESET_COMMAND_BUFFER_BIT的命令池，会增加内存管理开销，因为驱动程序无法为池中的所有命令缓冲区使用单个大型分配器。

5、使用secondary command buffer来允许多线程渲染通道的构造。

6、最小化每帧secondary command buffer的调用次数。

• 优化描述符集和布局（descriptor sets and layouts）。

1、尽可能多地打包描述符集绑定空间。

2、更新已经分配但不再引用的描述符集，而不是重置描述符池和重新分配新的描述符集。

3、重用预分配的描述符集，避免更新相同的信息。

4、使用VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC或VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC绑定相同的UBO或SSBO，但不同的偏移量。 另一种选择是构建更多的描述符集。

5、不要在描述符集中留下空白，会浪费空间，阻断访问连续性。

6、不要留下未使用的条目（entry），因为复制和合并依旧有消耗。

7、不要在性能关键的代码路径上从描述符池（descriptor pool）分配描述符集。

8、如果不打算更改绑定偏移量，就不要使用DYNAMIC_OFFSET UBOs/SSBOs，因为处理动态偏移量会有很小的额外成本。低效的描述符集和布局未优化的Vulkan描述符集和布局的负面影响可能会增加绘制调用的CPU消耗。

• 避免渲染管线气泡（空闲）。

以下几种情况会产生渲染管线气泡：

1、Command Buffer提交不够频繁。不经常提交命令缓冲区会减少GPU处理队列中的工作量，限制潜在的编排机会。

2、数据依赖。假设有渲染通道M和N，M在稍后的阶段。当N在管道中被M更早地使用时，数据依赖就产生了。数据依赖会导致延迟，在此期间必须做足够的工作来隐藏结果生成中的延迟。

渲染管线气泡示意图。图中显示CPU、VS、PS都存在气泡。

以下建议可以减少管线气泡：

1、频繁地提交Command Buffer。例如，为帧中的每个主要渲染通道之后，但渲染通道期间不宜提交。

2、如果某些情况导致了气泡，尝试填充气泡技术。例如，通过在两个渲染通道之间插入独立的工作负载。

3、考虑在比使用依赖数据的阶段更早的管道阶段生成依赖数据。例如，计算（compute）阶段适合为顶点着色阶段生成输入数据。而片元阶段是不合适的，因为它的执行晚于顶点着色阶段管道，否则会造成卡顿和延时。

4、考虑在管道中的更后阶段处理依赖数据。例如，片元着色使用来自其他片元着色的输出比计算着色使用片元着色更好。

5、使用栅栏异步地将GPU的数据读回CPU。千万不用同步地调用从GPU读取数据到CPU的接口，否则整个渲染管线将可能发生严重停滞。

此外，以下建议可以优化渲染管线：

1、不要在管道的任何地方不必要地等待GPU数据。

2、不要等到帧结束才提交所有的渲染通道。

3、在没有足够的中间工作来隐藏延迟的情况下，不要在管道中创建任何逆向（backwards）的数据依赖。

4、不要使用vkQueueWaitIdle()或vkDeviceWaitIdle()。

• 正确使用管线同步。

现代图形API（如Vulkan）拥有非常细粒度的管线阶段：

typedef enum VkPipelineStageFlagBits{    VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT = 0x00000001,        // Vertex Stages    VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT = 0x00000002,    VK_PIPELINE_STAGE_VERTEX_INPUT_BIT = 0x00000004,    VK_PIPELINE_STAGE_VERTEX_SHADER_BIT = 0x00000008,    VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT = 0x00000010,    VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT = 0x00000020,    VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT = 0x00000040,    // Fragment Stages    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT = 0x00000080,    VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT = 0x00000100,    VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT = 0x00000200,    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT = 0x00000400,    // Compute Stages    VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT = 0x00000800,    VK_PIPELINE_STAGE_TRANSFER_BIT = 0x00001000,    VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT = 0x00002000,        VK_PIPELINE_STAGE_HOST_BIT = 0x00004000,    VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT = 0x00008000,    VK_PIPELINE_STAGE_ALL_COMMANDS_BIT = 0x00010000,        (......)} VkPipelineStageFlagBits;

现代图形API（如Vulkan）也包含了众多同步对象：

1、Subpass依赖、Pipeline Barrier、Event等，用于单个Queue内的精细粒度同步。

2、Semaphore（信号）用于跨Queue的较重度的依赖关系。

管线依赖存在两个变量：srcStage和dstStage。srcStage标明必须等待的管线阶段（pipeline stage），dstStage标明在处理开始之前必须等待同步的管线阶段。

为了更好的并行效率和更少的管线气泡，srcStage越早越好，而dstStage越迟越好。如果srcStage是VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT时，将获得最差的性能。

Semaphore可以使用pWaitDstStages指定具体的阶段。

更具体地说，遵循以下准则，可以获得更好的渲染效率：

1、srcStageMask被设置得越早越好。

2、dstStageMask被设置得越晚越好。

3、检查依赖关系是向前的（比如srcStageMask是顶点或计算，dstStageMask是片元）还是向后的（如srcStageMask是片元，dstStageMask是顶点或计算）。 尽量减少使用向后依赖关系。

4、如果确实需要向后依赖，则在生成和消费资源之间添加足够的延迟，以便隐藏向后依赖引起的调度气泡。

5、使用srcStageMask = ALL_GRAPHICS_BIT 和 dstStageMask = FRAGMENT_SHADER_BIT 彼此同步两个渲染通道。

6、零拷贝（Zero-copy）算法是最有效的，因此尽量减少TRANSFER拷贝操作的使用。密切关注TRANSFER副本对硬件流水线的影响。

7、只在需要时使用队列内屏障（intra-queue barrier），并在屏障之间尽可能多地安排工作。

8、不要让硬件处于空闲状态。

9、不要忘记重叠顶点/计算和片元之间的处理。

10、不要使用下面的srcStageMask到dstStageMask同步组合，因为它们会完全耗尽管道：

BOTTOM_OF_PIPE_BIT to TOP_OF_PIPE_BITALL_GRAPHICS_BIT to ALL_GRAPHICS_BITALL_COMMANDS_BIT to ALL_COMMANDS_BIT

11、如果合并管道屏障，请注意不要引入错误的依赖项。确保不打破顶点/片元重叠，并创建一个不必要的气泡。

12、不要使用VkEvent信号并立即等待该事件，用vkCmdPipelineBarrier()。

13、不要在单个Queue中使用VkSemaphore进行依赖管理。

14、不要让渲染管线留有太大的空闲（否则降低性能），也不要让渲染管线留有太小的空闲（否则可能产生错误）。

• 正确处理管线资源。

OpenGL ES为应用开发人员提供了一个同步呈现模型，即使底层的执行可能是异步的，必须反映数据资源在绘制调用时的状态。如果一个应用程序修改了一个资源，而一个挂起的draw调用仍在引用它，那么驱动程序必须采取规避操作来确保正确性。

驱动程序处理这些资源的同步行为时因GPU厂商而异，例如Mali驱动程序避免了阻塞和等待资源引用计数达到零，因为这样做会耗尽管道并导致性能低下。Mali GPU会创建一个全新版本的资源，资源的旧版本或幽灵（Ghost）版本将一直保留，直到挂起的绘制调用完成，其引用计数降至零。其它一些驱动程序（如PowerVR）会卡住本帧的渲染管线，延迟到下一帧处理，引发性能下降。

这种行为开销大，需要为新资源分配内存，并在完成时清理空资源。如果更新不是完全替换，还需要从旧的资源缓冲区复制到新的资源缓冲区。

为了优化资源，需要遵循以下建议：

1、避免修改已入队的draw call引用的资源，可以使用N-buffered资源，并通过管道进行动态资源更新。

2、使用GL_MAP_UNSYNCHRONIZED标记，以允许使用glMapBufferRange()来补齐缓冲区中仍被动态绘制调用引用的未引用区域。不要将GL_MAP_INVALIDATE_BUFFER /GL_MAP_INVALIDATE_RANGE与glMapBufferRange()一起使用，因为这些标志在某些版本的驱动会触发创建一个不必要的资源拷贝。

• 高效地上传纹理资源。

上传纹理资源到到图形硬件时，对于非压缩纹理，按线性的扫描线上传，对于压缩的纹理，将会逐块上传。

部分GPU内部（如PowerVR）使用独特的布局来改善内存访问局部性和提高缓存效率。数据的重新格式化是由专用硬件在芯片上完成的，因此非常快。如果能遵循以下步骤更能提升性能：

1、在非性能关键时期上传纹理，如初始化。有助于避免与纹理加载相关的帧率下降。

2、避免上传帧期间（mid-frame）的纹理数据到已经用于该帧的纹理对象。

3、在纹理上传完成后执行一个预热（warm-up）步骤。依然是有助于避免与纹理加载相关的帧率下降。

前面提到的预热（warm-up）步骤可以确保纹理立即完全上传。默认情况下，glTexImage2D不会立即执行上传所需的所有处理，纹理是在第一次使用时完全上传的。可以通过在屏幕上画出一系列三角形或用有问题的纹理对象进行绑定处理来强制上传。

12.6.1.3 带宽优化

• 注意数据的存放位置。如：RAM、VRAM、Tile Buffer、GPU Cache，减少不必要的数据传输。
• 关注数据的访问类型。如：是只读还是只写操作，是否需要原子操作，是否需要缓存一致性。
• 关注缓存数据的可行性，硬件可以缓存数据以供GPU后续操作快速访问。可以通过以下几点提升缓存命中率：
  • 提高传输速度，确保客户端顶点数据缓冲区被用于尽可能少的绘制调用。理想情况下，应用程序永远不应该使用它们。
  • 减少GPU在执行调度或绘制调用时需要访问的数据量。这样可以让尽量多的数据放到缓存行，提升命中率。
• 使用纹理压缩格式。优先ASTC，其次是ETC、PVRTC、BC等压缩格式。GPU的硬件通常都支持这类压缩格式，可以快速地编解码它们，并且可以一次性读取更多的纹素内容到GPU的缓存行，提升缓存命中率。
• 使用位数更少的像素格式。如RGB565比RGB888少8位，ASTC_6X6代替ASTC_4x4等。Adreno支持的像素格式参见Spec Sheets。
• 使用半精度（如FP16）取代高精度（FP32）数据。如模型顶点和索引数据，并且可以使用SOA（Structure of Array）数据布局，而不用AOS。
• 降分辨率渲染，后期再放大。可以减少带宽、计算量，减少设备热发热量。
• 尽量减少绘制次数。绘制数量的减少可以减少CPU和GPU之间、GPU内部的带宽和消耗。
• 确保数据存储在On-Chip内。

利用PLS、Subpass的特性，可以实现移动端的延迟渲染、粒子软混合等。下表是PowerVR GX6250在实现延迟渲染时，使用不同的位数和性能的关系：

以上可知，当位数大于256，超过GX6250的最大位数，数据无法完全存储在On-Chip内，会外溢到全局内存，导致每帧时间暴增10ms，增幅为34.5%。

因此，对每像素的数据进行精心的组装、优化和压缩，保持数据能够完全容纳于On-Chip内，可有效提升性能，节省带宽。

• 避免多余的副本。

确保使用相同内存的硬件组件（CPU、图形核心、摄像机接口和视频解码器等）都访问相同的数据，而不需要进行任何中间复制。

• 使用正确的标记创建Buffer、纹理等内存。部分Mali GPU（如Bifrost）执行以下几个标记组合：

1、DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT

2、DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_CACHED_BIT

3、DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT | HOST_CACHED_BIT

4、DEVICE_LOCAL_BIT | LAZILY_ALLOCATED_BIT

其中HOST_VISIBLE_BIT | HOST_COHERENT_BIT | HOST_CACHED_BIT的内存类型说明如下：

1、提供CPU上的缓存存储，与内存的GPU视图一致，无需手动同步。

2、如果芯片组支持CPU与GPU之间的硬件一致性协议，则该GPU支持此标记组合。

3、由于硬件的一致性，它避免了手动同步操作的开销。当可用时，缓存的、一致的内存优先于缓存的、不一致的内存类型。

4、必须用于CPU上的应用软件映射和读取的资源。

5、硬件一致性的功耗很小，所以不能用于CPU上只写的资源。对于只写资源，通过使用Not Cached，一致内存类型绕过CPU缓存。

关于LAZILY_ALLOCATED内存类型说明：

1、是一种特殊的内存类型，最初只支持GPU虚拟地址空间，而不是物理内存页面。如果访问内存，则根据需要分配物理页。

2、必须与使用VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT创建的瞬态attachment一起使用。瞬态Image的目的是用作帧缓冲attachment，只存在于一个单一的渲染过程中，可以避免使用物理内存。

3、不能将数据写回全局内存。

以下是Vulkan内存标记的使用建议：

1、对于不可变资源，使用HOST_VISIBLE | HOST_COHERENT内存。

2、对于CPU上只写的资源，使用HOST_VISIBLE | HOST_COHERENT内存。

3、使用memcpy()将更新写入HOST_VISIBLE | HOST_COHERENT内存，或者按顺序写入以获得CPU write-combine单元的最佳效率。

4、使用HOST_VISIBLE | HOST_COHERENT | HOST_CACHED内存用于将资源读回CPU，如果此组合不可以，则使用HOST_VISIBLE | HOST_CACHED。

5、使用LAZILY_ALLOCATED内存用于仅在单个渲染过程中存在的临时帧缓冲区附件。

6、只将LAZILY_ALLOCATED内存用于TRANSIENT_ATTACHMENT帧缓冲区附件。

7、映射和取消映射缓冲区消耗CPU性能。因此要持久地映射经常被访问的缓冲区，例如：统一缓冲区、数据缓冲区或动态顶点数据缓冲区。

• 尽量使用零拷贝（Zero-Copy）路径。

如下图所示，通过使用EglImage实现Camera和OpenCL共享Original Image Data，OpenCL和OpenGL ES共享Final Image Data，从而达到零拷贝：

• 将内存访问分组。

编译器使用几种启发式方法，可以识别内核中的内存访问模式，这些模式可以组合成读或写操作的突发传输。为了让编译器更好实现这种优化，内存访问应该尽可能紧密地组合在一起。

例如，将读放在内核的开头，写放在内核的结尾，可以获得最佳的效率。对更大的数据类型(如向量)的访问也会尽可能地编译为单个传输，加载1个float4比加载4个多带带的float值更好。

• 合理使用Shared/Local内存。

可以在Shader初期（如初始化），将常访问的数据先读取到Shared/Local内存，提升访问速度。

• 以行优先（Row-Major）的顺序访问内存。

GPU通常会预读取行相邻的数据到GPU缓存中，如果着色器算法以行优先的方式访问，可以提升Cache命中率，降低带宽。

• GPU特定带宽优化。

Mali的Transaction%20elimination只有在以下情形适用：

1、采样数据为1。

2、mimap级别为1。

3、image使用了COLOR_ATTACHMENT_BIT。

4、image没有使用TRANSIENT_ATTACHMENT_BIT。

5、使用单一颜色附件。（Mali-G51%20GPU及之后没有此限制）

6、有效的tile尺寸是16x16像素，像素数据存储决定了有效的tile尺寸。

Mali%20GPU还支持AFBC纹理，可以减少显存和带宽。

GL_BYTEGL_UNSIGNED_BYTEGL_SHORTGL_UNSIGNED_SHORTGL_FIXEDGL_FLOATGL_HALF_FLOATGL_INT_2_10_10_10_REVGL_UNSIGNED_INT_2_10_10_10_REV

int4 ResultOfA(int4 a) {    return a + 1; // int4和int相加, 只需要1条指令.}int4 ResultOfA(int4 a) {    return a + 1.0; // int4和float相加, 需要3条指令: int4 -> float4 -> 相加 -> int4}

uniform sampler2D ColorTexture;in vec2 TexC;vec3 light(in vec3 amb, in vec3 diff){    // 纹理采样返回vec4, 会隐性转换成vec3, 多出1条指令.    vec3 Color = texture(ColorTexture, TexC);     Color *= diff + amb;    return Color;}// 以下代码中, 输入参数/临时变量/返回值都是vec4, 没有隐性类型转换, 比上面代码少1条指令.uniform sampler2D ColorTexture;in vec2 TexC;vec4 light(in vec4 amb, in vec4 diff){    vec4 Color = texture(Color, TexC);    Color *= diff + amb;    return Color;}

float scale, bias;  // 两个float值.vec4 a = Pos * scale + bias; // 需要两条指令.vec2 scaleNbias; // 将两个float值打包成一个vec2vec4 a = Pos * scaleNbias.x + scaleNbias.y; // 一条指令(mad)完成.

highp vec4 v1, v2;highp float x, y;// Bad!!v2 = (v1 * x) * y; // vector*scalar接着vector*scalar总共8个标量muladd.// Good!!v2 = v1 * (x * y); // scalar*scalar接着vector*scalar总共5个标量muladd.

precision mediump float;#ifdef GL_FRAGMENT_PRECISION_HIGH    #define NEED_HIGHP highp#else    #define NEED_HIGHP mediump#endif        varying vec2 vSmallTexCoord;varying NEED_HIGHP vec2 vLargeTexCoord;