Compute Capability 7.5 中的缓存行为

Posted 2023-03-23

【中文标题】Compute Capability 7.5 中的缓存行为

【英文标题】：Cache behaviour in Compute Capability 7.5

【发布时间】：2020-12-09 08:49:09

【问题描述】：

这些是我的假设：

有两种类型的加载，缓存和非缓存。在第一个中，流量通过 L1 和 L2，而在第二个中，流量仅通过 L2。 Compute Capability 6.x 和 7.x 中的默认行为是缓存访问。 L1 缓存线为 128 字节，L2 缓存线为 32 字节，因此对于生成的每个 L1 事务，应该有四个 L2 事务（每个扇区一个。） 在 Nsight 中，SM->TEX 请求意味着从 32 个线程合并的 warp 级指令。 L2->TEX Returns 和 TEX->SM Returns 是衡量每个内存单元之间传输多少扇区的指标。

假设 Compute Capability 7.5，这些是我的问题：

第三个假设似乎暗示 L2->TEX Returns 应该始终是全局缓存加载的 4 的倍数，但情况并非总是如此。这里发生了什么？ 用 const 和 __restrict__ 限定符标记指针还有意义吗？这曾经是向编译器提示数据是只读的，因此可以缓存在 L1/纹理缓存中，但现在所有数据都缓存在那里，只读和非只读。 根据我的第四个假设，我认为每当 TEX->SM Returns 大于 L2->TEX Returns 时，差异来自缓存命中。那是因为当缓存命中时，你会从 L1 读取一些扇区，但从 L2 读取一个扇区。这是真的吗？

【参考方案1】：

CC 6.x/7.x

L1 高速缓存行大小为 128 字节，分为 4 个 32 字节扇区。在未命中的情况下，将从 L2 获取仅寻址的扇区。 L2 高速缓存行大小为 128 字节，分为 4 个 32 字节扇区。 CC 7.0 (HBM) 64B 升级已启用。如果高速缓存行的低 64 字节未命中，则将从 DRAM 中获取低 64 字节。如果高速缓存行的高 64 字节未命中，则将获取高 64 字节。 CC 6.x/7.5 仅访问的 32B 扇区将从 DRAM 中获取。 在 L1 缓存策略方面 CC 6.0 默认启用负载缓存 CC 6.x 默认禁用加载缓存 - 请参阅编程指南 CC 7.x 默认启用负载缓存 - 有关缓存控制的详细信息，请参阅 PTX

在 Nsight Compute 中，术语 requests 在 6.x 和 7.x 之间变化。

对于 5.x-6.x，每条指令的请求数因操作类型和数据宽度而异。例如，32 位负载为 8 个线程/请求，64 位负载为 4 个线程/请求，128 位负载为 2 个线程/请求。 对于 7.x，请求应等同于指令，除非访问模式具有导致序列化的地址分歧。

回答您的 CC 7.5 问题

第三个假设似乎暗示 L2->TEX Returns 应该始终是全局缓存加载的 4 的倍数，但事实并非如此 总是这样。这里发生了什么？

L1TEX 单元只会获取缓存行中丢失的 32B 扇区。

用 const 和 restrict 限定符标记指针还有意义吗？这曾经是对编译器的提示，即数据是只读的，因此可以缓存在 L1/纹理缓存中， 但现在所有数据都缓存在那里，无论是只读的还是非只读的。

如果已知数据是只读的，编译器可以执行额外的优化。

见PTX Cache Operators 见PTX Memory Consistency Model

根据我的第四个假设，我认为每当 TEX->SM Returns 大于 L2->TEX Returns 时，差异来自 缓存命中。那是因为当缓存命中时，你会得到一些 扇区从 L1 读取，但没有从 L2 读取。这是真的吗？

L1TEX 到 SM 返回 B/W 为 128B/cycle。 L2 到 SM 返回 B/W 在 32B 扇区中。

Nsight 计算内存工作负载分析 | L1/TEX Cache 表格展示

L2 扇区未命中（32B 扇区） 返回 SM（周期 == 1-128B）

【讨论】：

请问您在哪里找到您提到的第一个信息？我在编程指南中找到的最后一个参考是 Compute Capability 3.x，它说数据在缓存之间的 128 字节内存事务中移动。

不过，我还是有点困惑。我一直假设传输的单位是一般缓存的缓存行。据我了解，缓存命中意味着您尝试读取的行已被缓存。但是，如果 L1 和 L2 之间的传输发生在扇区中，则可以想象一条线路中可能缺少扇区。因此，L1 中的缓存命中仍然需要从 L2 获取数据（行中缺少扇区），或者缓存命中是根据扇区而不是缓存行定义的。是哪个？

关于最后一部分，在我的报告中，TEX->SM Returns 大于 Elapsed Cycles 的数量。那有意义吗？我希望它等于或更低，因为如果我理解正确，它会测量传输 1-128 字节数据块的周期数。

GPU 有一个专门的缓存。将高速缓存组织为每个高速缓存行 4 个 32B 扇区可降低标记查找的成本。在大多数情况下，不强制提升（获取所有 128B）效率更高。在 CC 3.x 中，您可以进行缓存或非缓存访问（分析器清楚地显示了这一点）。缓存加载将提升到 128B。未缓存的加载只会读取指令访问的扇区。

TEX 到 SM 返回的最大吞吐量是 1 每个 sm__cycle_active。如果它大于可能导致问题的重播之间的某种类型的不一致。我建议您在 devtalk Nsight Compute 论坛上发布报告。