Plans for 3D acceleration


#41

My point being this: Designing from scratch takes much longer than adapting an existing design. If you or somebody you know can provided the necessary time and skills, then… Patches welcome!


#42

GPU is sophisticated and powerful computational unit. It would be good to use it more than for 3D graphics.


#43

The situation is more like EVERYONE else has these badass bridges… it just so happens that one of them has plans and near complete manual for how to build it nailed to the side of it (Linux)… And several projects are already copying it so we have examples of how to do that (Open/Free/DragonFlyBSD) . And there is so much work going into the Linux bridge and it is such a fast moving project that just keeping up with porting it is alot of work.

So, it’s not that we should run off and build our own bridge because we think we can do it better that is NIH syndrome and with so few developers it would be doomed to failure (even a large group attempting it would likely underperform the already existing implemenations)… rather we just need to spend just a little effort and get 99% of the benefits for 10% of the effort.

Doing this port also means that you get OpenCL and Vulkan for just a bit more work… so it isn’t just 3D stuff. And potentially video acceleration as well though that is probably a bit more work than the rest since it would require hooking into the existing Mediakit or perhaps creation of MediaKit2. It would also be cool if AMD’s ROCm toolchain could get ported then Haiku would also have tools for images processing and AI etc… doing stuff like this is at the heart of what BeOS was and why the early Be machines had DSP coprocessors.

Accelerated 3d also means accelerated browsers… accelerated media playback means youtube uses less power etc…

Probably waddlesplash is going to do this work but it won’t be just him we’ll all get to test it out… report bugs and submit patches to get it going on as much hardware as possible. It’s probably is going to require a big chunk of his or someeones time to polish this port so we should be ready to support them when it reaches a substantial enough point to show off before the next phase of development.


#44

This is all very exciting!

What do you all think would be the first step in porting OpenBSD’s drivers to Haiku? If possible, I would like to bug test for them. How much would work be involved in porting OpenBSD’s Intel i915 drivers for Ivy Bridge and backwards?

I also have some stupid questions. How much more work would it take to just write new hardware accelerated drivers native to Haiku for Intel integrated graphics

What kind of performance hit would be incurred by adding a compatibility layer between Linux’s DRM infrastructure and Haiku’s app server? Would this performance hit be “compiled away”?


#45

We don’t know yet… come back in a month like I already said. Waddlesplash might have an update on this by then … it could be sooner later never… :stuck_out_tongue:

It’s probably months worth of work to get it up to speed with Current Linux… OpenBSD’s current drivers only support up to Haswell so would need to be updated.

Thier radeon support is even worse, and doesn’t support much after maybe the initial southern islands cards.

That said it may be the best starting point… as it is relatively clean according to waddlesplash unlike FreeBSD’s hackfest that is up to date relative to Linux 4.17.

It is likely that were would be little to no performance hit, if waddlesplash doesn’t interfere too much with the memory allocation routines in libdrm… however that is one source of ugliness. If he does… well I don’t know for sure but it would probably take some perf hit. And yes most of the compat layer would be compiled to native calls.

Haiku’s App server could be modified to act as a wayland compositor etc… but that’s another thing completely as it is the 3d driver will probably just write into a graphics context on the screen without modifying the app server much if at all.

I would also caution that sometimes code is ugly for a reason, either maintainability’s sake or for performance reasons, the Linux code itself is a pretty active codebase so ugliness there is unlikely to be without reason if it is in part of the code that has been around awhile… also they do have minimum standards before letting the code in at all.

Also while I’m at it I’ll note that Linux 4.20 has converted all the southern islands and up drivers to use the DC codepath in the radeon driver… which is probably good new and also means a more functional driver.


#46

Fair enough, I’ll just have to wait.

I’m also going to see if Apple has any documentation about their Metal API. To be forward thinking, I would like to implement some sort of linux DRI/DRM compatible infrastructure that can utilize Vulkan and in the same way that Apple uses Metal for drawing their UI. I just have no idea how it would work.


#47

Not sure I follow what you are saying? Do you mean modifying the app server to render with Vulkan?

Looking at what Mozilla’s WebRender does and how it works might be a place to start? I’m not sure how much would be applicable though. There are probably also differences in what is a sane design in Rust vs C++ also as used in Haiku.


#48

Actually the existing Media Kit is quite well designed to allow hardware assisted decoding. After all, hardware mpeg decoders were already a thing in BeOS days.

But we will probably implement something we can plug ffmpeg onto, as they have some code to decide wether to use the hardware or wether it’s too buggy, depending on the codec, bitrate, etc.


#49

Well FFMPEG already supports VA-API… maybe that will just work if libva is ported and the hardware support exists once the driver is up and going? There are also VDPAU wrappers in both directions both as backend and frontend.

VLC and mplayer woudl also benefit… since they support VAAPI.

https://trac.ffmpeg.org/wiki/HWAccelIntro


#50

