Linux环境下无需编写dummy driver实现进程GPU指定及中途切换的方案问询

你确实把问题复杂化了，dummy驱动方案技术上可行，但绝非最简路径，而且开发成本极高，完全存在无需编写驱动的替代方案。

一、你的dummy驱动思路可行性 #

• 技术层面是可行的：本质是实现一个符合GPU设备接口（如PCIe、Vulkan/OpenGL规范）的虚拟驱动，拦截进程的图形调用后转发至真实GPU。
• 但缺点致命：需要深入掌握Linux内核驱动模型、GPU硬件规范及图形API协议，开发周期长，还要处理进程上下文同步、资源迁移等复杂问题，调试难度极大，完全不符合你“不愿编写驱动”的诉求。

二、无需驱动的最简实现方案 #

1. 进程启动时指定GPU #

针对不同GPU厂商和图形栈，有现成的用户态工具/环境变量可以直接实现：

• NVIDIA GPU：用CUDA_VISIBLE_DEVICES环境变量限定可见GPU，例如：

  CUDA_VISIBLE_DEVICES=1 ./your_target_process
  

  若为OpenGL/Vulkan程序，可配合__GLX_VENDOR_LIBRARY_NAME=nvidia或VK_ICD_FILENAMES指定驱动路径。
• AMD/Intel GPU：依托Mesa驱动框架的DRI_PRIME环境变量，例如：

  DRI_PRIME=1 ./your_target_process
  

  其中1代表离散GPU，0代表集成GPU，支持OpenGL/Vulkan程序。
• 通用API拦截：通过LD_PRELOAD加载自定义共享库，拦截glXCreateContext、vkCreateInstance等图形API初始化调用，在进程启动时强制绑定目标GPU的设备ID。这种方式仅需编写用户态代码，实现成本远低于内核驱动。

2. 进程运行中途切换GPU #

虽然存在稳定性风险，但也有用户态的实现方式：

• 图形上下文重建：针对Vulkan/OpenGL程序，通过ptrace工具向目标进程注入共享库，强制销毁当前GPU上下文，重新创建目标GPU的上下文，并迁移原有图形资源。部分程序可能因资源兼容性问题崩溃，但满足实验需求。
• 容器化动态配置：将进程置于容器中运行，通过修改容器的GPU设备映射（如nvidia-container-toolkit的动态配置），再向进程发送信号触发上下文重建。切换逻辑可在容器外部实现，无需修改进程本身。

总结 #

优先选择用户态的环境变量、LD_PRELOAD拦截或容器化方案，这些是当前需求下的最简实现路径，完全不需要开发内核驱动。

内容的提问来源于stack exchange，提问作者Lynet _101