Libdrm now officially supports 2 operating systems upstream!

And everyone also loves to tell us how Haiku would be out of beta by now if we had just used the Linux kernel, etc. etc. It’s probably true, but it also completely misses the entire point of Haiku.

1 Like

It is not being spent for more than 10 years. And will be likely not being spent next 10 years if approach will be not changed. “someone else with the requisite knowledge will tackle #2 and #3” that satisfy you will likely never come ever.

You didn’t answered what is use case of multiple GUI sessions for different users. Implementing multi-user support before hardware acceleration will delay it for many years. Hardware acceleration can and should be implemented without multi-user GUI session support.


I don’t know why you are saying “that satisfy me” here; my only real requirement is someone who is a proficient programmer and can either learn quickly (and without my help), or who already knows their way around the systems, and can collaborate with others on open source. That’s it.

In fact, in your earlier forum post about 3D acceleration, you sounded interested enough and I suggested we start a conversation outside the forum on it. If you have the time and are willing, I think we could at least get something to work, as you clearly know your way around Mesa.

Of course. But if we are designing a display_server, it makes sense to at least consider that it may be used for such things in the future, even if that is not an initial use of it.

1 Like

I don’t know what you are expecting for help. You can talk me anytime on this forum, github or e-mail but I don’t use IRC. You can start porting kernelland DRM part from Linux or BSD, it don’t need others help. When you finished tell me and I will try to make accelerant and Mesa DRM support.


Alright. Right now I am working on beta2 related items, as time permits (as I am Release Coordinator, again), but I will get started on that again after the release comes out.

Speaking of which: if your Mesa patches are finished in the next ~2 weeks, we could get a Mesa build with them into beta2. (It would also be nice to have those upstreamed; I can ask kallisti5 to review them on Freedesktop if you push them there.)

Well, having some kind of chat system instead of those would be better for more “real-time” discussion. We can work that out later, though.


You know what will happen anyway? People will move to the next item on their checklist.

  • 2010: Do you have an office suite?
  • 2020: Do you have 3D acceleration?
  • 2030: Do you have a modern web browser?
    and so on and so on…

That’s why I’m not so worried about 3D acceleration currently. Personally I’m not sure what I’d do with it, and I think my time is better spent on things I actually need to use Haiku, like a working web browser. It’s easy to see that over time, the situation degrades there (because the web keeps moving on, and our web browsers don’t) and I’m doing more and more things on non-Haiku computers. And this puts Haiku in danger a lot more than lacking 3D acceleration (not because of just me, but because web browsing is actually more important than 3D acceleration for our current users).

And on top of that, I’m annoyed that the way to implement 3D would be “get the code from Linux”. Intel has now stopped providing docs for their hardware. The documentation for the last 3 generations are a 7-page pdf with no programming info whatsoever (Open Ecosystem). And my efforts in contributing to Haiku is also here to show that yes, if the manufacturer gives us the hardware specs, we are able to implement our own drivers and design our own graphics architecture. And this should be the normal way things would be done. Without specs as Intel did in the past, Haiku would not exist in its current form. The BSD on the other hand have always shared a large part of the drivers with Linux, these used to be on the X server side, with DRM a larger part of it moved kernel side. Yet they pretty much have the same graphics stack. We don’t. So, how close to Linux drivers should ours be? Should we import the whole thing? Just port the driver? Try to get the driver to play nicely with our existing one? Write our own thing? The options are open, despite waddlesplash being set on one of these approach and then not actually implementing anything. If someone wants to have fun with one of these, just try it and see what happens :slight_smile:


Of course I don’t know. I said that it will unlikely that graphics acceleration will be implemented in near future with current waddlesplash approach (deep redesign of many Haiku parts, multiuser support etc.).

