Vulkan lavapipe software rendering is working on Haiku

Development
64

Have a look at Vulkan Tutorial, it seems to have the most traffic besides Sascha’s pages. Win/linux/osx support with same codebase.

https://vulkan-tutorial.com/en/Development_environment#page_GLFW-2

1 Like
65

Good day @X512,

A really nice job there, KUDOS!!! I wonder if the hack you are using to get “window output” could be the same needed for Godot to work inside a window instead full screen [@CodeforEvolution, @cocobean]?.

Keep up the good work.
Regards,
RR

6 Likes
66

Intel Vulkan driver also need futex functions (futex_wake, futex_wait) that currently unavailable on Haiku.

4 Likes
67

Actually Haiku kernel has similar syscalls (_kernel_mutex_lock etc.) that can be used to implement futexes.

5 Likes
68

I managed to build Mesa Intel Vulkan driver (libvulkan_intel.so).

Problems:

  1. dl_iterate_phdr function missing.
  2. futex_* functions are not implemented for Haiku.
  3. memmem function is missing (but present in libroot.so source code, probably not included to build). libgnu was needed.
19 Likes
69

With some hacks Vulkan is working with GLFW and vkgears example. WSI add-on currently creates its own window instead of using GLFW window, so 2 windows are created. Proper support need adding Haiku Vulkan WSI surface extension.

screenshot28

24 Likes
70

Ilya, thats fantastic, I can now port my next gen Vulkan graphics engine to Haiku. My benchmarks on supported hardware for 4K content went from 1200fps with OpenGL to 2000fps with Vulkan, same scene complexity. Looking forward to running this on Haiku as well.

9 Likes
71

Nice! So is this hardware accelerated or still software rendering? :smiley:

1 Like
72

This is software rendering by Mesa Lavapipe. Hardware rendering needs DRM support in kernel. I want to investigate what is actually needed from DRM by Vulkan userland driver. Maybe DRM ioctls can be implemented for existing Haiku kernel drivers such as radeon_hd (initial attempt by @kallisti5) instead of porting large and hardcoded to Linux kernel drivers.

7 Likes
73

What engine? Can you give a link?

1 Like
74

Sorry my friend, its a proprietary company engine, used in my employers embedded systems (https://www.atlasgaming.com.au/moregames - like to current OpenGL products, next gen is Vulkan).

75

Can commercial games be released on Haiku?

1 Like
76

My employers products are shipped on embedded proprietary hardware, to licensed clients in a regulated market. Not available for the general public.

Lots of embedded systems need 3d graphics stacks (car info systems, kiosks, public displays, and of course phones and tablets). A good opportunity for Haiku some day. And the work you’ve done for Vulkan on Haiku is an excellent starting point …

6 Likes
77

well, i didn’t quite understand, but even if it’s proprietary, nothing forbids a closed code demo as a working example on haiku, am i right?

p.s. more generally speaking i can’t wait to see demoscene OpenGL (via zink) and Vulkan brought in large quantities here on HAIKU :star_struck:

1 Like
78

Is this something brand new, started about ten days ago? looking at the code looks like yes, am I right?

In any case I wish you the best of success guys, this could be an incisive milestone.

79

First patch version date is 24/03/2021.

1 Like
80

Thanks for correcting me, I had absolutely not seen the various patchsets over the time.
So I started reading all the history of your comments from March until when I saw that kallisti5 proposed on twitter 3 graphs to get to the acceleration.
Which model was finally chosen?

One

Two

Three

2 Likes
81

I think that they are terrible at architecture designing. DRM kernel driver is over-complicated, non-portable and insecure (more code in kernel means more vulnerabilities). Why they even move graphics driver to kernel?

Vulkan made situation better because of standard userland driver API and windowing system abstraction.

4 Likes
82

This seems to make sense.
I think that one of the best advantages of haiku in its “slow development” is that you can see the mistakes that others have made and this helps to choose cleaner and smarter approaches.

4 Likes
83

Design by committee, on steroids. linux has this disease.

I’d put the hardware drm in it’s own accenerant, and don’t be afraid to create more accelerants for each card manufacturer. In fact, I’d break the driver stack up into accelerant and accelerant add-ons wherever possible. There is a pervasive effort to put to much hardware coverage in each driver. It’s ok to hard a radeon, radeon hd, Radeon 560 etc. Same for all drivers. Better to have a simpler driver than try to mske one driver fit all that is fragile to other hardware compatibility changes. Fix one card, break another etc.

I imagine there is a need for a kernel level driver for certain card functions, but that should be minimal at all costs. Again, if there’s lits of ifdef going on, break into hardware families.

3 Likes