Haiku Gains Support For Current Radeon HD Cards

As reported by Phoronix, the Haiku operating system "has added (untested) support for the newest AMD Radeon graphics cards to its open-source driver for the BeOS-compatible operating system." (Specifically, that support is for the "Mullins" and "Hawaii" graphics processors.) Impressive that this project keeps the BeOS flag raised and continues to modernize; Haiku has been around since 2001 — years longer than Be, Inc. itself lasted.

untested

[Anonymous Coward]

Not to take anything away from the folks working on Haiku, and not that I would ever accuse Phoronix of jumping the gun on a story *cough*, but I really don't think you can claim support for new hardware before someone has tried running the code.

Re:Who knows

[rudy_wayne]

I have to give them credit. Haiku is even more irrelevant than BeOS.

That's not easy to do.

Re:

[Anonymous Coward]

Amiga OS4 begs to differ !

Re:

[Lawrence_Bird]

Indeed - if anything, BSD's do much of what they claim in their FAQ that Linux does not.

At this point, it is hard to envision any OS displacing Windows/OSX/BSD/Linux without providing a radically different approach that allows users to do things not possible before

Re:

[Anonymous Coward]

It's a shame too, because BeOS was doing things that even modern OSes still can't do. I remember being able to run twenty or more video at the same time without lag or do in place driver updates without interrupting anything or requiring a reboot, all on a Pentium III 450MHz.

Re:

[jones_supa]

What made this difference? Was there something magical about the scheduler and/or the graphics stack?

Re:Who knows

[jones_supa]

Indeed. Man, a frame-accurate, fully responsive, low-latency OS would be a dream. Today we have various CPU schedulers, I/O schedulers, multiple CPU cores and SSDs thrown at it, but the results are still often quite subpar.

Re:

[Anonymous Coward]

If we want a similar feeling we will have to start to treat user interaction as realtime-critical. Not only is it necessary to fetch user input in a timely fashion, lost input events is non-acceptable bug, but it is also vital that any GUI or console output is processed at a higher priority than any generic calculation. Even network packetloss is preferable to unresponsiveness.
A situation where a process hogs the CPU so much that opening a console and killing it takes several seconds should never occur.

Also

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[TheRaven64]

The GUI toolkit made aggressive use of threading. This was good for latency, but not great for throughput because you ended up doing a lot of context switching. It was also quite hard to program, because you had to be very careful about synchonisation.

Re:

[Anonymous Coward]

Funny, because every BeOS developer I have ever talked to has said the opposite, that BeOS is a joy to code in.

And I can tell you right now that throughput was no problem. I ran Quake II, used Gobe Productive and have done realtime video editing without any throughput issues. In fact, BeOS is still used in a number of professional studios, specifically for video and audio editing.

Basically, you don't have a clue. You're talking about something you have never even used.

Re:

[TheRaven64]

Funny, because every BeOS developer I have ever talked to has said the opposite, that BeOS is a joy to code in.

Steve Jobs wasn't the only reason Apple decided to buy NeXT for ten times what Be was asking. The BeOS APIs were easy to use to write simple applications, but they had a sudden difficulty cliff. Your GUI application was a distributed system and most of the time this was fine because the parts were independent and events arrived at low enough rates that the user wouldn't notice if they were handled in the wrong order. Once you started getting complex MVC applications, the synchronisation requirements beca

Re:

[Rhys]

I'm going to go with something on the theory that after being put on a PC (single chip, with a large L2 cache) it got a free pass to do what it damn well pleased, since it'd been designed to run on a much slower multi-chip PPC solution, which gave up L2 cache entirely in order to have the second processor.

Re:

[fizzer06]

I saw a demo at the Dallas Infomart back in the day. Like you said, it was able to display several videos without any choppiness. No other OS I had seen could come close. I suspect that Haiku can't come close either.

Haiku hauku

[hawk]

Beos fails to sel
Asks too much for Apple sale
now just open source

Re:

[hawk]

You can't count to five!
So then why do i bother?
Best your name not known . . .

hawk

No acceleration

[Anonymous Coward]

Remember, no graphics (not "No modern Radeon HD graphics" or even "No Radeon graphics" but no graphics at all) in Haiku are hardware accelerated.

The ONLY acceleration they offer at all is YCbCr scalable overlays for video on old chipsets that still did that sort of thing, which obviously Radeon HD does not. No 3D, no compositing, no blit operations, everything is done in RAM and then the whole frame is copied to the framebuffer.

Of course today's CPUs are really fast. So long as you do simple 2D graphics or you have a really poky high-end CPU, Haiku can make this look pretty good despite not using virtually any of the transistors on your $200 graphics card.

Re:

[drinkypoo]

I see fools in this thread who ridiculously paint Haiku as not supporting 3D hardware, when the reality is they are fools unaware that such "acceleration" is a damn kludge:

Purists always whine about kludges, and they always get left in the dust by people willing to get the job done by the most expedient means. Intel has been working on replacing GPUs with CPUs for over a decade now (remember their various raytracers?) and they gave up and began integrating more powerful GPUs. Nobody agrees with you. Build a bridge and get over it. Coprocessors are here to stay.

Re:

[TheRaven64]

Please let me know where you work as a hardware designer so that I can make sure never to buy your company's products. There is a cycle between specialised and general purpose compute that has been through about half a dozen complete oscillations. If you're only aware of it moving in one direction, then you're not much of an enthusiast either - especially as you have it moving in the wrong direction.

If you want some further reading, look up 'dark silicon'. Transistors are still getting smaller and cheap

Start of a trend...

[Kittenman]

Yet another OS?
This plethora of systems
Adds to general mess

Re:

[sillybilly]

I like variety, though I've never used Haiku or BeOS, but heard good things about it, especially back when BeOS was still an active business, with some folks who put their heart into it, but was steamrolled into oblivion by monopolistic competition. It's kinda hard to resurrect a dead corpse and breathe new life into it. It feels like people trying to bring step-dancing from the 40's movies back into vogue today. It's not gonna fly very far in this modern age of half shaved heads and pierced clits and nostr

Re:

[Wing_Zero]

When i was in high school, I bought a copy of BeOS. I thought it was really cool. it flew on my k6 with a matrox video card. it came with cool demos like dragging videos onto a 3d cube and playback all sides. really i think it had much more polish than Linux or windows of the day visuals-wise (my opinion linux still drags behind on this). even today, a modern OS struggles to load itself from power off in under a minute, where BeOS loaded itself in under 15 seconds. I would have loved to see it survive, but

Re:

[Peter Kowalchuk-Reid]

What IP would they want badly enough to buy a whole company for? I can't find anything on this.

Re:

[ArcadeMan]

I heard it was 127.0.0.1

Re:

[jones_supa]

Actually it must have been 66.101.79.83... ;) (see what I did there?)

Re:

[jones_supa]

I like variety, though I've never used Haiku or BeOS, but heard good things about it

I do not like variety if it mostly just produces various unusable things.

Re:

[dugancent]

Monoculture is the death of innovation and invention.

Re:

[jones_supa]

Well, I guess there is a truth to that side too. I suspect that Microsoft finally made Windows so much better in the NT 6 series as Linux was getting "too good". On the other hand, I still think that the open source landscape is even too diverse. There's a lots of things which are essentially only slightly different from some other thing, providing only little innovation and mostly just causing duplicate work.

Re:

[sillybilly]

The open source movement is under extremely strict control by copperheads (all over the internet the term is either for a venomous snake, or for some party during the civil war, when the meaning should be undercover agent), pretending to look out for the interests of open source, but in reality making sure that it never gets usable or good enough, while allowing enough room for some new ideas that can be used in commercial software. Even the Linux "leaders" are preaching the virtues of the "cloud." Like how

Re:

[TheRaven64]

Fear of failure is the biggest obstacle to getting good results. If you can afford it, then having 10 teams go off and do things that will probably fail is a good way of finding the one path that has unexpected good results. The Haiku team isn't costing anyone anything (and their code is permissively licensed, so occasionally interesting bits end up in other systems). Even if it's a dead end, it's worth having someone check that it doesn't go anywhere - you never know, there might be some useful spin-off

