It will be probably similar to existing Haiku software OpenGL rendering based on Mesa llvmpipe.
7 Likes
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 
6 Likes
this is excellent, this is the first step towards hardware 3d, and x512, brother you are a machine !!!
5 Likes
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 (libvulkan.so, 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.
8 Likes
ok.
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.
4 Likes
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.
2 Likes
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.
3 Likes
There is DXVK project that implement Direct3D API over Vulkan.
2 Likes
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.
3 Likes
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.
3 Likes
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.
16 Likes