Haiku needs a DRM compatible driver architecture for video cards.

[kallisti5]

Haiku needs a DRM-compatible driver architecture for video cards. With such an architecture, we could begin porting Linux graphics drivers to Haiku.

• Implement DRM lib/compat
• Figure out hooks from Haiku-native calls to DRM. (DRM accelerant?)
• Leverage libglvnd for 3d rendering
• 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)

​http://wayland.freedesktop.org/faq.html

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,
WaylandGL.

A more subtle point is that libGL.so 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.

[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

[kallisti5]

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

[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.

​http://dri.freedesktop.org/wiki/RadeonArchitecture/

[kallisti5]

This is still up in the air 7 months later.

Current issues:

• DRI3 has xorg dependencies
• libdrm doesn't require xorg
  • libdrm requires libpciaccess, which requires xorg ​https://bugs.freedesktop.org/show_bug.cgi?id=76320
• 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:

• ​http://keithp.com/blogs/dri3_extension/

(These git repos can be browsed on ​http://git.freedesktop.org) DRI3 protocol and spec:

• ​git://people.freedesktop.org/~keithp/dri3proto master

XCB protocol

• ​git://people.freedesktop.org/~keithp/xcb/proto.git dri3

XCB library

• ​git://people.freedesktop.org/~keithp/xcb/libxcb.git dri3

xshmfence library:

• ​git://people.freedesktop.org/~keithp/libxshmfence.git master

X server:

• ​git://people.freedesktop.org/~keithp/xserver.git dri3

Mesa:

• ​git://people.freedesktop.org/~keithp/mesa.git dri3

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.

[SamuraiCrow]

Revisiting a 9-year-old ticket, the advent of Vulkan renders much of the previous discussion obsolete. There is much more streamlined support for the lower-level APIs of Vulkan than what OpenGL ever had. The advent of wrapper libraries that call Vulkan drivers, such as DXVK and Zink, make Vulkan a good choice for modern graphics drivers. The kernel-level Linux drivers may have redirection issues but I think the RISC-V Haiku codebase has those issues dealt with to some extent. What remains to leverage Radeon and Intel open-source drivers on Haiku? Will the Linux kernel call redirection from the RISC-V version apply to other architectures? Will Lavapipe be adequate to use on older cards or will OpenGL-ES drivers need to be used? I know there are software patches like GL4ES that make classic desktop OpenGL code work on OpenGL-ES drivers to alleviate some driver overhead. Does Mesa even need such patches?

[waddlesplash]

Vulkan changes nothing here. The kernel-level drivers have been modified to support Vulkan in Linux, but this just means they have slightly different IOCTL interfaces. Otherwise the demands and requirements are exactly the same as before. There is no difference on RISC-V either; X512's experiments with a custom driver for Vulkan work on x86 too. The same amount of work is required as before.

[X512]

Hopefully Mesa DRI infrastructure is not needed for Haiku, OpenGL drivers can be directly based on Gallium (all non-Gallium drivers are declared obsolete and removed from Mesa source tree), Vulkan drivers do not use DRI framework.

My experimental implementation provides its own libdrm implementation that allows running Mesa Vulkan drivers almost unchanged and also OpenGL by using Zink. For OpenGL I use glvnd driver loader framework and EGL glvnd driver over Gallium. HGL code in Mesa is dropped and BGLView is implemented as wrapper over EGL in glvnd. My Mesa patches are available here:

• ​https://github.com/X547/mesa
• ​https://github.com/X547/libglvnd

[X512]

Replying to kallisti5:

• 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

My flow: glvnd OpenGL dispatch -> EGL Mesa driver -> Zink Gallium driver -> libvulkan dispatch -> Mesa RADV Vulkan driver -> libdrm2 -> port_id IPC messages -> GPU server in userland -> GPU hardware access via MMIO area_id, IRQ with sem_id, physical memory translation with poke driver needed for GPU MMU.

[SamuraiCrow]

Thanks for sharing your notes, X512. Just a few questions:

Is glvnd capable of also processing OpenGL-ES 2.x or 3.x calls or would an ​ANGLE port be necessary to implement WebGL, the WWW wrapper for OpenGL-ES?

Also, I haven't looked into WebGPU but I've heard it is a low-level wrapper for low-level GPU APIs like Metal or Vulkan. Is there an existing wrapper for the WebGPU protocol that your experiments could solve? Is assistance needed? I may not have the time to do the whole job but I can see what's been done once I know what I'm looking for.

[X512]

Replying to SamuraiCrow:

Thanks for sharing your notes, X512. Just a few questions:

Is glvnd capable of also processing OpenGL-ES 2.x or 3.x calls or would an ​ANGLE port be necessary to implement WebGL, the WWW wrapper for OpenGL-ES?

glvnd supports OpenGL ES v1, v2 (v3 is libEGL.so?).

/Haiku/data/packages/libglvnd/build.x86_64/install> tree lib
lib
├── libEGL.so -> libEGL.so.1
├── libEGL.so.1 -> libEGL.so.1.1.0
├── libEGL.so.1.1.0
├── libGL.so -> libGL.so.1
├── libGL.so.1 -> libGL.so.1.0.0
├── libGL.so.1.0.0
├── libGLdispatch.so -> libGLdispatch.so.0
├── libGLdispatch.so.0 -> libGLdispatch.so.0.0.0
├── libGLdispatch.so.0.0.0
├── libGLESv1_CM.so -> libGLESv1_CM.so.1
├── libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.2.0
├── libGLESv1_CM.so.1.2.0
├── libGLESv2.so -> libGLESv2.so.2
├── libGLESv2.so.2 -> libGLESv2.so.2.1.0
├── libGLESv2.so.2.1.0
├── libOpenGL.so -> libOpenGL.so.0
├── libOpenGL.so.0 -> libOpenGL.so.0.0.0
└── libOpenGL.so.0.0.0

0 directories, 18 files

[SamuraiCrow]

Replying to X512:

Replying to SamuraiCrow:

Is glvnd capable of also processing OpenGL-ES 2.x or 3.x calls or would an ​ANGLE port be necessary to implement WebGL, the WWW wrapper for OpenGL-ES?

glvnd supports OpenGL ES v1, v2 (v3 is libEGL.so?).

OpenGL-ES 2 is good enough for WebGL1. WebGL2 corresponds to OpenGL-ES 3.x but it's a start just to get WebGL1 going. If more is needed later, it will be later when we get to it anyway.

I've forked your repos and am trying to get glvnd to build. Should I have built Mesa first? I hate to nag but are there different build instructions for Haiku? I see from your directory that you're already looking at x86_64. That's also my build target but I've got one of those old pesky Radeon cards that don't support Vulkan so I'm going to look into making OpenGL 3.3 work on it.

[kallisti5]

The pipeline is shifting due to X512's recent work on Mesa and libglvnd.

Was:

• Haiku: libGL / OpenGL Kit dispatch -> Mesa3D GL Add-on -> ??? -> Accelerant ring buffer -> Card

Now:

• Haiku: libGL (libglvnd) OpenGL Kit dispatch -> Mesa3D libglvnd EGL renderer -> Accelerant (likely DRI hooks?) -> Card

See ​https://github.com/haikuports/haikuports/issues/8152 for current status of this.

[kallisti5]

I gotta say, us/me maintaining radeon_hd is becoming unsustainable.

We have an awesome radeon_hd driver which works pretty well for modesetting of "Radeon HD 2xxx - 6xxx cards" with a few notable exceptions (like this one lol. aka laptops / displayport).

The AMD team began transitioning to a new driver called amdgpu for Radeon RX 4xx - RX 7xxx. The big difference in the new drivers seems to be a rearchitectured method for connector discovery and management. (there's also new discovery subsystem for card memory, etc).

I'm sure these are all big improvements for the modern "daisy chained display" world. The new driver also means AMD can sidestep decades of quirks and weird one-off-mistake patches as well (which are getting easier and easier to accidentally break)

The big tldr here is:

• If we want to continue maintain / improve radeon_hd for new cards I need help. I'm getting old and not as sharp as I used to be. (nor I have the motivation I used to)
• We should *seriously* consider a substantial investment in a drm compatibility subsystem. We have been talking about this for several years now. I love BeOS's driver architecture, it's elegant and simple... however we don't have the people power to continue maintaining even basic modesetting drivers as things stand.
• GPU's move quick. radeon_hd has been a great stop-gap I put a lot of love into to get functional, it'll always be limited / broken compared to a driver developed by multiple paid AMD engineers and 10's of thousands of Linux kernel engineers.

FreeBSD went the DRM compatibility route because of the above. ​https://github.com/freebsd/drm-kmod

X512 has already done awesome work implementing libglvnd for Haiku which nudges us closer to this future which could have hardware 3d rendering.

So where do we go from here? Poke at waddlesplash and X512 to start work on a DRM compat subsystem. :-)

Here's the pre-existing work i'm aware of..

• ​https://review.haiku-os.org/c/haiku/+/435
• ​https://review.haiku-os.org/c/haiku/+/3823

[nephele]

FreeBSD went the DRM compatibility route because of the above. ​​https://github.com/freebsd/drm-kmod

Indeed, sadly DRM on FreeBSD works even worse than linux. This for me ment constant crashes, freezes etc and basically "sorry we cant fix it we don't understand it" for pretty much all issues :/

I'd rather have Haiku modesetting drivers that work than drm drivers that do 3d but randomly crash my deskop. So, if DRM can be used in the sense that the driver *only* does the 3d stuff in userpsace and we keep our modesetting driver that could be an avenue that might work. We should keep the door open for native drivers next to this though, not become dependant on drm.

I'd be fine with helping maintining gpu drivers but would probably need some guidance to get started.