Graphics card for Haiku


Maybe I’ve just picked a bad nightly to install – 51826. The desktop is not visible with original settings, videos are choppy, out of sync, even Webpositive and Qupzilla won’t run.


I doubt it’s the nightly, though I’d try a bit older one, since the current crop exhibits a rather annoying shutdown delay.

Blacklisting the radeon driver falls back to VESA and then it works for you? Then you may want to file a ticket at the bugtracker with your listdev and syslog.


Okay. Thanks for all the help.


It works in VESA but not well.


Ah, thank you for that reveal! Is one better than the other (swrast vs. llvmpipe), or just different ways of doing the same thing?


swrast is the older code that we still use for gcc2. It is a plain old interpreter so it is quite slow, and it is also not updated by the Mesa team anymore. llvmpipe is the replacement for it. It uses the llvm compiler to create code that can be executed by the CPU, so you can think of it as “software accelerated” 3D rendering. It is also able to use more CPU cores to perform more computations in the same time.


Nvidia GeForce 6xxx-Geforce 7950 GT are supported.
Nvidia Quadro FX 330 - Quadro FX 5500 are supported.
Radeon HD 2xxx-RX580 and Vega 56/64 cards and IGPs are supported (unless blacklisted).

Intel Graphics IGPs (Intel HD, UHD and Iris Graphics) are supported.


  1. Currently, any low-end Nvidia GeForce and Quadro cards work well with Haiku (i.e. in most cases).
  2. Nvidia Optimus-based laptops will have issues.


Would be great to get this in a formal and easily accessible hardware support matrix :wink:


There used to be a BeOS/Haiku hardware compatibility list on certain Haiku-related websites that went offline sometime during the time period of (in)famous switch to the Package Manager system. I kind of remember that there was even a wiki section dedicated to the supported and unsupported hardware.


Do you mean this one?


The problem with a formal approach is we can only report “we have some code for this and it’s supposed to work”. No matter how hard you try, there are many components involved and even when two devices have the same PCI IDs, one may work and the other won’t, for example because the display is wired differently on otherwise identical graphic cards.

This is what you can find in the “hardware info” pages on the development wiki, which miqlas linked already.

For a more definitive answer on exact hardware models, one has to resort to testing from the community. Besly has been collecting some data, and during GCI we got a test web interface running, so there is only a little work left to plug these two together, I guess. Would be great if anyone could handle this.


I’ve tried creating two hardware lists now on both the old and new Land of the Leaves sites. I’ve given up until Haiku reaches Beta 1, because the target (the Nightly branch) keeps moving, and what might be accurate a few months later will have changed. Once the Beta is out, I’ll test several machines but for now, it’s all awaiting Beta.


Bad news for you: drivers and hardware support are probably something we wont freeze in the beta. So it will be as much of a moving target as it is now.
Moreover, to me as a developer, the most valuable information in such a database would be “worked on hrevxxx, stopped working in hrevyyy”. This makes it a lot easier to look for what changed and find/fix the regression


Maybe some application like “Report Your Hardware” or like inside Haiku would help. The application will collect the key hardware IDs and open a dialog which asks several questions about what works and what doesn’t work (checkbox). On the remote side of application, where the report goes, it will be listed as following: hardware piece ID - number of positive reports - number of negative reports. It is still not very clear how to report negatively, when the report application cannot start. Besides the numbers it is a good idea to have a timeline of the positive / negative reports to see the progress. This information presented in some online resource can greatly simplify watching:

  1. What hardware are most probably supported and stable with Haiku;
  2. What hardware is most used by Haiku users and needs more attention;
  3. What hardware support is missing and most needed.

Of course, Haiku users are urged to report both positive and negative working on install / update when they see some progress / regression.


There already is one. The BeSLY SAT (System Analysis Tool) will help you collect the data and report what works/what doesn’t. But no one uses it to fill in the database, and as a result no one is motivated to plug the mostly empty database to a web frontend. And people complain that this and that is needed.


What would help is to promote this tool. I certainly did not know about it and most probably all affected user neither. People can’t use what they don’t know about.


I saw awhile ago, but I usually run Haiku x86_64 so need a gcc5 package for it.

BeSly System Analysis Tool (0.3.6-2, System and Utilities):


Haiku Depot:!/?bcguid=bc1-NFPK&repos=besly,fatelk,clasqm,haikuports&arch=x86_gcc2&viewcrttyp=ALL&srchexpr=besly

Note: I only see a package for Haiku x86_gcc2 at the moment.


This is right, I only create a x86 version, because no 64 bit version of haiku are available this time and I does not know about a yab version for 64bit is available to build on it.

If there is a 64bit version available, you can try to run the app from:


@lelldorin - Ok. The tool works fine and I uploaded info into the database. Yab 64-bit packages
are provided in Haiku Depot, so will need a yabbesly package (gcc5, 64-bit) eventually for more users to adopt it

I think a note that any video card/IGP ‘compliant’ to VESA standards is supported. So, if
a user has a Nvidia GeForce 1080Ti or AMD Radeon X1950 XTX video card and wants to use Haiku - it ‘should’ work using the VESA driver.


It depends on your notion of “supported”. I don’t consider it supported if you can’t get your display native resolution to work, and unfortunately it is often not the case with VESA (not our fault, but lazyness from the VESA BIOS provider/integrator).