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.

Comments

Haiku hauku

[hawk]

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

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:No acceleration

[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:No acceleration

[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 cheaper, but they're no longer consuming significantly less power each generation. This means that it's increasingly cheap to put things on a die, but expensive to actually have them turned on at any given time. For most efficient die usage, you want to have most of your chip covered in accelerators for particular workloads that are powered down 90% of the time but provide significant performance increases when used.

There's nothing pure or noble about running code that is data-parallel, has little locality of reference, few branches, and predictable memory accesses on a processor that is optimised for sequential code that has a branch roughly every 7 instructions on average, has strong locality of reference, and relies on smallish working sets for good performance (the CPU) when there's a processor with a high-throughput streaming memory interface designed for branch-light workloads with lots of parallel cores (the GPU). It's just inefficient use of resources.

Re:Who knows

[rudy_wayne]

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

That's not easy to do.

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.

Awesome!

[viperidaenz]

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

Re:Start of a trend...

[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 after Palm bought it, and gutted the company (all they wanted was the IP) it kinda died slow and horribly.

I've checked in with the development of haiku, and other than re-creating the system in open-source, it seems fairly stagnant. I'm gonna be rooting for them, if they can get some modern chip set support, it could bring back relevance.

Re:Who knows

[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:Who knows

[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, if the start-time of a program is so long that it can have a splash-screen it is still in beta.
There is no reason for that. You don't need to load a gazillion small files, you don't need to initialize a bunch of data.
Everything can be cached and much can be loaded in the background.

Modern systems shouldn't have a worse response time than systems from the 90's.