163网站建设,百度一下你就知道官网下载安装,在别的公司做的网站可以转走吗,linu安装wordpress移动端GPU 的内存结构#xff1a; 先简述移动端内存cache结构#xff1b;上图的UMA结构 on-Chip memory 包括了 L1、L2 cache#xff0c;非常关键的移动端的 Tiles 也是保存在 on-chip上还包括寄存器文件#xff1a;提供给每个核心使用的极高速存储。
共享内存#xff08…移动端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 Actionsdon‘t care、Load、Clear。 在移动端图形中GPU Store Actions存储操作决定了在渲染完成一帧后如何处理FBO中已经存在的数据主要有三种dont’care 、resolve、store Apple 的Store Action 有三种 Store DontCareMultisampleResolve 还有两种处理 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 对应的是glinvalidateclear对应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 Cache320000 / 每访问周期 64 字节Load Read Bytes from External Memory640000 / 每访问周期 128 字节 从这组数据中可以看到从 L2 缓存读取总共 320,000 字节平均每个访问周期读取 64 字节。从外部内存读取总共 640,000 字节平均每个访问周期读取 128 字节。 尽管外部内存每个周期读取的字节数较大但外部内存访问的延迟比 L2 缓存高整体访问效率可能较低。因此如果程序频繁地访问外部内存而不是 L2 缓存可能会导致性能下降。在这种情况下优化策略可能包括
提高 L2 缓存命中率通过更有效的数据布局内存对齐和访问模式减少对外部内存的依赖。使用共享内存(内存数组等)或寄存器来缓存频繁访问的数据从而减少全局内存访问。
参考资料
1、 移动端高性能图形开发 - 移动端GPU架构探究 2、 移动GPU体系结构 3、 OpenGL ES 3.0 帧缓冲区失效- 4、 移动平台的GPU性能分析
