1

这些是我的假设：

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

假设计算能力 7.5，这些是我的问题：

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

1 回答 1

4

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 问题

  1. 第三个假设似乎暗示 L2->TEX Returns 对于全局缓存加载应该总是四的倍数，但情况并非总是如此。这里发生了什么？

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

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

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

  1. 根据我的第四个假设，我认为每当 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）
于 2020-08-20T07:02:01.133 回答