最近给BitBLAS添加了AMD的后端，发现AMD的异步拷贝等和Nvidia有很大的不同(但是FA3在MI300上需要用到这一个Feature)，然而官方根本没有文档，只有Instruction Set，我在这里做一下自己的理解和解读，大部分内容是参考自这个Instruction Set。
Optimize Gemm on GPU
Windows Server AMD 玄学驱动安装
一台Windows Server 2022，上面装了两块AMD Radeon™ VII的显卡，操作系统的和显卡的版本都很新，导致出现了一些错误，不过最后还是成功安装上了。
使用Tensor Core
最近在使用NNFusion的时候发现Codegen出来的FP16的网络在V100上的性能打不过FP32（甚至要慢一倍以上），但是理论上FP16应该要比FP32有两倍的性能收益才对（V100 Cuda Core的half precision的最大吞吐量是single的两倍，在s9234的slides中看到直接使用half的情况下peak performance其实和single差不多，都是15Tops，但是Cuda Core提供了half2类型，可一次做两个half类型的运算，这是half在CUDA Core上的收益来源；V100卡上的Tensor Core只支持FP16，利用好Tensor Core可以获得非常强的加速，A100卡上的Tensor Core增加更多的精度支持）。
建议阅读的文章：
拿nvprof测试了一下发现主要的性能瓶颈是：half卷积算子的实现速度要比single慢一倍，而这部分运算又占了总体运行时间的绝大部分。
踩坑nvidia driver
刚开始碰到的问题是这样的：在Azure上开的一台HPC（4块 V100 16G）在运行了大概七八个小时之后，nvidia的显卡会挂掉，具体的表现为nvidia-smi会卡住十几分钟，之后输出No devices were found，但是执行lspci | grep -i nvidia还是可以看到四块显卡好好的挂在上面，这种情况应该直接reboot就可以修复，但是reboot了之后同样的程序运行一段时间之后显卡还是会掉。
关于常用的Simulator
主要分为三个部分：
Architecture：加速器的体系根据其结构可分为三组，固定数据流的加速器(例如TPU、NVDLA、Eyeriss)、灵活数据流的加速器(例如Eyeriss v2、Maeri、Sigma)和chiplet多核加速器(例如SIMBA)。与包括CPU和GPU在内的传统体系结构不同，空间体系结构使用ScratchPad作为片上buffer。和传统的CPU体系结构里的Cache不一样，ScratchPad是可编程的，数据从DDR往ScracthPad上load的过程是由用户生成指令来操作，因为要取的数据地址相对来讲固定，所以理论上存在一个最有的数据流动序列，详见HPCA19上的《 Communication Lower Bound in Convolution Accelerators 》，而Cache是根据局部性原理由硬件完成这个操作，用户不可控。
Cost Models：也是因为Cache的原因，对加速器运行效率的建模不一定需要使用cycle级别的模拟器就可以。现在开源的就存在着不同的cost模型，用于以不同程度的保真度，为不同类型的加速器建模。例如，SCALE-sim来仿真脉动阵列(TPU)， MAESTRO仿真的阵列具有可配置的宽高比，Timeloop在模拟的时候可以考虑到复杂的内存层次结构建模，Tetris可以建模3D阵列。
Mappers：使用Cost Models，可以用目标硬件上的特定的map来估计程序的性能。然而，要为给定的工作负载和体系结构找到最佳映射并不简单，原因有两个。首先，映射的空间可能非常大，这使得穷举搜索变得不可行。这导致了几种映射器的开发，它们通过修剪搜索空间或用有效的方法搜索来减少搜索时间。Marvel提出了一种分离芯片外map空间和片上map空间的方法，timeloop利用了基于采样的搜索方法，Interstella使用了基于启发式的搜索方法，Mind Mapping开发了一个子模型来基于梯度搜索，而Gamma使用了基于遗传算法的方法通过利用先前的结果来有效地推进。其次，定义Map的搜索空间本身通常很复杂，因为不同的操作和不同的硬件加速器可能会对可行的映射施加约束。这就是为什么现在的Mapper在今天高度依赖于特定的成本模型，从而限制了可扩展性。