tugouxp的专栏

1./dev/kfd管理一组设备而并非单个设备，如果有多个HSA节点，则open kfd的上下文将会创建一个process，并为这个server上的所有可用的HSA节点分别创建上下文。2.如果/dev/kfd管理多个设备，那么驱动如何确定当前系统调用下来要访问那个HSA设备呢？方法是用户会在系统调用的参数中传入要操作的gpu_id.3.既然如此，进行系统调用前用户应用必须首先知道有那些GPU_ID,那么应用是如何知道的呢？

主存和现存在PCIE框架下可以做到互相访问，路径归纳如下：三种角色，两种存储，六种路径。1.HBM通过BAR透给了HOST，使HOST可以通过MMU给CPU访问，或者通过IOMMU给设备访问。2.相反，Host Memory并没有类似的BAR机制透给 PCIE设备端，PCIE设备端想要访问 HOST MEMORY必须经过 HOST IOMMU的映射一遍，加上PCIE端的SMMU映射，对于PCIE设备端（GPU）来说，要经过两层IOMMU翻译。所以从HOST端和GPU端看起来不太对称。

或许因为RISCV ISA规范的开放带来了RISCV快速发展证明了硬件开放也是一条可以尝试的方向，今年8月，上海交大先进计算机体系结构实验室团队对外发布了自研开源GPGPU平台“青花瓷”，试图通过开源这条路缩小和AMD,NVIDIA等产业国际巨头的距离。GPGPU中文名叫做通用图形处理器，在面对并行任务处理时，CPU 与 GPU 的体系结构设计理念有着根本的区别。

优化时遵守的一些原则：1.Grid一定要给足block.2.Block内一定要给足thread,目的是提高并发WARP的数目，隐藏延迟.3.Block内线程的数目一定是warpsize的整数倍.每个warp的执行上下文（execution context，如程序计数器 和 寄存器等）在warp的整个生命周期内都被保存在片上内存（on-chip memory）。因此从一个执行上下文切换到另一个执行上下文是无开销的。

ION是一种Linux内核中管理共享内存的机制，最初由Google开发，用于Android系统中的图形渲染和多媒体应用。the principle diagram,exporter process 输出FD，给另外两个进程作映射。

【代码】SIMD < SIMT < SMT: parallelism in NVIDIA GPUs。

PS：下图展示的是一个计算片段分别在标量计算单元和向量计算单元上不同的编程方法：

通常情况下，某个顶点的坐标变换不依赖也不影响其它顶点的坐标变换，某个像素的颜色计算不依赖也不影响其它像素的颜色计算。每个周期执行指令，获取一个输入，得到一个输出，CPU 处理计算任务的处理流程通常是单指令单数据流的流程。堆砌大量的计算单元，基于SIMD 设计。3. 硬件设计偏向高并发的设计。比如矩阵变化、光照计算等等。1. 主要处理简单的任务。2. 任务之间相互依赖少。

AMD好像全部都开源了，听在AMD工作过的朋友讲，AMD为了开源，几乎将整个KMD代码全部重写，从这个角度看，AMD的开源热情甩NVIDIA几条街。

熊大的RTT-SMART是除了Linux内核之外，唯一一个覆盖从小型嵌入式平台到到中高端终端SOC品类的操作系统，其中对GPU，图形系统和OPENGL的支持可谓是比较典型，简单搜集了一些这方面的实现资料，纪录如下。RTT-SMART支持原生的ARM-MALI GPU DDK，MALI-GPU是业内首屈一指的图形IP，看看它的对手有多强就知道了，比如高通的Adreno GPU， IMG的PoverVR, 苹果GPU等，都是业内的顶级产品。

从系统架构来看，针对GPU的架构转型还在进行过程中，目前GPU依然还处于外设的地位，还没有摆脱其从属身份，因为这个根本特性，对GPU的编程并不像对CPU编程那样直接，而调试和优化GPU程序的难度就很大了，要比CPU程序复杂很多。