What's the end game when it comes to 3D acceleration?

I apologize I’m just slightly curious I heard haiku sort of uses its own display protocol and a lot of other things when it comes to 2D and 3D acceleration what’s the future plans for all that are you guys planning on working on the existing display server are we going to move over to say something like Wayland I personally believe we should just improve when we have already trying to keep things as original possible but that’s just my take on it

Previous discussions: Plans for 3D acceleration

1 Like

Sorry I didn’t see that older post

Thank you! I was curious about this. I’m mainly interested in acceleration for 4K displays and the ability to run them at at least 60Hz. You know, having a smooth experience with Haiku itself

There is some work being done where possible Haiku ❤ Nvidia (porting Nvidia driver for Turing+ GPUs)

1 Like

That is completely unrelated. I run my haiku system with a 4K panel with 120hz (though 140hz can also work, but the display is 240 so tather just use half) with just the efi driver.

Anything more than that requires displayport link training code and native modesetting, but, this is a completely different issue to 3d acceleration or to accelerated decoding of media (video acceleration)

1 Like

I am aware. I’m mainly commenting on the drivers taking full advantage of the GPU.

Which graphics card and monitor are you able to run at 4K at 120 Hz? Each time I run Haiku at 4K, either I can’t select 60 Hz, or I use a Radeon and get a very sluggish framerate at 4K.

But yes, this thread is about 3D acceleration. So this is unrelated

If you can’t use 60hz maybe you have a cable that can’t support this?

For HDMI you need some specific cables, it is somewhat easier with displayport…

For gpu this worked for me with both a intel arc something gpu and a high end amd card; The monitor is branded aorus

Anyway, if you can use the efi driver try doing that and disable CSM mode. Some efis only allow higher modelines if CSM is disabled.

I have multiple cables, and they’re the same ones that work just fine on Windows with the same display. I also got a Display Port to HDMI adapter at 4K 60hz option

Thanks, I’ll try this. It’s preventing me from using Haiku more often.

First, it is needed to clarify that 3D acceleration can work without any kind of support on display server and GUI toolkit side. It can even be used on PC without display and running GUI. You can render into arbitrary GPU buffer.

So, even without display server support, you can render into GPU buffer, copy its contents into regular CPU memory and display it with existing BView::DrawBitmap API. This is actually already possible for Nvidia Turing+ GPUs with my experimental Nvidia GPU driver port (see Haiku ❤ Nvidia (porting Nvidia driver for Turing+ GPUs)).

Second, acceleration and display output are two almost unrelated things. GPU acceleration is for doing some computations faster, but CPU still can do it with the same results by using for example Mesa llvmpipe, just slower. Display output (also called modesetting) driver allows setting screen resolution, refresh rate (including variable refresh rate), supporting multiple displays, V-Sync, hardware cursor, video overlays. If there are no display output driver, it is often still possible to use BIOS/UEFI framebuffer, but you will be not able to use multiple screens, change resolution or refresh rate or render without tearing.

Currently Haiku have no any kind of GPU acceleration support and very primitive display output control support, so no multiple displays and no rendering without tearing yet.

I am currently working on “app_server_neo” project that will introduce proper display output control support and 2D vector graphics hardware acceleration using Skia library and Vulkan API. This features will work only on Nvidia GPUs for first time. Project is currently far for being complete and too early to show results. It still use current app_server protocol and not based on Wayland or X11.

20 Likes

For efficient integration or 3D accelerated rendering with Haiku GUI, some extensions to HaikuAPI will be needed.

First, it should be possible to bind BBitmap to GPU memory to avoid wasteful GPU → CPU → GPU copy operations. That will need OpenGL/Vulkan extensions for creating BBitmap from EGL Image or VkImage.

Second, it should be possible to use GPU synchronization primitives and call BBitmap draw operation even before GPU rendering operation is completed to achieve better GPU utilization.

Example API extension can be:

void BView::Wait(BFence* fence);
void BView::Signal(BFence* fence);

BView::Wait() will pause executing drawing operations after this call until specified BFence is signaled. Call itself do not block current thread. BView::Signal() will signal specified BFence when all drawing operations before this call are complete.

Some new OpenGL/Vulkan extensions will be needed to convert OpenGL/Vulkan semaphores/fences to Haiku BFence.

BView::SetViewBitmap() will need new variant with specified wait and signal fences similar to Wayland protocol:

void BView::SetViewBitmap(
    const BBitmap* bitmap,
    BFence* waitFence,
    BFence* signalFence,
    BRect source,
    BRect destination,
    uint32 follow = B_FOLLOW_TOP | B_FOLLOW_LEFT,
    uint32 options = B_TILE_BITMAP);

CC: @waddlesplash, @PulkoMandy

11 Likes