Forgot your password?
typodupeerror
Graphics Operating Systems Be Open Source

Haiku Gains Support For Current Radeon HD Cards 70

Posted by timothy
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.
This discussion has been archived. No new comments can be posted.

Haiku Gains Support For Current Radeon HD Cards

Comments Filter:
  • by cide1 (126814) on Sunday May 25, 2014 @10:22PM (#47090279) Homepage

    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:Who knows (Score:4, Interesting)

    by jones_supa (887896) on Sunday May 25, 2014 @11:26PM (#47090483)
    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 (Score:3, Interesting)

    by Anonymous Coward on Monday May 26, 2014 @04:32AM (#47091137)

    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.

  • by TheRaven64 (641858) on Monday May 26, 2014 @09:04AM (#47091813) Journal
    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.

In a consumer society there are inevitably two kinds of slaves: the prisoners of addiction and the prisoners of envy.

Working...