Someone said that they didn’t think GLTeapot was much of a benchmark, but I think it could be. But it needs specific refinement.
Right now, we know it’s basically CPU-centric, because there is no accelerated 3D in graphics card hardware. It’s also capped at 60fps, which as I recall was mentioned as the fact it was tied to Vertical Sync. But this does not exclude it from being a true benchmark. We just need to redefine what we’re looking for/at and measuring.
First of all we need the teapot lid to match the rim of the teapot. The fact that you can see the black or fog background when the teapot comes around to the top, looks “glitchy” at best. Obviously, this is because there is only one layer of polygons making up the entirety of the teapot. There is no “inside” layer of polygons to the teapot, so when backface culling is enabled, we’re seeing through the gap around the lid and seeing… nothing, because the bottom of the teapot is behind what we can see and, therefore, is removed (the “backface” (what is technically not visible) is culled (removed)). So, by making the lid match the rim, we won’t see that, which will be a visual improvement.
We need to know EXACTLY how many polygons comprise the teapot.
We need to be able to have GLTeapot “stress-test”, by being able to select between different rendering engines (Mesa, Gallium, Vulkan, etc.), as well as the number of CPU cores used, resolution (size) of display window, features (whatever is supported by the given rendering engine; anti-aliased, mip-mapping, texture mapping (the teapot in stone or leopard skin?), etc.).
The FPS display should be less huge/obvious. It should probably be smaller text.
It should run for a set duration, and a score given at the end.
The number of polygons rendered should be able to be increased (the single teapot rendered with more/smaller polygons or the number of teapots rendered increased), as part of the stress test. Then you’ll know exactly how many total polygons can be rendered at a given framerate. Should 60fps be considered the bare minimum or 30fps? The number of polygons is increased until the selected framerate can no longer be maintained solidly.
Basically, I discovered that my dual-core/quad-thread Pentium G4560 processor was fully capable of running the teapot at 60fps, with Perspective and Fog enabled, at full windows size (as big as I could make it), on a 1920x1080p monitor, on 1 core and never reached more than 50%. That gives me at least a certain metric of my CPU’s capability to render 3D graphics. It’s hard to tell how much of my CPU is being taxed with all four threads bouncing around, but with only 1, I was able to tell easily.
Being able to uncapping the framerate would also tell you how many desired fps (say you want 75-100fps or more) you could get on a given processor. I think, at some point, there is ridiculous overkill, but who are we to say what any one person should have to settle for?
Thanks for the head’s up! However, I’m running R1/alpha 4 + updates. The updated GLTeapot isn’t available for this version, is it? Do I have to install a nightly to get it?
Optimizing for rednering glteapot quicker gives you one thing… a quicker teapot rendering.
It can never be a “good” 3d benchmark because it only uses simplistic features.
If you want a benchmark you will have to build one from scratch.
Mesa Galium and Vulcan are three parts of the same stack, and they can’t be switched between, that makes no sense.
also, for your suggestions: turning off cpus is already possible. adding several teapots is too.
The first question for benchmarks is: what do you want to measure?
CPU speed? Improvements in newer Mesa versions? GLTeapot will make a bad job at either of these, because a teapot is an extremely simple object using only very antiquated OpenGL primitives. No recent (that is, made in the last 25 years) OpenGL app is working similarly to it. As for CPU, well, your benchmark will be interferenced by the video RAM speed, and whichever instructions the Mesa rendering decides to use or not.
So, there are better tools for that. CPU benchmarks exist and can be ported. For example you could use the SPEC benchmarks: SPEC Benchmarks - Published Results
If you want a benchmark for app_server drawing speed, there are several of these available. For example I wrote BeNICCC which has a benchmark mode. It will mainly compare polygon filling: GitHub - pulkomandy/beniccc
The goal of GL Teapot is to draw spinning teapots. It’s not to test how fast your system is. It was not designed for that, and even if it were, it would be a benchmark of long obsolete 3D graphics. The 3D model of the teapot is from 1975, it was an interesting test for 3D rendering capabilities at the time, but not today.
I have a new saying I use: “Don’t go jumping in after alligators”. At some point, a matter just becomes an argument. People have differing opinions on things and no matter how you try to explain it or make your point, you get nowhere in doing so.
So, instead of getting irate and upset, I’m just going to walk away. I’ve tried to offer a perspective on making GLTeapot “useful” and no one wants to entertain the idea. So, let others decide what they will. I have better places to spend my energy. LT. LGO.