Why isn’t Vulkan integrated

Community
1

Hi, everyone so this was a random question I had and I was wondering why isn’t Vulkan integrated by the way this is an open ended answer and I’m going to included the research I study in the Haiku forums

So if I’m correct, Vulkan is supposed to be the modern successor OpenGL and letting it have less of CPU overhead, allowing for good CPU efficiency and it is also very complex to code so I know this, but this will allow Up to 40%–50% of peak processing and thermal stress.

The second thing I wanted to mention is App Server Neo allow for the CPU’s on Haiku to move 5x - 10x faster and not to mention Asynchronous Hardware Double-Buffering, since it running through skia will allow for complex 2D or 2D in general to be pushed out more, Up to 30%–40% of standard CPU execution overhead, pairing this with Vulkan allow for a synchronized system for Haiku as a whole
What I’m saying it is more synchronized compared to the normal way

Regular app server + OpenGL is basically a one person trying to work a kitchen which is basically the CPU doing everything in this scenario

App Server Neo + Vulkan is basically multiple people trying to work a kitchen fast, Because App Server Neo does everything within itself and pushes out work fast, Vulkan is multiple employees trying to work that kitchen and keeping up while serving the customer(user/us)

Also the reason why I mentioned App Server Neo here is because during all the forum I checked it was alway mentioned with it so I decided to do more research on it to see why it was so significant to Vulkan, in this I discovered on How it give us Hardware Acceleration as the CPU is writing frame at insane speed and the GPU is grabbing the frames via the shared ram so even though the math of the 3D shapes might be calculated by the CPU (via software engines), the actual display mechanics, frame-buffer flipping, resolution rendering, and layer composition are handled directly by the GPU hardware which give Haiku the most native form of Hardware Acceleration and that still uses Native Haiku driver + better CPU management + a better rendering system, so definitively by use using our system RAM into a zero-copy data transfer between the CPU and GPU, we are creating direct contact as we bypass the slow data-transfer delays that plague unoptimized operating systems, resulting in a fast, fluid desktop that performs like it has full hardware graphics acceleration

This was my personal take on it and I’m glad you took time to read it, but this is what I was wondering and Just to clarify I wasn’t trying to say remove OpenGL support, I mean why not keep both and use App server Neo as the main layout and Make Vulkan the main rendering engine

Thank you and I hope you have a good day

2 Likes
2

Engineering is always a balance, and there is no one-size fits all solution. Vulkan is great when you want to built commands, push it down a queue and get another CPU to execute asynchronously. Great for pushing rich scene graphs with programmable fragment shaders to the GPU. A lot of overhead and synchronization for potentially a small number of simple GUI windows. My Vulkan renderer for complex multiscreen machines with hundreds of thousands of objects is 50-80% faster than OpenGL. However, for really simple scenes (a couple of dozen or so), it is actually slower the OpenGL. There is also latency, since you push data through several swsp chains and layers before it reaches the framebuffer. For simple GUI’s, directly writting to the framebuffer might be faster than taking a massive round trip. You ever notice hiw Haiku feeks more immediate/responsive that the modern GUI’s (with blurred window shadows), the latency is shorter but as a compromise you miss out on pretty visual effects.

3

I feel like Vulkan will excel here, as it rendering everything all at once and what I mean by this is Vulkan allows App Server Neo can do what OpenGL can’t Instead of dealing with each small window as a completely separate, heavy task, the cpu can group all 20 small window textures together into a single, massive drawing queue which is more efficient than how App server + OpenGL did every single one at slow speed and also made older system feel more heavy

Which would be this

OLD APP_SERVER: Win 1 ──► Win 2 ──► Win 3 ──► Win 20 (Slow Sequential CPU Spikes)

APP_SERVER_NEO: Win 1 to 20 Batched Together ────────► GPU Executed Instantly

While it’s true that a single, simple window might face slight queue overhead, App Server Neo + Vulkan will actually scale much faster when the desktop gets crowded with many smaller windows. Because Vulkan handles multi-threading and hardware instancing natively, it can batch dozens of smaller window canvas updates into a single parallel command stream

App Server Neo and Vulkan allow for a little bit of latency but that only a 1ms of latency it still able to keep Haiku fast if not faster because of how Haiku is built along with this it allow for Haiku multi threading to be used which should allow for it to be rendered and transferred directly from the GPU instantly

4

Keep in mind that it is my personal project, it is currently incomplete and there are no any schedule guarantees. Even when completed, there are no guarantees that it will be integrated to upstream Haiku (but it will be easy to install to Haiku anyway).

6 Likes
5

Current Haiku app_server (and even BeOS app_server) already render each window parallel in separate thread. But AGG based renderer can’t use hardware acceleration and it can’t directly render to GPU buffer, shadow CPU buffer is needed.

3 Likes
6

Thank for the clarification, I didn’t know this is how the Current App Server works So the real bottleneck isn’t sequential blocking, but rather the CPU overhead of the AGG renderer forcing it to draw to a shadow buffer before moving it over.

This is exactly why your personal App Server Neo project is so interesting to analyze when I was doing research on it, because Pairing Vulkan with Skia to bypass that shadow buffer bottleneck and still allow for Haiku multi threading to be used.

Thank you for taking time out your day to reply to my thread

7

Maybe giving a look at this project could be interesting then:

It’s a C library using Vulkan to do 2D rendering, including fonts, images, gradients.
It’s under MIT licensing, so Haiku compatible.

And it seems with way less complexity and attached strings than Google’s Skia.

1 Like
8

Is the graph demonstrating that cairo es3 is really fast or really slow?

9

Cairo is dated library that is quite slow compared to alternatives. It is not used where performance is important. AGG is generally faster than Cairo.

10

It’s a benchmark graph “lower is better”, because it’s the duration to run each kind of drawing tests.

11

This is cool and that’s mean Haiku could have even more advanced multithreading

1 Like