Vulkan lavapipe software rendering is working on Haiku

It will be probably similar to existing Haiku software OpenGL rendering based on Mesa llvmpipe.


Great work Ilya. I’m assuming that the host buffer can be mapped to a BBitmap::Data() for display / animation loops (instead of exporting to ppm)?

My newest graphics engine is Vulkan based, and I’m really looking forward to making a Haiku port as well.

A toast for your accomplishments :slight_smile:


this is excellent, this is the first step towards hardware 3d, and x512, brother you are a machine !!!


How is porting a software driver a step towards hardware drivers?

Anyway, it’s nice to see that lavapipe runs on Haiku. : )

I assume that when it comes to developing the core-driver for the gpu, “all regkeys” , which now turn towards a software simulation on the cpu will be replaced, these will be linked one by one on the real hardware registers of the gpu, So for Intel and AMD it will be more easy because these are in the public domain thanks to the linux opensouce drivers, while for nvidia, porting will be much more difficult.

Vulkan driver add-on host library (, officially called “Vulkan ICD desktop loader”) can be used also for hardware accelerated drivers. Hardware acceleration should start working when GPU driver add-on will be installed.

Also software renderer allows to prepare Haiku infrastructure for hardware rendering. Primary difference between software and hardware renderer is output to regular RAM vs GPU RAM, the rest is almost the same. It is possible to render to GPU RAM offscreen.



bare bones basics data flow

application,>>> api/opengl/vulkan>>>>, jit compiler, >>>>memory manger, >>>>gpu hardware

so you need to have a compiler that takes your api call/program/sha
aders/drawing commands and turns them into a program the gpu can render.

he has the vulkan shader compiler working.

now he needs to get the vulkan to gpu compiler working.

then the ring bus of cpu/ram to gpu/gpu ram needs to be done

then a bunch of hardware setup calls, etc.

first step, and a rather large one

the vulkan to amd gpu compiler for shaders and textures is nearly os agnostic iirc as long as you have solid posix compliance

I’m aware of the basic infrastructure, but we already have llvmpipe, I don’t see how lavapipe gets us any closer to 3d accel on it’s own. it seems like an orthogonal component to me.

Unlike OpenGL, Vulkan do not depend on windowing system and it have driver add-on system with standardized API (Mesa also have OpenGL driver add-ons, but it have non-standard Mesa-specific API). OpenGL may need more work for windowing system related code.


at this point Developing Vulkan on real hardware is more strategic than developing OpenGL, since now Zink running on Vulkan compensates for the lack of OpenGL support by giving performance similar to native accelerated OpenGL.


it is somewhat orthogonal, but intel and amd are assistant in creating natuve vulkan drivers and rendering engines etc.

have this allows work towards the next step, and hopefully real gou drivers.

opengl needs to die, it’s full of a lot of cruft and thdre are very efficient translation layers that go above vulcan

OpenGL is an api, your argument makes no sense to me. I am not ready to throw away all OpenGL applications for a goal of only supporting the newest and leanest.
Supporting Vulcan definetely makes sense for Haiku, but so does supporting OpenGl… and direct3d9 direct3d8 (through wine, likely a translation layer aswell) etc. In the end we want to be able to run applications that use those “older” apis, regardless of how the driver stack looks in the end

OpenGL is still useful for simple 3D graphics such as scientific visualizations. Vulkan need many boilerplate code to do even basic things. OpenGL can run over Vulkan for example by using ANGLE.


There is DXVK project that implement Direct3D API over Vulkan.


vulkan should be the native base layer api as driver maintenance becomes massively easier.

everything else can be a wrapper or translation layer above it, let those who wish to use broken outdate graphics APIs maintain them.

1 Like

I don’t know, maybe I’m wrong, but from what I read in following the comments, it seems some of you are not clear what Zink is, it is full support of OpenGL 4.6 and OpenGL ES 3.2 on top of Vulkan, so the problem of supporting OpenGL does not arise once Vulkan is developed on real Hardware.


correct, there are upper layer translation frameworks which make adding opengl dx ontop easy

True. Also, Direct12.0/GL ← VK wrapping (photon) as well. Most of this just happened this year.

The compatible profile is what is desirable at OpenGL 4.6. This seems hit/miss at the moment when I
reviewed it.

Let’s see once the work is pushed out for wider use.


Not certain but I think that the significance is that supporting mesa/opengl accelerated drivers from Linux requires a lot more porting effort because they are very Linux specific (to the driver architecture and also windowing system) and it isnt really clear how to even do it cleanly. Whereas Vulkan drivers are much more portable and comparatively straightforward to port.

1 Like

Radeon Vulkan driver compiled successfully (Intel driver complains about missing symbol dl_iterate_phdr). In theory hardware 3D acceleration should start working after adding kernel DRM support.