Opened 6 years ago

Last modified 5 years ago

#9919 new enhancement

Haiku needs a hardware rendering pipeline / API for Mesa3D

Reported by: kallisti5 Owned by: kallisti5
Priority: normal Milestone: Unscheduled
Component: Kits/OpenGL Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by kallisti5)

A rendering pipeline needs to be created to provide hardware 3D access to Mesa.

Such a pipeline would need to fill the following needs:

  • Provide a method of sending rendering data from Mesa3D to the graphic card accelerants.
  • Be stable enabling minimal upstream changes to Mesa3D.
  • Require minimal ring buffer communications in the acc
  • Be "future proof" to prevent the need for another redesign.

The wayland project is a nice shakeup to the Mesa3D / X11 ecosystem. We may be able to ride on a new rendering pipeline if the wayland team creates one. For the moment though Wayland still relys on X11 for OpenGL rendering. (fine if you're running Linux, not so fine if Linux / X11 isn't an option)

Why does Wayland use EGL and GLES2?

EGL is the only GL binding API that lets us avoid dependencies on
existing window systems, in particular X. GLX obviously pulls in X
dependencies and only lets us set up GL on X drawables. The
alternative is to write a Wayland specific GL binding API, say,

A more subtle point is that includes the GLX symbols, so
linking to that library will pull in all the X dependencies. This
means that we can't link to full GL without pulling in the client
side of X, so we're using GLES2 for now. Longer term, we'll need a
way to use full GL under Wayland.

Work is undergoing for llvmpipe, this will give us Gallium experience (and better software rendering) while putting off the hardware rendering a bit until a better option becomes available.

Change History (5)

comment:1 Changed 6 years ago by kallisti5

Description: modified (diff)

comment:2 Changed 6 years ago by kallisti5

I should note the need. BeOS had a "driver, accelerant, and opengl addon" for each card. Each opengl addon would be aware of the hardware, and communicate to it directly.

That option works well for binary drivers (GL from nvidia, GL from intel, etc), but Mesa3D contains all of the gpu rendering code. Mesa3D expects a standardized pipeline to each card.

  • BeOS: libGL / OpenGL Kit dispatch -> NVidia GL Add-on -> Ring buffer (in GL add-on?) -> Card
  • Linux: Mesa3D libGL -> DRI -> Kernel DRM / KMS driver / ring buffer -> Hardware
  • Haiku: libGL / OpenGL Kit dispatch -> Mesa3D GL Add-on -> ??? -> Accelerant ring buffer -> Card

comment:3 Changed 6 years ago by kallisti5

I may be wrong on the BeOS GL internals, please let me know if I am and I will correct it :)

comment:4 Changed 6 years ago by kallisti5

Here is a run down of the radeon ring buffer and command processor. You could call this a "user story" for our rendering pipeline. Need to confirm that other cards operate in the same way.

comment:5 Changed 5 years ago by kallisti5

This is still up in the air 7 months later.

Current issues:

  • DRI3 has xorg dependencies
  • libdrm doesn't require xorg
  • Wayland uses EGL, which is a pipeline to an OpenGL DRI interface (DRI still requires in-kernel / in driver support)
    • The DRI3 code that is out there requires xorg
      • libraries that support DRI3 require xorg

More info on DRI3:

(These git repos can be browsed on DRI3 protocol and spec:

XCB protocol

XCB library

xshmfence library:

X server:


We're going to have to do one of the following:

  • Make a custom pipeline. This will require code written for each accelerant to interface with using this new pipeline
    • Pros:
      • Stable, we control the ecosystem.
      • We can design it under our rules, avoiding all the C spaghetti code that comes with DRI / DRM. Only the outward interface to userland needs to be C.
    • Cons:
      • More initial work.
      • Could suffer minor breakages due to upstream changes in Mesa.
  • Port over existing drm drivers from the linux kernel. Port over drm code for each driver.
    • Pros:
      • Possibly slightly less work
    • Cons:
      • More likely to break as an update to the DRI specification or an update to the DRM library could cause massive changes requiring a large rewrite.
      • Prone for us to get 'left behind' as with other large projects such as Webkit.
Note: See TracTickets for help on using tickets.