Announcement

Collapse
No announcement yet.

AMD Implementing Process Isolation Support For Their GPU/Accelerator Driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD Implementing Process Isolation Support For Their GPU/Accelerator Driver

    Phoronix: AMD Implementing Process Isolation Support For Their GPU/Accelerator Driver

    A set of patches posted today on the AMD graphics driver mailing list begin implementing support for process isolation within the AMDGPU kernel graphics driver...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    What valuable information could be extracted from an enterprise GPU? Unreleased ML weights? I don’t think confidential information would ever be put onto a shared system, or on a system that can run untrusted software.

    Comment


    • #3
      Originally posted by EphemeralEft View Post
      What valuable information could be extracted from an enterprise GPU? Unreleased ML weights? I don’t think confidential information would ever be put onto a shared system, or on a system that can run untrusted software.
      That could be a subsidiary use case.

      But just think about how horrible GPUs are in general compared to "ordinary" CPUs and memory.

      A normal low end consumer CPU has a full MMU and can strongly isolate memory and I/O access as well as have discretionary enforced privilege / permission levels for all such resources vs. processes accessing them. That's how you can have a multi-user OS with user to user process isolation. Or multi processing where you have each process isolated from each other process even if they're running as the same user's processes (e.g. email program vs. web browser) or sandbox browser tab#1 from browser tab #2, etc. etc.

      It has been decades with MMU and eventually IOMMU since we've accepted that simply everything wrt. CPU/RAM/IO should be able to be
      (a) isolated between processes / threads / users / kernel / userland etc. etc.
      and
      (b) should strongly support multi-user / multi-tasking scenarios by being able to nicely time-share or segment / multiplex
      resources between different user contexts / users transparently so that each user / process could even act as if it owned some whole or subset of resources on the machine while that process / context is active
      and
      (c) Support containerization, virtualization such that we can even subdivide resources or time share them and it shouldn't even matter if we virtually overcommit the resource use and share it among more users than there are physical resources e.g. virtual NICs / virtual networks, virtual memory, storage namespaces, virtual drives, etc. etc.

      Then consider how abysmally GPUs (thanks to the architectural & driver "to heck with you" we've gotten from the GPU vendors) have been the single sore point where basically NONE OF THE ABOVE is holistically true for working with GPUs.
      Have a bunch of VMs / containers and want to share GPU compute between them in a granular and nicely allocated / subscribed / virtualized way? Good luck with that.
      Have VMs / containers and want accelerated graphics / video / console service for each? Middle finger to you.

      Have a multi-head / multi-user system you want to have different video output ports of a single N-port GPU host isolated independent desktop environments? Middle finger to you.

      The list goes on.

      Literally nothing else that has such pervasive importance to modern linux / windows / ... computing as a GPU (which is also the sole ML/NPU/HPC capability realistically) has been allowed to fail so miserably at playing nicely with isolation / virtualization / system administration.

      And the VERY SAME companies that make the CPUs, MMUs, IOMMUS, drivers, virtualization / containerization support HW/FW/SW for modern computers (AMD, Intel, to an extent nvidia too) are the VERY ONES that make GPUs that utterly break every single one of the "minimum expected architectural functionality" use cases we take for granted being in the VERY LOWEST END smart phones, tablets, notebooks, minimal entry level desktops, etc.

      Comment


      • #4
        Originally posted by pong View Post
        (b) should strongly support multi-user / multi-tasking scenarios by being able to nicely time-share or segment / multiplex
        resources between different user contexts / users transparently so that each user / process could even act as if it owned some whole or subset of resources on the machine while that process / context is active
        and
        (c) Support containerization, virtualization such that we can even subdivide resources or time share them and it shouldn't even matter if we virtually overcommit the resource use and share it among more users than there are physical resources e.g. virtual NICs / virtual networks, virtual memory, storage namespaces, virtual drives, etc. etc.
        I just want CGroup support for GPUs. Give me the cpu.* and mem.* interface but for limiting GPU utilisation and VRAM usage.

        Intel experimented with developing a CGroup for GPUs in the past but it never went anywhere.

        Comment


        • #5
          This reminds me of when I used to dual boot linux and windows. I was running windows and rebooted into linux and when I took a screenshot in linux it included all monitors and the space outside the monitors that you would expect to be black, but in that space I could see the windows desktop image because operating systems dont clear gpu resources on shutdown/when they are given to other processes.

          Comment


          • #6
            Yeah and that reminds of the time when if you booted Windows and then rebooted to Linux for just a moment right before Linux modesettled it would flash a frame of windows shutting down...

            Comment

            Working...
            X