Slashdot Mirror

← Back to Stories (view on slashdot.org)

Haiku Gains Support For Current Radeon HD Cards

Posted by timothy on from the old-and-new-together dept.

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.

9 of 70 comments (clear)

  1. Haiku hauku by hawk · · Score: 3, Funny

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

  2. No acceleration by Anonymous Coward · · Score: 5, Informative

    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.

  3. Re:Who knows by rudy_wayne · · Score: 4, Funny

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

    That's not easy to do.

  4. BeOS kicked butt, give Haiku a break! by Anonymous Coward · · Score: 3, Insightful

    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 .

    1. Re:BeOS kicked butt, give Haiku a break! by cide1 · · Score: 5, Interesting

      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.

      --
      -- the computer doesn't want any beer, no matter how much you think it does. NEVER, EVER feed your computer beer.
    2. Re:BeOS kicked butt, give Haiku a break! by TheRaven64 · · Score: 3, Interesting

      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.

      --
      I am TheRaven on Soylent News
  5. Awesome! by viperidaenz · · Score: 4, Funny

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

  6. Re:Who knows by jones_supa · · Score: 3, Interesting

    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.

  7. Re:Who knows by Anonymous Coward · · Score: 3, Interesting

    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.