Hardware graphics acceleration port idea

Many people says that introducing hardware graphics acceleration (OpenGL etc.) is difficult, but actually implementing basic support may be not so.

Hardware accelerated rendering can be done on offscreen GPU surface and then copied to CPU memory and displayed by BView::DrawBitmap. No major changes in Interface Kit / app_server is required. Compositing is also not required. This solution should work faster than software rendering.

Things need to be done:

  1. Port kernel mode DRM (direct rendering manager) as Haiku kernel module. Existing attempts: https://github.com/hamishm/haiku-drm, https://review.haiku-os.org/c/haiku/+/435, https://www.haiku-os.org/blog/vivek/.
  2. Adjust mode setting/accelerant.
  3. Port user mode library for interfacing to kernel module libdrm (https://gitlab.freedesktop.org/mesa/drm).
  4. Enable build of DRM in Mesa port.
  5. Adjust HGL to allocate GPU surfaces and copy it to BBitmap.

I am not familiar with internals of videocard hardware or kernel mode video drivers, but can do userland (Interface Kit/Mesa HGL) things.


I have a long-standing offer to tackle the kernel/drivers side of things, if someone else will take care of the app_server & Mesa side of things, but nobody has taken me up on it yet. So if you’re game… :slight_smile:

The “accelerants” model already has support for hardware framebuffers-as-windows (BDirectWindow), and it is rather flexible (although, the accelerants could use a refactor anyway; they are very much designed around 90s-style video cards, and I think they even get instantiated into apps and not only app_server…)

Refactoring the accelerants, and then app_server to get multi-monitor support would be a good first step here, as the Intel and Radeon drivers already support multi-monitor, but only “mirror” mode as app_server does not support multiple displays.

The existing attempts are extremely basic and don’t get very far.

For my own research, I think there are 3 major possible approaches to porting the KMS-DRM components:

  1. Port the ones from DragonFlyBSD. These mostly keep up with upstream, and use the BSD-style PCI/DMA/etc. APIs that we already have implemented for WiFi support. (Probably the least amount of time required of the 3.)
  2. Port the ones from Linux directly (what the ones you have linked to started doing) via a new compatibility layer. This will probably be more robust in the long run than #1, but will also take more time and trial’n’error to get right.
  3. Port the ones from Linux … as user-space drivers. This may be the “best” solution, actually, though it will require some kind of wrapper in kernel-space for interrupts (PCI mappings may already be workable via /dev/mem.) There really is no good reason for a lot of this code to be in the kernel, Linux only put it there because they don’t ship userspace components with the kernel.

Probably #1 is the approach worth taking, though #3 may be worth consideration at least, or maybe worth revisiting later.


Yes, BWindowScreen allows apps to directly call the accelerant hooks and do scrolling, etc. This could be useful for games to have precise synchronization with the graphics card in the 2D world (but not so much in 3D).

The old radeon driver does support multiple displays. The Screen preferences allows you to set different resolutions for each display and set their relative positions (but I don’t remember if our version still does this or if the Radeon driver used to come with a patched RadeonScreen). This even works in BeOS. The remaining problem is that the driver then tells app_server that this is just one single large display, and it’s not really possible to use BScreen to target a specific display. But it’s a start, and there is already a patch on Gerrit adding the screen_id to all accelerant hooks to solve this (at the cost of losing BeOS compatibility, but we may be able to fix that by putting the parameter at the end and abusing our knowledge of x86 calling conventions, knowing it woudl safely be ignored by old drivers).


Hi this sounds very interesting. I could maybe give some spare time to help out a bit. But someone would need to direct me a bit. So maybe we can get some people together to get it done.


There is also OpenCL support to consider that may not impede getting graphics working too much. Also I think a long time ago it was mentioned that perhaps one of the video acceleration APIs could be hooked up on Haiku. But yeah one thing at a time I guess… I thinking OpenCL could actually occur before graphics acceleration though since there is less going on there.

If either of you needs hardware let me know.

Some time ago I tried to get multiple displays working with a supported Radeon card. I couldn’t get it to work. It may require some extra work.

It worked last time I booted Haiku on my 2003 machine. You need one of the old Radeons (7000/VE or 9250) from 20 years ago. The new radeon_hd driver does not support multiple displays (yet).

1 Like

Is it possible to make at least experimental accelerant API to enumerate displays and getting front buffer of specific display? I can try to integrate it to app_server and Interface Kit.

Related tickets: https://dev.haiku-os.org/ticket/10486, https://dev.haiku-os.org/ticket/8612.

1 Like

The starting point is https://review.haiku-os.org/c/haiku/+/329 there are open questions in the comments.

And also the hacks from the old Radeon driver with RADEON_MODE_MULTIMON_REQUEST/REPLY (https://git.haiku-os.org/haiku/tree/headers/private/graphics/radeon/accelerant_ext.h) which was done this way because the driver was also used on BeOS and changing the hooks there wasn’t possible.


Love it… another if I can help with any hardware.

I have a variation of the Radeon 9800 in my Tyan Thunder 2 ATX these days… I should give it a go also.

1 Like

If hardware testing for anything is needed I have a massive collection of graphics cards from the mid 90s up of about every company that was worth mentioning, and even some that are rather fringe. I have some strange obsession with collecting interesting and old graphics cards, so far I have about 4 large boxes full :neutral_face:



Please remember that the nVidia driver I wrote, and also the Matrox driver do support dualhead modes: these use Mark Watson’s preference app, but for the nVidia driver I also added partial support for Thomas his method (Thomas and I had long night-time conversations at BeGeistert back in the day :wink: )

The nVidia driver supports TNT1 upto/including GeForce 7900 or so… And of course I have a lot of them still a few meters away from where I am sitting writing this message :slight_smile:

Oh, PS:


Think it ran pretty well on BeOS/ZETA back then :slight_smile: