On 27.04.23 12:51, Raj J Putari wrote:
id write it but im an amatuer and i dont have time to read the kernel source and experiment, we're talking about nvidia and amd video cards assisting in processing heavy data.
obviously not w/ NVidia (except for some old, already reverse-engineered gpus), since Nvidia is doing all they can hiding the necessary specs to write drivers from us. Forget about Nvidia. Never ever waste a single penny on that.
lets say youre compiling a kernel, you can write optimizations into the kernel through a cuda module and offload cpu data directly to the gpu using opencl or cuda or what amd supplies,
cuda, opencl, etc, are *userland* *library* APIs. They don't work inside the kernel. One had to write something similar *inside* the kernel (which is working very differently from userland). Also consider that the most complex stuff (eg. creating command streams) is done in userland (eg. mesa's pipe drivers, ...), the kernel is just responsible for some more lowlevel things like buffer management, modesetting, etc. If you wanna go that route, you'd have to create something like Mesa's Gallium inside the kernel. Besides that this is a pretty huge task (and you'd have to reimplement lots of drivers), you'd also have to find a way to get a good performance when calling from userland (note that syscalls, even ioctls, etc, are much more expensive than just plain library function calls inside the same process). Probably comes down to using some bytecode (tgsi ?) and loading it somewhat similar to bpf. Assuming that's really up and running one day, it indeed could solve other problems, eg. clear separation between containers and hosts (for now, containers still needs the userland parts of gpu drivers for the corresponding host hardware). But be warned: this is a huge endavour, *a lot* work to do and hard to get it right. OTOH, I'm yet sceptical whether there's much practical use cases for using GPUs by the kernel *itself*. What exactly do you have in mind here ? --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
