Hello there! I’m a new user here (first topic), so please forgive me if I’m not in the know about certain things.
Haiku seems to be quite focused on efficiency and Vulkan lets developers make their graphically intensive applications be more efficient. From an outsider’s perspective, they seem to be natural fits. Is it possible to have Vulkan support on Haiku? It may not even need to be GPU-accelerated (at least for the meantime) using this. It might be one way to get software rendering that’s closer to hardware-accelerated performance-wise without it actually being so.
Just imagine, 3D teapots scattered about spinning at around 1000 FPS or higher simultaneously and evenly distributed across cores…
This may be within reach using the existing Mesa renderers on modern systems. But there is no point in 1000fps, it makes more sense for the teapot to be vsync’ed.
I don’t know much about 3D rendering, but if this thing is software-only, then it should not be too hard to port, and may serve as a base for designing and experimenting with an API for Vulkan.
It only uses the CPU, so its considered software-only right? After all, Kazan doesn’t required specialized hardware; compare this with the usual way to use Vulkan, which uses hardware explicitly designed for graphics (GPUs). Additionally, Vulkan applications tend to distribute their workloads more evenly across cores in contrast to OpenGL due to better support for multi threading.
Here are some videos demonstrating this with Vulkan and OpenGL ES; the latter is pretty much identical with the desktop version when it comes to multithreaded performance:
There’s also this article from Phoronix detailing some benckmarks between OGL vs. Vulkan if you want to see more information.
BTW, that 1K FPS with multiple teapots thing was just a thought for fun. What would be interesting is to see that on older or low-powered systems.
Addendum: It seems that there’s another related project from Google called SwiftShader that’s also been working on getting Vulkan running atop CPUs according to this Phoronix article
We really should invest effort into hardware support though as vulkan on a CPU will never be very performant compared to the available GPUs at the time or even several year old GPUs.
Also much of the work for supporting hardware opengl is the same work as for supporting hardware accelerated vulkan.
No argument against Vulkan (my graphics engine is both Vulkan and OpenGL core profile), the thing is that as of Sep/2018 there is no Vulkan software renderer. MESA still doesn’t have a pure software Vulkan renderer.
When an open source software renderer is available for another platform, I’m sure Haiku will get a port.
Perhaps getting Vulkan on CPU working on Haiku can still help to some degree? I can certainly think of one area where even software-based Vulkan rendering may help significantly: multimedia playback. Media Player (the Haiku app) and WebPositive could both be able to play 4K@60 videos if they can utilize Vulkan for video playback. Turns out that this bit is wrong; see @cb88’s response below.
Anyone else have other thoughts on how software-based Vulkan can help Haiku?
No that isn’t true at all. Haiku’s software rendering is about as good as you’re going to find. Vulkan doesn’t accelerate video decoding… only painting to the screen and perhaps some post processing. From the perspective of painting video on the screen vulkan and OpenGL are roughly the same.
Mesa3d has video acceleration via VDPAU and VA-API but those are completely separate from Vulkan. Also just for reference VA-API is probably the one you’d want to support as VDPAU has VA-API wrappers available.
Why do people think Vulkan is the silver bullet? Vulkan just removes some overhead by the driver since the user is now responsible to hand-manage everything (which removes certain checks). In the end the command queue goes through the same GPU as with OpenGL. Vulkan is only faster if the engine has been written suboptimal against OpenGL. If you use an optimal OpenGL implementation then Vulkan is marginally faster (sometimes even slower). So no, Vulkan will not make Haiku render faster, especially not without an accelerated GPU driver. What it does is making the driver simpler since Vulkan compliancy is less complex than OpenGL compliancy. But that’s about it.
It’s not about performance, it’s about larger and more open support by GPU makers.
The lack of Vulkan software renderer is an issue because for alternative OSes, GPU support is always lacking if not totally missing, and without a fallback solution, user won’t see anything at all.
Actually @phoudoin, it’s both. You’re correct in your statements, but let’s not dismiss the potential gains in performance when rendering with Vulkan.
Speaking of which, Vulkan isn’t only faster on engines that are suboptimal with OpenGL @dragon. Even games designed with OGL in mind have shown perf improvements (however big or small) when using Vulkan. One can just look at benchmarks and comparisons between the two for games like DotA 2, DOOM (2016), and the entire Croteam catalog utilizing Serious Engine; the majority of these run better using Vulkan despite being made (or reworked) for OpenGL.
Last I checked, there have been no benchmarks done yet using software-based Vulkan. The value of these tests is showing the possible speed gains of using it over OpenGL. If these were done on the CPU, the numbers would be lower; despite this, Vulkan would (at least theoretically) remain faster due to the lower overhead.
“no benchmarks done yet using software-based Vulkan”
That’s because there is no complete software Vulkan implementation and until there is talking about porting a partial implementation is a waste of time. Software Vulkan literally doesn’t exist. If someone ever bothers to create it then we can talk about porting it but chances are we’ll already have hardware vulkan by then…
Its also worth noting that kazan3d has been abandoned for about a year.
There is another one here https://github.com/baldurk/visor that is probably better but again, not complete (though it does work for some subset). Not that it is barely runing that scene at 40FPS… as simple as it is.
While Vulkan is designed to reduce overhead for GPUS, there is good chance it actually increases overhead on CPUs. OpenGL originated being mostly software rendered and gradually acceleration was added over the years… Vulkan goes the other way.
I’ll address the issue using OpenGL (GLTeapot, software-only):
Mesa 17.1.10 for Haiku: 1 teapot @793-810 FPS (debug)
Mesa 17.1.10 for Haiku: 40 teapots @28 FPS (debug)
Mesa 18.2.0 for Haiku: 40 teapots @34 FPS (release)
Yet, I could tell you a story of running glxgears on a AMD Radeon 9200 versus the AMD Radeon HD 4870…
Anyhow…
I increased GLTeapot further than that, but hope you get the point. I can open multi windows with various teapots spinning or other demos. Haiku handles the pressure quite well. All OpenGL software rendering.
Speed is referential to a few factors. You have to judge and measure accordingly.
Vulkan 1.1 API/driver hardware implementation benchmark will reflect a 13%-40% improvement difference depending on a reprofiled optimized application for Vulkan versus OpenGL spec. Note that it mainly depends
on your graphics hardware implementation and internal speed as well. There are he early presentations of Vulkan that tell you about this theorem or existing test results.
Just use the FOSS solutions out there if you want to dabble. Go to the bigger vendors if you really want to get your feet wet…
No one should be impressed with 40 GLTeapots… its not even a benchmark or reflective of any real world application. Demos like that are mostly memory bandwidth limited… very little computation is done relative to real applications. It wouldn’t even call it a heavy mutithreaded workload… its a bunch of applicaitons doing memory copies without any syncronization or any significant computation at all.
Software rendering is a stop gap measure for testing applications and potentially running lightweight GL applicaitons on fast CPUs untill hardware support shows up, nothing more nothing less.
Also lets just stick to the concrete facts instead of vague generalities about performance, hardware accelerated GL and Vulkan will be a huge benefit, and both will continue to evolve over the coming years in parallel. So, to say that GL or Vulkan is faster or slower than the other is not nessesarily true.
“Just use the FOSS solutions out there if you want to dabble. Go to the bigger vendors if you really want to get your feet wet…”
Not sure wat you mean there… Mesa3d the “FOSS solution” is supported mostly by AMD and Intel and is in some cases even faster than the proprietary drivers…
Surely this is not true? OpenGL was created by SGI, whose defining feature was their graphics cards, based on IrisGL… though I know that they included software fallbacks if the hardware did not support a particular feature.
The earliest cards could only do Gouraud shaded polys or wireframes… if you wanted texture mapping you’d have to do that in software. Some cards would even lack z buffers and geometry engines … so yes software support first then accelerated because most people/companies couldn’t even afford the hardware accelerated machine that only got you as far as accelerated wireframes etc… anyway.
IrisGL originated in the early 80’s not the 90’s as you might expect. You can argue it one way or the other but GL always had software support unlike Vulkan.