I was wondering if anyone here has any experience with conventional modern GPU microarchitectures (modern: 5-10 years, kinda broad I know) and whether the computational hardware implements, also in hardware, privilege rings and memory protection like a conventional CPU compute device?
Where I'm going with this is with all the LLM/GPGPU stuff going on these days, I started reading on what security mechanisms are in place to prevent unauthorized memory access, privilege escalations, etc. inside the physical GPU hardware and am not turning up a whole lot of consistent guidance. An article from Microsoft on their graphics driver framework suggests GPUs have an MMU that provide comparable memory protection/virtualization services to the compute units, but then some other articles suggesting some GPUs require that this protection be done wholly in the driver/software and that there is nothing that would, say, prevent properly injected GPU kernel code from reading the memory belonging to another kernel it is not part of an execution list with.
I'm also coming at this from having an infinitely better understanding of tile-based graphics. I can write OpenGL, have a vague idea of how that translates into kernels and execution groups and all that, basically I understand to about the level of the abstract machine Vulcan exposes, but not any further (e.g. what bytecode does a nVidia compute core read, which ICs do which jobs after OGL/DX/VK has translated the user code into actual GPU-driving commands for that specific implementation.)
Thanks for any insights, low-level GPU is something I eventually want to study but just not there yet. I've got a RISC-V board with both a GPU and vector extensions support on the CPU, that's where I'll eventually start studying, albeit the GPU is not one of the big conventional ones so may be of limited comparability (Imagination Technology, supports OGL ES and Vulkan.) CPU SOC also has some NVDLA stuff which may also veer into this territory, so part of this is planting some seeds on discovering what the general protection situation is regarding massively parallel compute vs conventional central compute.
Where I'm going with this is with all the LLM/GPGPU stuff going on these days, I started reading on what security mechanisms are in place to prevent unauthorized memory access, privilege escalations, etc. inside the physical GPU hardware and am not turning up a whole lot of consistent guidance. An article from Microsoft on their graphics driver framework suggests GPUs have an MMU that provide comparable memory protection/virtualization services to the compute units, but then some other articles suggesting some GPUs require that this protection be done wholly in the driver/software and that there is nothing that would, say, prevent properly injected GPU kernel code from reading the memory belonging to another kernel it is not part of an execution list with.
I'm also coming at this from having an infinitely better understanding of tile-based graphics. I can write OpenGL, have a vague idea of how that translates into kernels and execution groups and all that, basically I understand to about the level of the abstract machine Vulcan exposes, but not any further (e.g. what bytecode does a nVidia compute core read, which ICs do which jobs after OGL/DX/VK has translated the user code into actual GPU-driving commands for that specific implementation.)
Thanks for any insights, low-level GPU is something I eventually want to study but just not there yet. I've got a RISC-V board with both a GPU and vector extensions support on the CPU, that's where I'll eventually start studying, albeit the GPU is not one of the big conventional ones so may be of limited comparability (Imagination Technology, supports OGL ES and Vulkan.) CPU SOC also has some NVDLA stuff which may also veer into this territory, so part of this is planting some seeds on discovering what the general protection situation is regarding massively parallel compute vs conventional central compute.
Statistics: Posted by segaloco — Fri Jan 19, 2024 11:34 am — Replies 0 — Views 46