5 ms·

I don't necessarily think so for 2 reasons: The fact that the lowest level of interaction you can have with a computer is writing memory. When writing device d

I don't necessarily think so for 2 reasons: The fact that the lowest level of interaction you can have with a computer is writing memory. When writing device drivers, or interfacing with microcontroller hardware, the way you give commands and transfer data is by writing your command to a memory-mapped device register, or an area of memory that will be copied to the target device. This, coupled with the ability to map a file to memory, allows this paradigm to compete with the most efficient bare-metal implementations. One particular example is the /dev/draw interface mentioned in the article, where anyone could literally write graphics program just by fiddling with bits in memory, just like in DOS or the C64. The other thing is, modern computers are networks in a box. For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? I don't see anything particularly inefficient here, particularly if the data transfer can be handle by a special network protocol that takes advantage of PCIExpress.

zozbot234 4y ago
> For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? AIUI, you need something like CXL to implement a proper concurrency model that works seamlessly for both local and remote memory. So we're kinda close to what you're describing but not quite there yet.
- my123 4y ago
  HMM is on the way for a page migration-based impl that works on most hardware and allows seamlessly to use all CPU memory from GPU programs, including mmap’d files. CUDA 12 is going to be fun. CXL 2.0 and earlier just aren’t it because of a coherency strategy that is absolutely dreadful. CXL 3.0 is better though, but that’s a long time away from hardware still.
0xcde4c3db 4y ago
> The fact that the lowest level of interaction you can have with a computer is writing memory. While this is true as far as it goes, it's worth keeping in mind that not all memory controllers are equally low-level. Some of them expose cache architecture or the rectangular organization of DRAM in interesting ways.
Jasper_ 4y ago
> The fact that the lowest level of interaction you can have with a computer is writing memory. When writing device drivers, or interfacing with microcontroller hardware, the way you give commands and transfer data is by writing your command to a memory-mapped device register, or an area of memory that will be copied to the target device. This is somewhat true, but usually these devices are not designed for multiple processes to come in and start writing memory to them. On Linux, the job of the DRM kernel driver for graphics is to mostly facilitate command buffer submission, scheduling, and results gathering. We'd really just see the same exact situation on Plan 9: user-space GPU drivers which do the work of translating graphics APIs into command buffers, and talking to a kernel-side component by submitting dedicated command buffers. That they talk over a file interface isn't really relevant here, since it's just used as userspace -> kernel IPC. > The other thing is, modern computers are networks in a box. For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? Well, first, you'd need to figure out the layout of the texture you want (e.g. AMD has these layouts https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/addrlib/inc/addrtypes.h#L178-207 https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd... ), allocate the full mip chain size, allocate your texture descriptors, then swizzle the texture data into a form that the GPU can understand. Oh, and if you wanted a fast texture on desktop GPUs, you'd have to store it in host-inaccessible memory (host-accessible memory is often slower). So first you'd need to allocate a scratch buffer in slower, host-accessible memory, copy your texture data there, and then allocate the real texture storage in the faster host-inaccessible memory, and submit a copy command. That's a lot more work than a memmap and a memcpy. Maybe we put all those smarts in the driver, but the driver is going to need a lot more info about the intended usage of the texture, and by that point we're basically creating /dev/vulkan rather than a low-level GPU API.
- zozbot234 4y ago
  AIUI, a mmap file could in fact be "backed" by host-inaccessible memory. Then copying data to and from that memory would be a job for the driver, as for any block device. Other things can almost certainly be done in userspace, such as figuring out texture formats and converting if necessary. > usually these devices are not designed for multiple processes to come in and start writing memory to them. Multiplexing devices as needed can also be done in userspace. That's what, e.g. pulseaudio and pipewire do for audio devices, even those that don't support outputing audio for multiple processes at the same time.
hedora 4y ago
I've implemented high performance software atop VFIO, (roughly speaking: mmap chunks of the PCIe bus) and atop the equivalent Linux kernel APIs. With VFIO, it is at least an order of magnitude easier to get to 90-95% of what the underlying hardware can do.

zozbot234 4y ago

> For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? AIUI, you need something like CXL to implement a proper concurrency model that works seamlessly for both local and remote memory. So we're kinda close to what you're describing but not quite there yet.

my123 4y ago
HMM is on the way for a page migration-based impl that works on most hardware and allows seamlessly to use all CPU memory from GPU programs, including mmap’d files. CUDA 12 is going to be fun. CXL 2.0 and earlier just aren’t it because of a coherency strategy that is absolutely dreadful. CXL 3.0 is better though, but that’s a long time away from hardware still.

0xcde4c3db 4y ago

> The fact that the lowest level of interaction you can have with a computer is writing memory. While this is true as far as it goes, it's worth keeping in mind that not all memory controllers are equally low-level. Some of them expose cache architecture or the rectangular organization of DRAM in interesting ways.

Jasper_ 4y ago

> The fact that the lowest level of interaction you can have with a computer is writing memory. When writing device drivers, or interfacing with microcontroller hardware, the way you give commands and transfer data is by writing your command to a memory-mapped device register, or an area of memory that will be copied to the target device. This is somewhat true, but usually these devices are not designed for multiple processes to come in and start writing memory to them. On Linux, the job of the DRM kernel driver for graphics is to mostly facilitate command buffer submission, scheduling, and results gathering. We'd really just see the same exact situation on Plan 9: user-space GPU drivers which do the work of translating graphics APIs into command buffers, and talking to a kernel-side component by submitting dedicated command buffers. That they talk over a file interface isn't really relevant here, since it's just used as userspace -> kernel IPC. > The other thing is, modern computers are networks in a box. For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? Well, first, you'd need to figure out the layout of the texture you want (e.g. AMD has these layouts https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/addrlib/inc/addrtypes.h#L178-207 https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd... ), allocate the full mip chain size, allocate your texture descriptors, then swizzle the texture data into a form that the GPU can understand. Oh, and if you wanted a fast texture on desktop GPUs, you'd have to store it in host-inaccessible memory (host-accessible memory is often slower). So first you'd need to allocate a scratch buffer in slower, host-accessible memory, copy your texture data there, and then allocate the real texture storage in the faster host-inaccessible memory, and submit a copy command. That's a lot more work than a memmap and a memcpy. Maybe we put all those smarts in the driver, but the driver is going to need a lot more info about the intended usage of the texture, and by that point we're basically creating /dev/vulkan rather than a low-level GPU API.

zozbot234 4y ago
AIUI, a mmap file could in fact be "backed" by host-inaccessible memory. Then copying data to and from that memory would be a job for the driver, as for any block device. Other things can almost certainly be done in userspace, such as figuring out texture formats and converting if necessary. > usually these devices are not designed for multiple processes to come in and start writing memory to them. Multiplexing devices as needed can also be done in userspace. That's what, e.g. pulseaudio and pipewire do for audio devices, even those that don't support outputing audio for multiple processes at the same time.

hedora 4y ago

I've implemented high performance software atop VFIO, (roughly speaking: mmap chunks of the PCIe bus) and atop the equivalent Linux kernel APIs. With VFIO, it is at least an order of magnitude easier to get to 90-95% of what the underlying hardware can do.