Plans for 3D acceleration

Development OS
21

Now,that depends (as you know) on a few things. Let’s just compare games like Neverball/NeverPutt versus
the Microcosm screensaver. You can play Neverball quite well even on a typical Hauku x86 laptop, but Microcosm requires a bit more muscle (aka HW-acceleration). Billard3D is ‘playable’ but still requires some HW-acceleration for smoothness.

As for drivers, you can have a OpenGL 4.x driver that fallbacks if the HW’s firmware doesn’t support a OpenGL feature. That is how you can have a unified OpenGL 4.6 driver for legacy hardware which can do software rendering if the hardware has limited features/no acceleration. OpenGL is all software - whether in hardware for acceleration or not. It is developed more like a client/server model just in driver/library (API) fashion.
2D graphics acceleration relates to this as well.

You’ll notice this when you see messages like “your hardware is too old for that…” or “your hardware is mighty, but your driver is weak - upgrade your driver”.

22

Nope, not so, The software drivers do not implement anything greater than OpenGL 3.3 full stop. See here: https://mesamatrix.net/

There are some cases were features are implemented with fallbacks in the hardware driver via emulation but that has very little to do with the software drivers and the code is still generally running on the GPU not falling back to the CPU renderer. The GPU still has to be able to support the feature most of the way… so you can have things like 64 bit float support on GPUs that only really support 32bit… but you won’t see entire feature sets emulated because it doesn’t make sense.

All the applications you mention are pretty old… probably opengl 2.1 or older which isn’t what I was talking about at all, given a fast CPU LLVMpipe can probably run all of those well.

23

Continuing the conversiation here. Just some thoughts…

You mentioned FreeBSD’s driver layer is messy and that you are considering OpenBSD’s.

I’d ask you to reconsider that for several reasons, OpenBSD’s layer is doing what FreeBSD used to do. Attemt to rewrite the Linux layer completely from scratch… which is a very slow way to go about things an they have to wait month to years to get new cards added. The newest cards they even list are MULLINS based APUs which are circa 2014. Even the Intel drm is lagging quite a bit. In other words thier DRM layer relatively stagnate. FreeBSD actually abandoned doing this as it was a waste of time and effort.

You’re far better off with something that is a little messy but works and has lots of testing… FreeBSD has alot more users than NetBSD and OpenBSD combined, and this time around are trying to leave the Linux code as intact as possible. Which means updating it is less work. So while the code may be messier it is probably more maintainable.

24

Yes, because they don’t have a ton of time to work on it themselves. It’s really not so much work, but it is work.

And FreeBSD’s layer is of very low quality, I’m told, and despite being older, OpenBSD’s is significantly more reliable when it does work.

It’s not a little messy, it will be very messy. And as noted above, I’ve heard from plenty of users that it doesn’t work "as expected.

In terms of server users, maybe; in terms of desktop users, absolutely not. Most of the FreeBSD developers don’t run FreeBSD as a “desktop OS”, apparently; OpenBSD eats more of their own dog food by a wide margin.

My experiences with the WiFi stack back that up, from early testing of the 11.1 Intel WiFi drivers, I and some other users ran into 3 chipsets that didn’t work but had trivial 1-2 line fixes. In other words, in one week of usage on Haiku nightlies, we found and fixed bugs the FreeBSD developers hadn’t heard of in multiple months of production releases!

Except the FreeBSD compatibility layer is such a huge hack that it really isn’t more maintainable at all; It seems that FreeBSD had tried to “BSD-ize” the drivers in their first attempt, which was probably what was taking them so long. OpenBSD seems to have taken a less expansive approach here.

There’s also AROS, which seems to have found some strange hybrid way of porting the drivers, which I don’t know much about and probably should investigate further. At first glance, it seems they ripped out a lot of stuff, so I’m not even sure how it still works or what features they removed.

If we ever do go the “Linux compatibility layer” route, it’ll probably be a Haiku-native one; but Linux’s APIs are just so ridiculous here that it’d be the last solution, probably.

1 Like
25

Perhaps that is the case hmm.

It is still is rather concerning that OpenBSD doesn’t even have the man power to update thier drm though, nor to even update thier changelog for several releases. They seem to have alienated alot of people recently for a vareity of reasons. And like I said I question if it is even worth porting a driver that only supports hardware that is 4+ years old in the grand scheme of things… if you do port it it certainly needs to be synced with the current Linux DRM to be worthwhile which will be a lot of work. Looking a little closer it looks like thier Intel driver is OK, however thier radeon drm is woefully out of date it doesn’t even support GCN based cards at all… and it’s by far the more important one for high performance graphics.

The radeondrm driver from OpenBSD I’d consider mostly unfixable… as it is ancient… it doesn’t even support radeon southern islands and later in other words it’s not just 4 years out of date it’s nearly 8 years out of date. And of course it is stable… nobody has touched it to upgrade it’s features in eons!

If the FreeBSD driver is ugly clean it up and fix it’s bugs… at least there are people actively working on making it better. Also I’d suggest you consider that part of the reason the FreeBSD driver is unstable is that the Linux driver is also unstable on newer cards so you could be seeing people just complaining about known issues… it ususally takes a few releases before the bugs get worked out… just like Haiku has bugs because it is being actively developed that is the nature of an active project.

Looking here https://github.com/FreeBSDDesktop/kms-drm/issues/69
drm-kmod is what you want to port , and additionally drm1 drm2 if you want older cards also. OpenBSD really only has the equivalent of DRM1 an DRM2… which for someone buying a new computer are completely irrelevant.

26

Huh? It looks like there was a large OpenBSD DRM upgrade in April.

???

The Intel DRM driver in FreeBSD supports through Kaby Lake (January 2017), so that’s only 1.5 years old, not 4? And it sounds like that upgrade wasn’t too bad from reading the mailing lists, so future ones won’t be either, probably.

