High-performance 3D on Haiku


See: Software Rendering Vs GPU Rendering: Differences, Pros, Cons (mygraphicscard.com)

1 Like

Thanks for the information! When it comes to the screenshot you provided, on the other thread, is it indeed Hardware accelerated or software render?

Software rendering only.

Seems amazing that you can get almost 2,000fps on GLTeapot via just software rendering. However, you didn’t mention what CPU/motherboard you were running, only the version of Mesa and the graphics card model. Since it’s CPU rendering, then we need to know what CPU you’re using! Also, perhaps, the revision of Haiku as well.

Now, in this scenario (software rendering), we need to start detailing the aspects of GLTeapot. How many polygons (triangles) is being displayed every frame. Obviously, there is no collision detection, even with multiple pots all spinning at once. Which got me to thinking about demos like this:

Or this:

Now given OUR (Haiku’s) logo is either a leaf or the Teapot (or the entire Haiku logo), if we were to create our own version of this type of demo, it could showcase:

  1. Collision detection (w/ walls and floor)
  2. Physics (same)
  3. How many triangles are rendered per frame
  4. Collision detection between teapots (or whatever image we used)
  5. Total framerate

In other words, we’d have a metric by which we could measure the functional performance of our systems in a fairly real world “game” environment. Someone (or a couple of people) threw together those two demos (Amiga and Atari ST) on hardware that, by today’s standards, are pathetic. So, why can’t we do something similar and showcase something that Haiku can do even better today!

And if/when hardware rendering is available in the future, we can switch between the two to see the difference and then record the percentage improvement!

Someone (or a couple of people) threw together those two demos (Amiga and Atari ST) on hardware that, by today’s standards, are pathetic.

These demos are also pathetic by modern standards. Using algorithms and hardware that is more than ten years old, you can

So one can easily imagine the following demo: a glass utah teapot filled with red liquid falls inside a transparent box. It crashes into pieces, splashing red liquid inside the box. The liquid make waves, and teapot pieces are carried a little bit by the waves. And of course all the sounds are simulated in runtime.

1 Like

Right… and you can code this in the same amount of time, as those two demos were coded in in the 80’s, right? I’m talking about making a SIMILAR demo, not one that vastly exceeds them. I’m not talking about what today’s systems CAN do, but what we DON’T have right now, as any type of benchmark. And GLTeapot is not as technically enabled (though it renders a much smoother teapot, because of the type of shading/resolution), because it doesn’t involve any physics or sounds or “physical” interactions with the environment. I’m simply proposing that a demo, similar to the ones I linked, be created that would showcase MORE than what the current GLTeapot demo does.

I just updated my copy of Haiku x86_64 R1/B4 to the latest revision, but GLTeapot still doesn’t have the “disable framerate limitation” option. However, I was able to Jam the latest version, which had it and… apart from the FPS counter changing so fast, I can’t even tell HOW fast it’s going (it’s something over 1,500fps, I think), it’s nice to know that unleashing it does tell me just how fast software rendering can be… which is insanely fast.

That being said, I believe, if we’re going to keep GLTeapot as a demo, it needs to be more informational and useful than it currently is. It tells us NOTHING about how many teapots are spinning, how many triangles are in the teapot, what the maximum/minimum/median framerate is, etc. And I think we need to set a standard that cannot be changed.

What I mean by that is we need to make the display represent some kind of reality. Spinning a teapot in a tiny window is ridiculous. If it were a game, you couldn’t even see the game! So, how fast it spins is utterly pointless. So I think the window needs to be sized to a standard dimension within the resolution that Haiku is displaying. Not resizable on the fly. Yeah, resizable windows on the fly is a cool thing that shows what Haiku can do as far as function, but displaying a spinning GLteapot at over 2,000fps in a 1" or smaller window is silly. And the framerate goes all over the place (and the graphics glitch) when your mouse pointer is moving over the window, so that needs to be fixed.

If we want a windowed display of GLTeapot, it needs to be something like 640x480, 800x600, 1024x768, etc. Something that will fit within the current resolution Haiku is using. If we want full-screen, then the display fills the entire screen. Settings made should be savable, so GLTeapot starts up with the same settings each time. In full-screen mode, the settings can be changed with number keys or something.

Just some ideas…

See: Gaming on Haiku - #89 by cocobean

GLTeapot is a simple app but it does show a basic benchmark. The difference in discussions is that GLTeapot is not a true representation of real 3D graphics benchmarking in full consideration. No high-end polygon counts, phong shading, bump mapping, or tessellations. At least, not in this current app iteration…

This is where the line in the sand is drawn by most enthusiasts…using 3DMark… etc, etc…

It is mostly a benchmark of memory bandwidth, not 3D rendering.


Then I would argue that we should try to push the boundaries of what it does and can do. What version of OpenGL does it represent in its current form? Is it displaying everything it can? Is it maximizing the rendering capabilities of that OpenGL version? Obviously, it’s using Mesa, the open-source representation of OpenGL, but still.

Why not really push things to the limit and show what we can do with Mesa 22.whatever? Let’s see just how much we can do with software rendering right now. Why not? People (Demo Crews) create demos to show off capabilities of hardware. The Care Bears (TCB) did it for the Atari ST. Other people still do it for Windows or other platforms. Why can’t we do something to really impress people with what software rendering can do in Haiku?

OpenGL 4.6 API compatibility. Also, Vulkan 1.3 API compatibility.

Several Vulkan/OpenGL-based demos and games are already ported to Haiku and mentioned in the forum. Really Slick Screensavers and the Sascha Willems Vulkan demos are good.

Where are they? I am looking on the SoftwareDepot and not seeing those names or types of programs.


Where are these, specifically? I still don’t see them.

1 Like

The implication was that these demos and such were already available to download for Haiku, not something I had to build from sources. I know Jam, but how do I build these?


It is CMake project, so you need to use something like mkdir -p build; cd build; cmake .. -G Ninja; ninja to build. It is intended to be sample source code to learn how to write applications that use Vulkan API, it is not intended for end user.


Well, I can confirm, Lugaru eats up all cores/threads (100%) on my Kabylake CPU at 1280x1024 windows with several effects enable (even minimally). I can get it down to about 90% total usage, if I run it in a 640x480 windows with all effects disabled. Need to test Nanosaur next…

1 Like

Ok, Nanosaur is definitely a lower-spec’d game, as it has nothing but anti-aliasing (I maxed it out to 8x) and one size of Windowed mode (640x480, I assume). And it was using about 25% of my entire CPU (threads all bouncing around). But I’m curious as to how many triangles it’s pushing, since it’s not using hardly any OpenGL effects. Just textures. It’s a fun game, but I need to bone up on how to play it properly.

1 Like


I actually got GLTeapot past 2401 FPS (i.e. using software rendering only) on a basic system w/ Intel HD 4600 IGP.

I tested SuperTuxKart on my old Y2010 x86 laptop with 1GB memory and a 1.7Ghz dual-core processor.

@X512 ran Vulkan demos and a Xonotic game with Mesa 22.2.0-devel and the new RadeonGfx driver.

We have other demos for benchmarking already…

Expected speedup: Depends, usually 2x-11x overall performance increase (see notes) depending on screen resolution and other factors. On BeOS 5.0.3, I’ve seen GLTeapot run at 4552 FPS.

Note: Based on my reviews on Intel HD Graphics 4600, Intel Arc A770 (16GB), AMD Radeon RX 590, and AMD Radeon RX 7900 XTX.