起源于前段时间做的一个GPU实验，关于两个CUDA进程的进程间通信（用CUDA-IPC机制，一个进程在显存中写，另一个进程一边自旋锁一边读数据是否被更改）。实验过程中发现(环境为Ubuntu16/18），在Pascal架构的电脑上做的时候，实验是成功的。然而转到Maxwell架构的电脑上做，发现CUDA程序自旋锁会导致桌面卡住，即使放弃桌面转到tty控制台中做依然失败，因为B进程自旋锁的时候会导致A进程卡主*，根本写不进去。
一开始认为原因是在Pascal架构之前，没有MPS技术，多个cuda进程无法同时在GPU中执行。但事实上软件支持的MPS对硬件计算能力要求不高(>=3.5)，cuda>=5.5就可以。且MPS一般默认关闭，在Pascal架构上实验时也并没有开启MPS。
后来发现原因是Pascal架构开始支持计算抢占。
相关技术及对应的架构：
-
Compute Preemption 计算抢占 :
available since cc6(pascal)
具体抢占策略未公开 -
假依赖-------->HyperQ-------->软件实现MPS------->硬件实现MPS
Fermi(cc2)---Kapler(cc3)----cc>=3.5∩cuda>=5.5----Volta(cc7)
CUDA Context
-
GPU的Context可类比于CPU的进程；
-
一个主机线程只能有一个CUDA Context； 目前应该是一个进程对应一个context
https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#context -
上下文主要由以下资源组成：
·程序计数器；·寄存器；·共享内存
——CUDA C权威编程指南 -
Contex中囊括了Stream
——高性能CUDA应用设计与开发第七章 -
**多个Context不能并行执行 **（除非使用 GPU multi-process server)
尽管可以在给定的GPU上同时分配多个上下文（及其关联的资源，例如全局内存分配），但是这些上下文中只有一个可以在该GPU上的任何给定时刻执行工作； 共享同一GPU的上下文是按时间划分的. 创建其他上下文会增加每个上下文数据的内存开销和上下文切换的时间开销. 此外，当来自多个上下文的工作可以同时执行时，上下文切换的需求会降低利用率。因此，最好避免在同一CUDA应用程序中每个GPU避免多个上下文.（https://s0docs0nvidia0com.icopy.site/cuda/cuda-c-best-practices-guide/index.html#multiple-contexts） -
The execution context (program counters, registers, etc.) for each warp processed by a multiprocessor is maintained on-chip during the entire lifetime of the warp. Therefore, switching from one execution context to another has no cost.
https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#hardware-multithreading（context切换无cost，really？） -
自CUDA 3.2开始(包含), 一个进程里的多个线程将共享同一个context, 而不是分别建立自己的context(3.1以及以下），
https://developer.nvidia-china.com/forum.php?mod=viewthread&tid=7166
MPS
推荐阅读MPS官方文档以及MPS相关博客。
个人理解：相当于用一个context整合了多个context。
待深入了解：MPS的硬件隔离?
自问自答：
Q：多个主机进程默认创建的Context是同一个吗？
A：是不同的Context。
Q：Pascal架构之前，桌面渲染和通用计算也是可以同时进行的呀？
A：事实上并没有真正同时进行，只是交替进行，宏观看上去会有并发的效果。如果cuda程序占用GPU时间过长，会被桌面图形程序停掉。
Q：图像渲染都需要用GPU吗？
A：不一定，某些软件计算量大且专门针对GPU做了优化的话才会用到GPU。
Q：GPU 通用计算会影响渲染任务吗?
A：如果两个计算量都比较大的话肯定会相互影响
网友评论