As I understand it, MacOS uses Metal or Metal2 to render the GUI in MacOS, and can also use OpenGL for other graphical applications. Metal is similar to Vulkan in that it is a language with less abstraction, making it more efficient but harder to use. This is how Apple improved performance of their UI on older hardware. To be forward thinking and also to improve efficiency and responsiveness, we could port pieces of Linux’s DRI in addition to its DRM so we can copy how it uses Vulkan to interface programs with the GPU driver. We would need to find where to replace X with app_server and media_server in the DRI. Then we could render the desktop GUI with Vulkan and use OpenGL for other graphical applications. Does that sound reasonable?


#51

really mc-loving this conversation/thread, but don’t we need hardware accell 2d before even thinking about 3d?

anyways, onwards and upwards! :smiley:


#52

You should almost certainly ignore X… just look at Wayland. X is basically completely depreciated and in matinance mode. Wayland is a much thinner display server optimized to run on DRM/DRI. It can also be software rendered at respecable speeds depending on what you are trying to render not as fast directly rendering the BeAPI in software though I imagine.

Basically Haiku could implement the app_server as a wayland compositor… and the BeAPI as a wayland toolkit Wayland is alot more like what BeOS developers might have come up with for accelerated graphics than X11… except for it’s implementation being written in C instead of C++.

QT and GTK and SDL are already ported to Wayland… so it would probably be more of a step forward than a step back though it would be sort of an orthogal move potentially discarding alot of the QT port work. I think this would be more of an R2 project than for R1… as it would be a major overhaul of the app_server.

It seems like it would be a good idea to me but I’m not sure what the Haiku developer’s take is on this… I would say that regardless whatever Haiku ends up doing for accelerated GUI is more lilkely to be like wayland than X11.

https://wayland.freedesktop.org/


#53

2D hardware acceleration doesn’t really exist anymore… its just implemented via the 3D accelerator … it hasn’t really existed for over 10 years.


#54

Lol thx for the education :smiley:
ID love some 2D acceleration on my desktop :blush:


#55

Actually the app_server design is a lot closer to X11 than to Wayland. Except we use it as intended, whereas in Linux people really switched to client side rendering and don’t need much of what X11 provides anymore. Hence the replacement with Wayland. It’s probably not the way we are going to take.


#56

We’ll the reason they switched is X11 wasn’t providing anything of value… anyone implementing a hardware accelerated system is going to come to similar conclusions. Even without hardware acceleration modern toolkit’s just blast bitmaps onto the screen… this is already happening on Haiku with QT.

Even remoting support is better done these days in other ways than having a network transparent protocol (RDP, spice, VNC etc…). Haiku is already running


#57

We have server side drawing and network transparency and they work a lot better in our case because they are actually used. I ran X11 over the network at school and it was a pleasant experience when running apps designed for it (cde, nedit, …). Not so much with Qt or gtk2 apps


#58

Exactly, it only works well for the most trivial use cases that could be implemented directly via the server’s API. As soon as you are you display images, or do a custom control graphic etc… the advantage is completely gone. So you are better off optimizing for the common use case which is the exact opposite of the X11 model.

Frankly network transparency is friggin cool, but largely overrated at least when implemented as X11 does because it is nevery actually used as intended and when it is… it’s pretty laggy.


#59

No. Wayland is a set of standards for hardware-accelerated display servers. It basically has a hard dependency on OpenGL, as well as being “deceptively simple” (the specification does not even include a clipboard or window management procedures, you have to use XML-based extension APIs for these.) It is kind of a nightmare to get started with, the learning curve is impossibly steep, and there are wrapper libraries for those implementing compositors so they have “less work to do.” It’s a very weird ecosystem.

No, it would absolutely be a step back. We already have Qt and SDL, GTK needs to be ported but that is a separate issue.

More like it would completely abandon a lot of the things that make our app_server great, like the remote drawing side of things and the like.

Um, what? We already have BDirectWindow and friends which do most of the needed things here; X11 vs Wayland has nothing to with this issue. Implementing the userland side of graphics acceleration is not really going to be a huge issue, as far as I can tell at this point.

+100.

It would be nice if we could get Qt to use our native drawing APIs instead of doing its own drawing, but that won’t happen anytime soon, probably. (I think Qt actually does this on macOS in some scenarios? But I could be wrong…)

You should look at RDP again. They actually do draw-call forwarding much like Haiku does (all font rendering occurs on the client side, for instance); but they also implemented a very interesting “MP4 compression overlays” system for video, 3D graphics, or anything else that can’t be sent as a drawcall. So we are only moderately behind RDP on this one, and if we added overlay support in RemoteHWInterface / RemoteDesktop to use video compression for those views, too, we would be almost on par with RDP performance.

Wayland makes this kind of low-latency, low-data-usage remote desktop protocol functionally impossible, instead mandating a bitmap-based protocol like X11, which is one of its major downsides IMO. (Actually there is not even plans for a remote interface built-in last I checked.)

See above, Microsoft solved this in modern RDP using video compression overlays in addition to draw-call forwarding. So we can do the same, when we have time to implement it, that is.

TL;DR: Wayland is not so great, but it makes sense given the way the Linux desktop has been going in general, indeed. We have the opportunity to be much more sane and flexible, and we should stick with that.


#60

On implementing the BSD’s 3D graphic framework(s), let us review the current state of affairs on porting the AMDgpu and Intel drivers to Haiku? :smirk: