计算能力7.5中的缓存行为

如何解决计算能力7.5中的缓存行为

这些是我的假设：

1. 有两种类型的加载，已缓存和未缓存。在第一个中，流量通过L1和L2，而在第二个中，流量仅通过L2。
2. 计算能力6.x和7.x中的默认行为是缓存访问。
3. L1高速缓存行为128字节，L2高速缓存行为32字节，因此对于每个生成的L1事务，应该有四个L2事务（每个扇区一个）。
4. 在Nsight中，SM-> TEX请求表示从32个线程合并的翘曲级指令。 L2-> TEX返回和TEX-> SM返回是对每个存储单元之间传输多少扇区的度量。

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

1. 第三个假设似乎暗示对于全局缓存的负载，L2-> TEX返回值应始终为四的倍数，但并非总是如此。这是怎么回事？
2. 用const和__restrict__限定符标记指针是否还有一点意义？过去曾经向编译器暗示过，数据是只读的，因此可以缓存在L1 /纹理缓存中，但是现在所有数据都缓存在了那里，包括只读和非只读。
3. 从我的第四个假设出发，我认为只要TEX-> SM Returns大于L2-> TEX Returns，差异就来自缓存命中。这是因为，当发生高速缓存命中时，您会从L1中读取一些扇区，而从L2中却没有读取。这是真的吗？

解决方法

CC 6.x / 7.x

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

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

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

回答CC 7.5问题

1. 第三个假设似乎暗示对于全局缓存的负载，L2-> TEX返回值应始终为四的倍数，但并非如此 总是这样。这是怎么回事？

L1TEX单元只会在高速缓存行中提取丢失的32B扇区。

1. 用const和 restrict 限定词标记指针是否还有一点意义？以前是向编译器提示数据是只读的，因此可以将其缓存在L1 /纹理缓存中， 但是现在所有数据都缓存在了那里，只读和非只读。

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

• 请参见PTX Cache Operators
• 请参见PTX Memory Consistency Model

1. 从我的第四个假设来看，我认为只要TEX-> SM回报大于L2-> TEX回报，差异就来自 缓存命中。那是因为当缓存命中时，您会得到一些 扇区从L1读取，但从L2读取。这是真的吗？

从L1TEX到SM的返回黑白是128B /周期。 从L2到SM的返回黑白在32B扇区中。

Nsight计算内存工作量分析| L1 / TEX缓存表显示

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