I want to apply to Haiku for Google Summer of Code this year. I love working with hardware and hence the “GPU acceleration support” project really catches my eye. Last year, I wrote drivers for the Raspberry Pi 4 for the RTEMS project as part of GSoC.
I have a fair amount of experience in firmware development, but this will be my first time messing around with the GPU. I love how Haiku brings life to old hardware and its focus on minimalism. Hence, I am excited to dip my fingers into the field through Haiku.
I have already read the GSoC FAQs and guidelines posted on the website. Still, I wanted to ask what I could work on to increase my chances of getting accepted. Are there any tasks specific to the “GPU acceleration support” project that I should look into?
The scope of that is very wide, but I would be very happy if you could write drivers for on of my GPUs(GeForce GT218 and GeForce GT260), so I can get a non 4:3 resolution, on a 16:10 screen. (using 1600x900 ATM, when the native res is 1440x900).
There are two main things you could work on on the top if my head: 3D acceleration, i.e opengl/vulcan. The other is accelerated decoding of media, linux has vaapi and vdpau for that for example.
Nvidia drivers are pretty much a waste of time… get a supported GPU and call it a day.
X512 has some work on acceleration but apparently it isn’t in a state where it could be merged, I think he has gotten things to acutally run at least on specific gpus.
For GSOC updating that work + doing some cleanups on it, would probably be a reasonable goal. What probably should not happen is, someone starting yet another implementation of that work all over again for like the 5th time…
Just to be complete in replying to this, Rudolfc did write reverse engineered drivers for GeForce 2 era hardware and maybe a bit later than that, pretty amazing considering it was a separate own implementation, but these were all fixed function GPU hardware. Nothing remotely recent. All the recent GPUs are more complex and have their own compute engines and compilers to implement support for so the barrier to entry for undocumented GPUs is vastly higher today than it was then.
There is some work in Linux land to make it possible to write open drivers for Nvidia but it requires relying on a gigantic blob, so even from that standpoint its problematic for developers even just implemented 2D is a problem there…
AMD and Intel and a few mobile GPUs are more viable targets since they have better documentation or at least have a good working open source reference implementation to port.
The shortest path to 3d on Haiku… is probably updating and cleaning up X512’s accelerant as I mentioned before. This would get you 3D on a wide range of AMD cards to start with. And once the architecture is cleaned up and nailed down more could be added. I think this is the only implementation so far that has gotten as far as rendering anything on a recent GPU for real. So it can be considered a real proof of concept and probably be best starting point since it actually works.
The poster above asked for modesetting drivers for nvidia cards. That is, in my opinion, feasible to do. nouveau provides this among other things for linux.
Getting those to do 3D „good“ would be much different, but that isn‘t the problem.
While I agree with cb88 that nvidia cards for 3D are not a great target I still think that it is quite doable to have nvidia drivers for the „please set my monitors resolution“
Or for the dual-gpu laptop case of „just turn off the nvidia gpu“
It’s feasible theoretically but not a good place to spend valuable time and money which again is what we are talking about here… My dual GPU laptop doesn’t have an Nvidia GPU, is recent also. Both GPUs could be supported by the same AMD driver in fact. If intel’s dGPUs ever take off the same could occur there.
The answer here is always going to be buy compatible hardware, and in the case of developing drivers it needs to be the shortest path to getting a working implementation integrated into Haiku.
The Nvidia GSP based Nova driver on Linux in development would require a massive mount of work to Haiku to get working as it would require Rust support in the kernel. Even then that still would not support the mentioned GPUs… only recent stuff after the RTX 2000 series. The status quo on the GPUs prior to GSP on Linux is that they will never have good support… because they are undocumented and reclocking probably will never work right.
I would suggest checking out what X512 has done. In his WIP driver, he has focused only on Vulkan, with Zink being used for OpenGL support. This seems like the best way to develop a driver, and is also where vendors like Imagination are heading.
It’s also worth noting that Vulkan itself is lower level than the internal gallium API in Mesa itself… so ZINK can sometimes be faster than the gallium driver, though it often isn’t due to being less mature. Pretty much everything is targeting Vulkan though these days.
The rust language is inadequate for writing drivers in the C and C++ kernel, the LInux kernel creates problems and keeps reinventing the wheel, it is not a good example of stability.
In this links there is a good basis for porting drivers to Haiku:
Rust kernel drivers may be actually easier for porting to Haiku compared to C ones because of proper module support (no #include hell) and less non-standard language features such as GNU C extensions.
It can be easy to port to rust, devs with skills and knowledge in security practices, there are few, rust is not a solution for everything, nor is Redox an OS phenomenon.
Indeed, it would be easier to port rust and then to port drivers would need less work but as you stated it is not an option.
But, I think that what X512 says is that the code of rust drivers being cleaner, you have a better chance to understand the behaviour and to replicate it in the language of your choice. That’s more work and you need more advanced skills though.
No, I mean that it will be easier to port (not rewrite) some existing Linux kernel driver written in Rust to Haiku comparing to Linux kernel driver written in C.