[amelius]

My guess: because FPGAs are slow compared to mainstream desktop CPUs and only make sense if you have massive paralelism. But then you'd need a massive FPGA which would be crazy expensive, plus you'd need a good way to handle throughput.

I could be totally wrong, though.

[atq2119]

That, plus programming FPGA kind of sucks. The software tool chains are somewhere between 20 and 30 years behind the state of the art for software development.

Also, FPGAs can't be reasonably context-switched. Flashing them takes a significant amount of time, so forget about time-multiplexing access to the FPGA among different applications.

[m4rtink]

I could imagine some sort of API based queuing - say you have 2 "slots" you can program stuff on so if you play 8 k video you can have on flashed to video decoder while the other one can speed up your kernel compilation. If you then want to also use FPGA accelerated denoising on some video you recently recorded, the OS will politely tell you to wait for one of the other apps using the available slots to terminate first.

[amelius]

Is there even any progress in OSes with respect to how they deal with tasks/processes on GPUs?

[atq2119]

Progress relative to what?

Since applications do all their rendering via the GPU these days, desktop multi-tasking requires reasonably time-sliced access to the GPU. GPUs have proper memory protection these days (GPU-side page tables for each process). That's big progress over 10 years ago.

[amelius]

True. But it's still far away from a unified approach you'd expect (as someone outside the field) in a modern OS. After all, one of the jobs of an OS is to abstract away access to underlying hardware as much as possible. Until we get some improvements here, my hopes are not very high for the FPGA domain.