Modern web browser need graphics acceleration for proper operation: WebGL, video rendering, layer composition etc. Current WebKit port is broken because of kernel virtual memory manager problems (#15804).

Creating OpenGL implementation or even new graphics API from scratch is near impossible for small Haiku team. DRM can be used as one of implementations of graphics acceleration and client software should not directly communicate with it. Some API that abstracts DRM and allows different implementations can be provided if needed like DXGI in Windows.

The modern browser requires a GPU in the present time for normal operation. I’ve tried to make Qt WebEngine (blink) work - and there’s a lot of hardware acceleration that’s wanted there. These things are interconnected.
It is possible to do this without the GPU, but this is also a set of not very well-working workarounds.


Yes, that’s the general situation with new browser software right now. QtWebEngine is expecting hardware acceleration by default and the fallback is to render on the CPU like what LLVMpipe and SwiftShader (used in Blink) do, which isn’t good enough anymore.

At best we must have a GPU-accelerated solution, thus an interest in getting DRM graphics drivers on Haiku is something required to increase the performance in browser software for both WebPositive and Blink-based browsers

1 Like

Have you tried to use BGLView? Mesa software rendering is good enough to run latest Blender.

1 Like

That’s the situation with Blink. Not quite as much with WebKit, and not at all with NetSurf, for example. Generalizing to all web engines isn’t quite right. And there is a LOT to do in WebPositive to optimize what we have without going with 3D acceleration just yet (at least make it not crash every 5 minutes and fix all the network-side problems).

I would also be quite annoyed if Blink was the default web browser engine everywhere. Having multiple engines around is good for alternative OS. Oh well.

That’s because Coffee Lake, Amber Lake and Whiskey Lake are not new generations. They’re all Gen9 parts fabricated on different nodes, so Skylake programming documentation applies.

Documentation for Ice Lake, actual new generation (Gen11), is published and available at the link you provided.

Disclosure: I work at Intel on graphics software.


The problem is that all that progress towards having a modern office suite, and modern web browser are basically stalled, both of those these days are going to now require 3d acceleration (yes LibreOffice is going to require it most likely and a usable we browser already does). And yes I’m aware webkit doesn’t require it… but it would benefit from it, there is a reason every major OS has hardware acceleration for that now.

So it’s not so much what you will do with it… it is how much your experience can be improved with what you already do, and in some cases of course there will be new things that can be done.

Ok, good to know, that’s some less work for us when we start working on these modern devices, at least. Still, I find that the docs used to be better for the early devices, and the SandyBridge one (and probably the next ones, even if I didn’t look as much there) is not as good. Quite often the docs are not very clear and my only hope to understand things is seeing how it’s done in the Linux driver (for which all the modesetting code is a single 10000 line file, where ours is a dozen files with nicely split out objects). I guess hardware documentation is never as good as a software developer would want it to. The Be Newsletter articles were already full of rants about such problems, and I’m also on the other side of this when I design and sell hardware devices.

They don’t currently require it and there are a lot of things I think are more important. Talking about graphics drivers, the thing that gets most in the way for me is not 3D acceleration, it’s the ability to display anything at all using the VGA output on my laptop, instead of the internal 12" display. When I’m home it would be nice to use that nice 24" screen. The result is that I just use that display with Windows or Linux. And I’d say time spent making this display work with my laptop would be more useful to mo than work on 3d acceleration. So that’s where I’ll put my focus. Then we’ll see where it gets us.


??? ??? ???

Why would LibreOffice require GPU acceleration? The OpenCL backend in Calc may be nice but why would they require it? That would be extremely dumb.

I also don’t know what you mean by “all that progress towards having a modern office suite are basically stalled.” We have LibreOffice, you can install it and it works, with only a few bits of missing functionality.

It’s also the case that WebKit still does not require GPU acceleration. Individual rendering backends do, but the whole point of WebKit is to abstract the rendering backends from the layout engine so that it can run on multiple platforms and APIs.

LibreOffice is being ported to Vulkan… I’m sure they will retain the old backend for awhile but all the modern platforms do support vulkan so the backend we use would end up being both slower, and less tested.

WebEngine works with both Direct3D and OpenGL, so they definitely have some kind of abstraction layer here (or are they just using ANGLE?) Either way, using BGLView as @X512 mentions should work now.

So they are just going to completely abandon native UI look and feel, and have a uniform (and foreign) look on every platform they support? Why would they use Vulkan directly anyway; they do basically no 3D rendering, so working with Vulkan directly would be a massive maintenance overhead? This just doesn’t make any sense at all.

Technically and just barely that, it’s impractical to browse with a modern browser engine with more than a handful of tabs, or with more than modest pages without it though…

OK, I found an actual article that explains what LibreOffice is doing. Turns out, they are just replacing Cairo with Skia, and Skia has a Vulkan backend, of course.

But Skia is just another 2D graphics API. They are in no way tying LibreOffice to Vulkan, or even to GPUs at all. Skia still has a CPU-only rasterizer (which is faster than Cairo’s, anyway, it’s not there just for “technical completeness.”)

So indeed your analysis of this situation is completely wrong. Even if they drop support for Cairo, they are in no way mandating Vulkan.

1 Like