移动端GPU 的内存结构:
先简述移动端内存cache结构;上图的UMA结构 on-Chip memory 包括了 L1、L2 cache,非常关键的移动端的 Tiles 也是保存在 on-chip上还包括寄存器文件:提供给每个核心使用的极高速存储。
- 共享内存(Shared Memory):用于同一计算单元内的线程组SM共享数据,访问速度比全局内存快。
- 常量缓存(Constant Cache):专门用于缓存常量数据。
- 纹理内存(Texture Memory):类似于常量缓存,也是具有缓存的全局内存,容量较大且一般仅可读。它们通过特定的方式进行访问,适用于纹理采样等操作。
移动端GPU流程
下图以arm 的mail为例(以后有机后再展开说):
load 与 store:
- load与 store决定了每个Render Pass开始时如何处理Tile内存中的数据。
- 从 SystemMemory 拷贝数据到 TileMemory 是 Load Action。
- 从 TileMemory 拷贝数据到 SystemMemory 是 Store Action。
在移动端图形中GPU Load Actions(加载操作)决定了在渲染一个新的帧缓冲区FBO,如何处理FBO中已经存在的数据,这在优化性能和内存带宽方面非常重要。主要有三种GPU Load Actions:don‘t care、Load、Clear。
在移动端图形中GPU Store Actions(存储操作)决定了在渲染完成一帧后如何处理FBO中已经存在的数据:主要有三种dont’care 、resolve、store
Apple 的Store Action 有三种, Store, DontCare,MultisampleResolve ,还有两种处理 MSAA 等的 Metal、vulkan 的storeAndMultisampleResolve, MultisampleResolve. 感兴趣可以直接参苹果的文档 Metal Best Practices Guide: Load and Store Actions
想要优化pipline的性能,就一定要注意设置好每个RenderTarget的Load Action 和 Store Actions。比如,Depth和Stencil通常只有在Rasterize阶段才会使用,所以直接放到了On-chip上, 或者后处理执行后深度没有用Store Actions设置为Don‘t care这样就不用把结果写入system内存,省下了大量的带宽。
fast clear
Fast Clear 是 GPU 对帧缓冲区进行快速clear的一种硬件优化机制。当帧缓冲区被clear时,只需将每个像素初始化到一个特定的颜色值。如果直接操作整个帧缓冲区对整个缓冲区的逐步遍历,会非常耗时
Fast Clear 本质上是一些硬件预设的清除值,比如clear成黑色或者白色这种,比自己传一个clear value进去要快!现代的硬件都有 Fast Clear,不管是 PC 、Apple A系列、ARM使用的Transaction Elimination 的技术,Adreno等都支持。
调用 clear 的时候根据硬件支持与驱动的设置会触发Fast Clear。比如在 amd 上Fast clear 在设计上比不同clear快约100倍
- Fast clear 需要全图像clear。
- Fast clear RT的 需要以下颜色RGBA(0,0,0,0),RGBA(0,0,0,1),RGBA(1,1,1,0) ,RGBA(1,1,1,1)
- Depth RT Fast clear 需要将深度值设为1.f或者0.f。
- 模板设置值为 0x00。
- Depth target arrays 需要将全部slices都清除才能实现fast clear。
- vulkan 与 D12有Discard或LOAD_OP_DONT_CARE 标记时(opengles 无),会跳过Clear。
opengles 的dont’t care 实现
在 opengl 中don’t care 对应的是glinvalidate,clear对应glclear,综上所述在 opengl 中glinvalidate与glclear不等价。所以glinvalidate应该会比clear会更好。glInvalidateFramebuffer 在 ogles2.0 是需要扩展,在 es3.0 是支持的详细参考 gl 文档: glInvalidateFramebuffer - OpenGL ES 3 Reference Pages
pipline开始时将显卡内存初始化使用glclear然后fast clear设置为特定颜色值,而无需system从内存中读回旧的帧缓冲区内容。在进行任何绘制调用之前,除非需要前一帧中渲染的内容上做处理,都可以使用以下的
glClear()
glClearBuffer()
glInvalidateFramebuffer()
你需要使用 glclear 、glClearBuffer、glInvalidateFramebuffer给 GPU 驱动标记opengl驱动会自己优化load过程。但是需要特别注意:每一帧中只有开始是免费(几乎无消耗)的。在pipline中的第一次绘制调用再后调用 glClear() 或 glClearBuffer*() 不是免费的,会增多指令并且这会导致每个着色器的片段都会被清除。同时这些是清除整个 framebuffer,而不仅仅是它的一个子区域!
对于store过程,最重要的是可以通过调用glInvalidateFramebuffer()作为pipline中的最后一个绘制调用,将内容标记为无效!
arm Mali参考
Minimizing-Start-of-Tile-Loads
Minimizing End of Tile Stores
gl 的例子 glInvalidateFramebuffer(GL_FRAMEBUFFER, 1, &attachment);
Load/Store Unit的性能指标含义:
首先,特别注意:
1、issues在 GPU 中是专业术语不能直接翻译成“问题”应该翻译成“发射”或者”调度“用于描述GPU在某个时钟周期内,某种操作(例如读、写、计算)被硬件单元执行或发射的次数。
2、beats 指的是内存控制器中的一个传输单元。它代表一次数据传输中的“拍子”或“节奏”,可以理解为传输过程中一个周期内的数据量。因此,这里的 beats 应该翻译为“传输单位”。
其次,如下表的指标主要是android GPU inspector的指标也是最全的,同样的 Arm 、adreno 等的指标都是下表的特定指标;
load/store参数的分析:
Demo假设你在分析一个 GPU 程序,并且性能分析工具streamline提供了如下参数值:
Load/Store Read Beats from L2 Cache: 5000
Load/Store Read Beats from External Memory: 20000
Internal Load/Store Writeback/Other Write Beats: 15000
从这些数据你可以推断出:
- 程序高度依赖外部内存:因为从外部内存的读取节拍(20000)显著高于从 L2 缓存的读取节拍(5000),表明许多数据访问没有命中 L2 缓存。
- 写操作较频繁:内部加载/存储写回和其他写操作节拍总数(15000)表明有大量的数据写入,可能是计算结果或状态更新(这个时候使用dontcare会有较好的优化效果)。
假设你有以下参数值:
- Load Read Bytes from L2 Cache:320000 / 每访问周期 64 字节
- Load Read Bytes from External Memory:640000 / 每访问周期 128 字节
从这组数据中可以看到: - 从 L2 缓存读取总共 320,000 字节,平均每个访问周期读取 64 字节。
- 从外部内存读取总共 640,000 字节,平均每个访问周期读取 128 字节。
尽管外部内存每个周期读取的字节数较大,但外部内存访问的延迟比 L2 缓存高,整体访问效率可能较低。因此,如果程序频繁地访问外部内存,而不是 L2 缓存,可能会导致性能下降。在这种情况下,优化策略可能包括:
- 提高 L2 缓存命中率,通过更有效的数据布局(内存对齐)和访问模式减少对外部内存的依赖。
- 使用共享内存(内存数组等)或寄存器来缓存频繁访问的数据,从而减少全局内存访问。
参考资料:
1、 移动端高性能图形开发 - 移动端GPU架构探究
2、 移动GPU体系结构
3、 OpenGL ES 3.0 帧缓冲区失效-
4、 移动平台的GPU性能分析