Haiku Now Has Experimental 3D Acceleration

The RX/R designation doesn't actually say much about the underlying architecture, Polaris is GCN 4, while HD 7000 is ... a mixture. Most HD 7000 cards are first gen GCN, though some are TeraScale 1/2, which would required very different driver support.

I guess it doesn't "matter" to consumers buying a product, but it is unfortunate how confusing the naming schemes are versus the underlying architecture. The R9/R8 cards were similarly a mixture of GCN 1, 2, 3, and even TeraScale.

(similarly, the RX 5xx/4xx series has GCN 1 and GCN 3 cards mixed in, in addition to the actual GCN 4 chips)

Thanks, I’m really dabbling in the AMD nomenclature.

Trying to discern if my gpu is better supported by radeon or amdgpu gives me headaches.

If you can so consistently reproduce kernel panics, it would be good to open a ticket. However, that has been less and less of a problem in recent years, and a lot more panics were squashed in the past few months, especially USB related ones. So you might try a nightly build and see if things are improved; if not, please do open a ticket.

As usual it's a matter of what you're trying to do and how closely it matches the things the devs are trying to do. My only real attempt to use it lately was on an old eeePC I only really wanted to use for remoting into my home Windows PC and I ran into a bunch of issues with the only working RDP client (commandline-run FreeRDP). Waddlesplash even had to pick up on a post of mine here on HN and take it upon themselves to update FreeRDP to get to that point. It functions, but is seemingly unable to resize or even go fullscreen despite specifying the relevant commandline arguments, which on the tiny monitor is a problem because it leaves me forcing it to run in a less-than-fullscreen resolution that accommodates the title tab and moving it to the top-left corner.

Personally, I am not a fan of the reliance on ported-from-unix packages. Especially considering that there is currently no autoremove for the mountains of dependencies that they bring with them. If Haiku had containerization this could be more easily mitigated, but as far as I'm aware it doesn't.

> Perhaps I could try running it in a VM, but why not use the outside OS at that point?

My feeling as well.

The thing that i always found puzzling with Qt, Java, etc on Haiku is that if you are going to rely on those instead of taking advantage of Haiku's uniqueness and integrated UI approach, then why not just run Linux with a BeOS-like theme?

Talking about supported hardware, I always select hardware that will run the software I want, not the other way around. When I build my desktop PC last year, it was all AMD hardware. Haiku works great on it, and with X512’s vulkan driver, I’ll even have 3D acceleration. I’m buying a laptop in 2 months, again, it will be all AMD hardware. And Haiku will run great on it. As will Linux.

I think that perhaps pushing for drivers in userspace wherever possible would improve this situation significantly. Userspace drivers for Linux would still be built with various Linuxisms, but at least you get all the kernel specific bits disentangled which improves portability a lot and makes writing compatibility layers for other operating systems more feasible.

You're 100% correct. I'll add to that the fact that GPL drivers can't be used as-is in non-GPL kernels. It's a one-way street leading to Linux.

This issue is not the fault of Linux but manufactures who REFUSE to release datasheets and programming manuals. Instead these manufactures "embrace" Linux (Which to them == open source) by writing undocumented drivers for undocumented hardware. So OS devs play reverse engineer and cargo cult the undocumented Linux driver bit twiddling dance routines into their driver code and pray it works.

The alternative would be to have drivers that work against a fixed common ABI (or API, if you just want source level compatibility). Good lucking trying to get operating systems to agree on this ABI.

Linux is constantly breaking these internal APIs for a reason: to keep adding new (hardware) features, while preventing each driver from implementing large amounts of would-be-common code each in their own non-standard and slightly broken way.

That's why some types of drivers tend to be huge on Windows: they're offering functionality that the (relatively stable) driver API doesn't support. This approach requires drivers with user interfaces. Good luck doing that cross-platform.

What you're asking for is highly impractical.

It's a bit strange you blame this on Linux, instead of e.g. Microsoft.

The PC (more or less accidentally) started out as standardized hardware. Everyone could write an OS for it. Then things like sound cards, network cards, advanced video were added on top, but standardization here was incomplete to nonexistent.

All kinds if programs had drivers, e.g. games for sound cards etc. As an example, I had to install a printer driver in wordperfect 5.1, a word processor under DOS.

Windows centralized these drivers. Games could talk to the sound API. Word processors to the printer API. Hardware vendors could stop writing drivers forceach program. But note a fundamental shift here: No more standard hardware spec, only a standard driver spec.

Microsoft didn't ask for this, but didn't fight it too hard either. History accidentally gave them a moat, and they liked it. They could easily have pushed hardware specs harder, like they did for USB with HID and Mass Storage.

There is no sane need for individual printer driver, for example. A standard way to push a bitmap, to read some specs( DPI), to control buttons, toner levels and lights gets you mostly there. We would have 1 stable high quality printer driver for each OS instead of the crappy mess we have now. In fact, IPP getsvus partially there. But you need a big player pushing for it, and Microsoft has everyone working for only them right now, so why would they change anything.

Linux wrote its own drivers until it got big enough to get some love from some big hardware vendors. But I see no way for it to push hardware standardization.

And it's so much easier to write several hundreds of drivers for the Haiku kernel instead of one 'desktop user' scheduler for Linux.. /S

So I guess just like I did with DOS, I should design my own "FBI" faux login screen in Lazarus, or some other RAD equivalent of QuickBasic? :-)

You can want a lock screen (optionally paired with data encryption) even on a single user machine for privacy reasons.

As both a Haiku and RPi fan, I agree they would be a great combination. RiscOS has run on the Pi since the first model, and if that combination's performance is anything to go by, Haiku would likely run circles around Linux on Pis.

The problem, as others have said, is the lack of dedicated manpower. This is one of those situations where I wish I was a developer, I'd dive right in and try to get Haiku to daily-driver stability on the platform. There is work being done on porting to ARM already, and my hope is that as the X86/64 platform matures, focus can shift to ARM and the Pi specifically.

I think its very disingenuous to call the lack of hardware support a "missed opportunity". There is a Pi port in progress but the Pi as a platform outside of Linux is a mess. Its not a well documented SoC and does weird stuff like boot via the GPU using a binary blob and other proprietary crap. It also has a different DMA architecture so drivers developed originally for PC hardware need to be modified. Ironically its a not very open source friendly SoC.