Re:

[sillybilly]

Life evolves by mutations, and mutations mostly just produce various unusable things, but you yourself are just a whole bunch of lucky mutations starting from the very first bacteria that appeared on the surface of this planet, and so are all the other lifeforms around you, including bacteria, fish, birds, cats, dogs, chipmunks and earthworms.

Re:

[sillybilly]

Do a google image search on "still born mutation baby" to see mutations/evolution in action, and all the various unusable things it produces.

Looking through their screen grabs

[aussersterne]

some of the window management features seem interesting to me.

Why has nobody else implemented the Haiku version of tabs and the ability to "stitch" windows at borders? I can see convenient uses for those. Were these features in BeOS? (I never used it.)

BeOS kicked butt, give Haiku a break!

[Anonymous Coward]

Too bad a few of the late bloomers are quick to jump on her grave. Multimedia was it's strong suit, and way out ahead of any Linux distro at the time. Try that with Slak, Mandrake or Redhat 6.x .

Re:BeOS kicked butt, give Haiku a break!

[cide1]

On hardware from circa 2001, BeOS had an audio latency of about 3 msec from input to output. I don't know the x86 / x64 number, but in 2014 running on the best ARM hardware available, by default, the Linux scheduler runs every 10 msec, so audio latency of 40-80 msec is pretty common. In many applications, that is quite a significant difference. There are good reasons why Linux has this latency, but it is a question of optimizing for different use cases. BeOS had a laser focused use case of Desktop performance. Linux is used on servers, desktops, embedded, super computers, and all kinds of wierd places.

Re:BeOS kicked butt, give Haiku a break!

[TheRaven64]

Linux is hardly a sensible point of comparison, because the reliance on userspace sound daemons (low-latency in-kernel sound mixing would bloat the kernel, but a web server in the kernel is fine...) means that you end up needing a lot of round trips to get audio out. On FreeBSD, for example, the mixing happens in the kernel so if you really need low latency you can pin a process to a dedicated core and have it pushing things out very quickly. Most of the time, it's fine to keep the buffers filled and allow other processes to share the core.

Re:

[uvajed_ekil]

Yes, BeOS was interesting... like 15 years ago. Today, not so much. And by not so much I mean, "People actually use Haiku? Who? And WHY?" I could do most of what I need to do today on WIndows 3.11, but that doesn't mean it would be a good idea.

Re:

[ChunderDownunder]

As long as you're happy running an alpha browser on an alpha OS. Pardon me if I feel safer with respect to timely security updates on a mature platform.

How does a platform utilising llvmpipe for acceleration choke on full-HD HTML5 video and WebGL?

Does haiku provide touch input on par with modern environments such as KDE 5.x and Windows 8.1?

Re:

[angel'o'sphere]

Says a guy who obviously has no clue about operating systems.
Hint: a quick look shows end user systems are dominated by different window versions (which all are pretty useless if you are a power user and know real OSes), various Linux versions, to a lesser extend BSDs and finally Mac OS X.

Conclusion: there is plenty of room for alternating OSes.

Next time you tell us: there is only cone car company needed ... the 'problem car' is solved.

Another free hint: read about Hurd or Plan 9 and you see, there is plent

Re:

[Bill_the_Engineer]

I remember when people said the same thing about Linux. Boy have things changed.

Awesome!

[viperidaenz]

Open source OS nobody uses provides support for graphics acceleration hardware without any hardware graphics acceleration.

Awesome!

[kallisti5]

The radeon_hd work is mostly to provide reliable mode-setting and to enable the full range of resolutions on Radeon HD cards. There is talk of hardware rendering, howevever we need a pipeline to connect Mesa / Gallium to the card. DRM is very Linux centric. In a lot of ways our driver is cleaner than the Linux one, i've been careful to refacter quite a bit of messy code as I went. We're actually working with the Linux radeon developers to point out issues in the Linux kernel driver. Everyone wins.