3 ms·

> 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

> 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
> This is somewhat true, but usually these devices are not designed for multiple processes to come in and start writing memory to them. You can use virtual functions for this purpose, but you only get access for a dozen-ish procceses. Also, GPUs have support for this already. Of course, virtual machine managers and hypervisors also provide good solutions to this problem.

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

> This is somewhat true, but usually these devices are not designed for multiple processes to come in and start writing memory to them. You can use virtual functions for this purpose, but you only get access for a dozen-ish procceses. Also, GPUs have support for this already. Of course, virtual machine managers and hypervisors also provide good solutions to this problem.