High-performance 3D on Haiku

Software
28

I already managed to port and run this driver as userland server, but it need integration with app_server modesetting and Mesa NVK Vulkan driver to be actually useful.

15 Likes
29

Once that is done, what kind of performance can we expect? Just how fast will the Teapot spin THEN? 1,000,000fps? :rofl:

3 Likes
30

I am new to Haiku, and I was kinda surprised when I saw mine (QEMU Virtual Machine) been only at 300+ fps. I mean, 300fps are great, but not for something so simple. Then again, it was OpenGL and not Vulkan, but this thread that explains that there is no GPU acceleration on Haiku gives some sense to my thoughts!

I hope we can have it soon and that Teapot can be at least 1000fps :wink:

3 Likes
31

https://www.theregister.com/2024/04/05/amd_mes_open_source/

2 Likes
32

I’ve read about exactly such an project only a few days ago: New open source GPU is free to all — FuryGPU runs Quake at 60fps, supports modern Windows software | Tom's Hardware
For now there’s only a driver for Windows,but since it’s fully open-source,one for Haiku can be written.
I don’t know if that thing is faster than software rendering (or at least not slower),however.

1 Like
33

Ref:

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

1 Like
34

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

35

Software rendering only.

36

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!

37

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
38

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.

39

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…

40

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…

41

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

2 Likes
42

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?

43

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.

44

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

45

Example:
https://depot.haiku-os.org/#!/?bcguid=bc1-JKYS&repos=haikuports&arch=x86_64&incldev=false&viewcrttyp=ALL&srchexpr=3D

46

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

47
1 Like