Huh? No, it was upgraded in April from being based on Linux 3.8 to Linux 4.4, which added support through “Mullins” APUs and “Hawaii” GPUs, which are Southern Islands / Sea Islands from ~2013; so just under 5 years out of date, not 8.

If we had any number (> 0) of people employed to work on this stuff, then maybe that’d be feasible. But it’s just not really…

As noted above, OpenBSD’s approach does not really follow the “DRM1/DRM2/KMOD” split, and supports chipsets from all three of those, AFAICT.

27

Oh, additionally: I don’t expect that merges of newer code would be amazingly difficult, from reading OpenBSD’s commit logs for the 3.8 -> 4.4 merge. But we’ll see, I guess.

28

Yeah hopefully not… however there weren’t alot of changes between 3.8 and 4.4 that I remember. 4.4 to now has some huge changes… because of Fiji, Polaris and Vega. It might be worth looking at what the diff is between current libdrm and 4.4 before going down that path just to be on the safe side. Southern Islands GPUs don’t have all that many changes to the display hardware just the core from what I remember… most of those changes occured before then so were already supported.

Linux 4.4 is 16 releases behind… and they only got updated to that in April sigh. It only suppirts the earliest GCN cards and probably buggily at that since Linux support for those wasn’t really mature then either though is quite stable now.

So, perhaps you can clarify my understanding of how haiku does things, so you had 2 implementations of drm do you think they could coexist and be loaded by the system at the same time eg if a user had 2 video cards supported by different versions? Using OpenBSD’s more stable drm for older hardware while supporting FreeBSD on more bleeding edge stuff might work… and oviously you should work on whichever you deem better after all you’re the one motivavted to do it :slight_smile: Honestly I found your comment earlier supprising which is why I’ve asked.

Also KabyLake as been out seens Q2 2016 so it’s more lilke 3+ years. I was mainly talking about radeon though as thier GPUs are more interesting my 4 year comment was a bit off and I revised it to 8 years uppon inspection of what openbsd’s librm supports… and certainly even more so now that they have desktop and viable mobile versions as well. While Intel only has mobile. Linux 4.4 = Jan 2016 so nearly 3 years ago.

29

Wouldn’t OpenBSD’s policy of “No binary blobs allowed” be an issue? It is fine for Intel and AMD GPUs, but it would basically exclude NVIDIA support from ever happening. That would be a shame, considering their dominant market position and the fact that they use a unified driver across four OSes (Windows, macOS, Linux, FreeBSD) means that all (more or less) have feature parity. The NVIDIA blob only officially supports (if I recall correctly) FreeBSD since that’s where most of the BSD testing takes place; OpenBSD doesn’t really test against it since it is closed source.

Perhaps taking a look at DragonflyBSD may be an option here?

30

Probably not. I don’t believe Linux can do this either.

That would be double the work to get it to run, which I’m, uh, not really interested in spending; not to mention the part where it will be very difficult to maintain and debug a compatibility-layer-on-compatibility-layer.

In the long term, a more robust LinuxKPI-on-Haiku wrapper may be the way to go; but this will be a ton of work, and so going with OpenBSD’s code for now seems to make much more sense.

It shipped to OEMs in Q2 2016, but desktop chips did not really hit the market till January 2017, I believe?

This policy applies to drivers only, not to firmware binaries; they’ve shipped firmware for WiFi chips and radeon hardware for a long time now.

NVIDIA support would come from nouveau if/when it happens, probably; NVIDIA’s proprietary driver is, well, proprietary, and they are not going to just suddenly port it to Haiku without some real motivation to do so.

Hmm, I thought DFBSD was doing something like what FreeBSD did; but indeed it appears they have an approach similar to FreeBSD’s but with a moderate compatibility layer, not the full-blown one that FreeBSD went with. I’ll take a look, I guess.

31

I wasn’t implying that you would maintain both compat layers I was assuming you’d want to work on whichever you felt best… but I might poke around the FreeBSD one though I doubt I’d get it working. I gues whichever one ends up being the one used doesn’t matter so much if it ends up being rewritten over time anyway…

Suffice to say they could probabably be loaded completely separately but not at the same time…

32

Suffice to say they could probabably be loaded completely separately but not at the same time…

Would it be possible to have Haiku auto-detect the GPUs at boot and enable the appropriate compat layer accordingly?

33

Anything is possible but I’d hazard a guess and say no. You’d really only one on drm layer installed on a system if they can’t coexist at the same time.

34

In that case, could the autodetection be done during the installation of Haiku? Installer would install the appropriate DRM layer based on the detected hardware.

35

We’ll cross that bridge if it ever even exists, it probably won’t… untill then it’s pointless to think much about it.

Probably give it a good month or so and waddlesplash will have a much better idea of where he’s going with this.

36

Why wouldnt they? They are just kernel modules and probably stuff statically linked into drivers, I’m fairly sure we wouldn’t get into too much problems getting them to load dynamically, and possibly even run side by side.

3 Likes
37

Right. The issue is just maintaining two compatibility layers, not one. As I said above, porting OpenBSD’s drivers may be the easiest solution to start with, and then in the long-term we may add a native LinuxDRM compatibility layer.

1 Like
38

I think, in 3D support, Haiku must go in the new more efficient way (to attract developers and users), if is there one. Is there a point in copying Linux or BSD in this? Neither of them are favorites in this area.

39

Which should be faster: building a bridge from an existing design, or building a bridge without ever having seen a bridge before? (^_^)

1 Like
40

Situation: bridges already exists (many), you must build new bridge beside others. That new bridge must be better in some way to attract users of that new bridge.
Also you must consider environment and materials which you will use for building.