[GSOC 2024] GPU acceleration support -- GSoC application withdrawn

Community
9

We already have nvidia drivers.

Writing modesetting drivers for more modern nvidia cards is feasible and should be done.
probably not by this GSOC though.

10

Not for any cards made in the last 20 years…

I don’t think your comment, while technically correct, brings much useful info here.

11

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.

1 Like
12

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“

2 Likes
13

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.

1 Like
14

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.

2 Likes
15

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.

2 Likes
16

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:

https://dev.haiku-os.org/ticket/18191

This link shows the problem when mixing rust with C:

https://madaidans-insecurities.github.io/firefox-chromium.html#miscellaneous

1 Like
17

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.

1 Like
18

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.

19

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.

20

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.

3 Likes
21

Ref:

Something like this:

  • Integration of libdrm2/libdrm, libglvnd, libvulkan, etc (see: @X512, @kallisti5.)
  • Integration of RadeonGfx driver (see: @X512.)
  • Demo successful work on a Haiku-based x86/x86_64 test platform.

This allows you to learn, develop, enhance, test, and integrate a full graphics stack and learn about Haiku’s app_server.

Always remember, there’s levels to this… but keep it simple and on target.

4 Likes
22

That is an interesting point I hadn’t thought about… basically Rust itself being a different language is forcing them to make a clean diver API. Perhaps even because there are fewer ways to skin the cat in Rust anyway by design it may prevent some churn.

3 Likes
23

@UtkarshVerma

Currently, we have a “functional” mesa glvnd + libglvnd implementation. It’s pretty buggy though with drawing artifacts which is why we haven’t upgraded to it yet.

The “OpenGL Kit” (aka, our libGL.so dispatch code) has been moved from upstream mesa to libglvnd, so we need to fix those bugs soon if we ever want to upgrade mesa again.

Fixing a few bugs in our libglvnd implementation would be a great entry point to this project. Even a few fixed drawing bugs will make the libglvnd dispatch code ready to go live

You can find examples of compiling libglvnd and mesa here:

If you’re looking for a quick way to get started:

  • Build + Install the libglvnd package (which will uninstall mesa) via haikuports
  • Uninstall any remaining mesa packages

Compile mesa, using the meson flags in the recipe for 23.1.9.

Once the build is complete, the libEGL_mesa.* binaries and 50_mesa.json go in ~/settings/non-packaged/add-ons/opengl/egl_vendor.d/

This should give you a glvnd mesa EGL renderer. Then you can test things like GLTeapot, Haiku3D, GLInfo, etc.

7 Likes
24

I think you meant
~/config/non-packaged/add-ons/opengl/egl_vendor.d/

5 Likes
25

Yup! Sorry, wasn’t looking at a Haiku machine when I typed that :slight_smile:

4 Likes
26

Thanks a lot for your feedback. Unfortunately, circumstances have changed on my end and it won’t be possible for me to participle this year. I look forward to contributing to haiku next year.

It’s a great project and has a good community around it.

4 Likes
27

Aargh! You were starting to get my hopes up! :grinning:

Best wishes on your pursuits. :wave:

2 Likes
28

So good to be true.