I’m a developer with good skills in 3D graphics, kernel drivers, assembler, verilog,etc.
I’m working on a project(see details below) of usermode daemon which will run GPU drivers on linux. I do know how GPUs work(primarily AMD ones), I do know how PCI works, I do know how kernel and page tables work, I used GL a lot, and so on.
On the other side, your project needs “3D acceleration support”. My project can be exactly what you want, especially in case of multicore cpus. However, porting my code from linux to haiku may not be a trivial task.
For example, I reimplemented UIO driver, and it must be rewritten again for haiku. My daemon takes pieces of system memory and makes it available to both GPU and client processes. Some efforts may be needed to seamlessly integrate with existing vesa driver. At least tell it: hey, tell me video mode you want, don’t touch this PCI device without using my callbacks until I die, and I’ll give you a buffer in reward.
Another unix-specific task is communication with client process: I use unix sockets to pass a file descriptor to client. Workaround is needed!
Details: actually, my project is "opensource massively-non-parallel processor. It will be something like a lot of fused cpus on a chip with specialized units like hash map accelerators, atomic op processors, and texture io units. I consider it as sort of GPU. My gpu will need a driver, and that’s why I started learning about linux dri, and my findings were the reason why I decided to move the whole stuff to a separate daemon: undebuggable overcomplicated legacy shit.
Now I’m working on moving all drivers from kernel space to user space. Modern CPUs have lot’s of cores and games do not utilize them all. We can bind our daemon to a core(N-1th), boost it’s priority. As for interoperation with drivers - i do know how drivers work and I’m sure I can reuse existing Mesa code once for all GPUs. And no more bumblebee or optimus!