The graphics acceleration can of worms

I’m just a Haiku user, however looks like AMD is trying to refactor Mesa interaction with the Linux Kernel:

The discussion is intense and touch: performance, security, why only Wayland approach (BSD, android excluded), VR headsets, browsers, why relay on Linux’s ABI api and so on.
Very complex and a good reference point when a new user makes a complaint about why Haiku lacks GPU acceleration.
Even with all the money and resources, Amd & Intel developers have a difficult task making their drivers faster on Mesa.

1 Like

Mesa 21.2.0





It’s mesa package from my LOTE repo?

“mesa package from my LOTE repo”

I am using x86_64 hrev55306 -

If I load your repository the mesa package does not show up (others do), and if I download the hpkg it won’t install if I open the file in the installer (nothing happens when I click “install”. Are there any prerequesites that I may be missing?

This is a bug in HaikuDepot app. Once you added the repo you can install mesa using pkgman.


I, for one, would still very much like to see support for certain NVIDIA cards. I have a laptop with a Quadro FX 3700M (G92-series core), which is only supported by VESA under Haiku, and consequentially doesn’t perform nearly as well under Haiku as it does under Windows or Linux. At this point, that’s the only major issue preventing me from using Haiku more regularly.

design by committee often leass to issues like this.

To quote Marcus Aurelius

waste no more time arguing what a good man ought to be, be one.

much of the performance issue, is that, well, imho, linux graphics subsystems ate full of multiuser multi terminal kludges, before the code path optimization issues arise in discussion.b

haiku needs a bare metal approach, remove all abstraction and flow changes except those that are absolutely helpful and required.

i studied many graphics driver design docs, the amount of obviously duplicated work in translation, jit, ir, rendering pipeline, just ridiculous.v

the goal should be to build the eimplest pipeline from application to hardware.


You meant *nix, as all this true for every unix too.

And maybe limit it to 640x480x16 colors, as god intended?

It seems nobody cares about that at*nix front. What do you think what can be the reason?

Somehow people always comes up with problems where the simplest solution fails. Any idea to solve them?

1 Like

TempleOS tried to be the most open OS that has ever been and the author lived to regret the 640×480 comments when he found out that VESA modes went higher within standardized mechanisms. I’m not going to criticize his motives though. We may live to regret having depended on communist Chinese to supply our equipment before too long. That’s a can of worms for another thread, however.

Vulkan seems to solve many issues when used in conjunction with other backward compatibility mechanisms. It’s just a matter of getting to that point.


being as haiku and beos never had any aaa games etc, I say pick the cleanest, most elegant, simple performant api, probably vulkan,and support just that, If people want open gl and the wankery of wayland etc, let them deal with that on their end.



ANGLE plus the Magma subsystem of Google’s Fuchsia OS will get us OpenGL-ES on top of Vulkan. Getting OpenGL on top of OpenGL-ES can be done using GL4ES. The only thing heavy about it is that Magma isn’t done yet (nor is Fuchsia), and GL4ES (as well as Fuchsia) is geared toward handheld devices like the OpenPandora and single-board computers like the Raspberry Pi and others. That will make it simple and small with a minimal number of function calls to implement from the Zircon kernel, (100 function calls, ballpark range, for a complete Zircon kernel emulation layer), will hopefully be easier to implement than Linux drivers, hopefully. Might be a tougher call but at least it avoids X11 server and Wayland.

It’s simple but it isn’t finished yet so it’s hard to judge. Now does that all make sense? It’s where I was coming from if you missed my posts on the Fuchsia off-topic thread.

Since the licenses are generally compatible between them all, we just need everything else set up so we’re ready for it once the Magma code drops on AArch64 devices. Unfortunately, I haven’t looked at the code for some of those links and a lot can happen between now and then.

The idea that BeOS never had “aaa” games is not true, there were a few ported. The issue was more that BeOS was always 3 - 5 years behind the curve, because no one wanted to port anything to it because the user base was so small it was not financially viable - certain ports never saw the light of day because of this. I think Haiku will suffer the same fate for the same reasons.

I don’t play games, and when I do I tend to play retro games, so what Haiku can offer me is fine really. If I want to play something a little more modern, I probably go to my Xbox 360. For me, the modern graphics subsystem and 3D only matter for practical operations.

3-5 years BEHIND the curve? You forgot that the gaming industry didn’t write multithreaded code for 5-10 years AFTER the BeBox.

Well no. You have things like Unreal Tournament and Quake, I think neither came out at the time, and you had Corum 3 which did, and Worms Armageddon that I certainly played but I don’t know if it was released. But most of the time, there was no incentive, and these games were 3 or more years after original release.

Worms came out first on Amiga and was originally written in Blitz Basic. It had to be rewritten in C++ before it could be ported to other platforms.

Um… the original demo was possibly in Blitz basic, but the retail version was completely rewritten in C AFAIK.

Also we are talking about Worms Armageddon, which was released in 1999. I think the BeOS port came to light around 2001/2002 or so. That is when I saw it at any rate.

1 Like

The last running version of worms are from zeta timed, cpmpiled with the zeta specific library

1 Like

there is no historical need to preserve a graphic api or driver design, so, find the easiest graphics drivers, api, and support that now.

i still think is vulkan and AMD cards, giving the greatest opportunity to have a powerful performant graphics stack. iirc there are already open gl etc layers to go above vulkan


You do remember correctly. I linked ANGLE in an earlier post.

The gaming industry was already writing multithreaded code in the mid 90s. Not everything was run on PCs.

1 Like