4
\$\begingroup\$

I've looked around and found several sites offering benchmarking statistics for mobile platforms and I've been seeing the unit of measure as "kTriangles/s". Originally I misread this, missing the 'k'; does this translate to "thousand(s) of triangles/s", e.g.:

8902 kTriangles/s = 8,902,000 triangles/s

(I'm pretty sure that my interpretation is correct, but I hope someone can confirm this for me)

Improve this question
\$\endgroup\$

2 Answers 2

Reset to default
6
\$\begingroup\$

Your interpretation is correct, it's thousands of triangles per second.

Improve this answer
\$\endgroup\$
0
9
\$\begingroup\$

In terms of utility as a measurement for how good hardware is?

Absolutely nothing

Yes, it means thousands of triangles per second. But it means nothing in terms of how good hardware is. It's about as useful a performance metric as CPU clock-speeds: at best an order-of-magnitude approximation.

These metrics are usually taken under ideal, benchmarking conditions, not real-world situations. In general, achieving these numbers in real applications will be impossible outside of the most ideal conditions. And what constitutes "ideal conditions" will change from hardware to hardware.

Improve this answer
\$\endgroup\$
4
  • 4
    \$\begingroup\$ Absolutely. It's been a long time since we were vertex bound on GPUs. In pretty much every title I've worked on in the last 7 years we've been fill-rate bound (i.e. how quickly can the pixel shaders be executed on the card). That's especially true on mobile GPUs. It's also why the number of pixel shader units is more and more relevant, as parallelisation of pixel processing is a much bigger win than, say, processing more vertices faster. I confess I haven't checked recently how many pixel pipelines your average mobile GPU has. \$\endgroup\$
    – MrCranky
    Apr 13, 2012 at 9:16
  • \$\begingroup\$ I appreciate the insight; I do take most of these benchmarks with a grain of salt. Mostly I've been trying to determine what the maximum possible polygon budget could be and then taking a more realistic value lower than that to give as direction to our modelers and designers. Going forward, when looking at performance capabilities, should I be looking at fill-rate? \$\endgroup\$
    – swquinn
    Apr 13, 2012 at 14:23
  • 1
    \$\begingroup\$ @swquinn: Honestly, it depends on what you're rendering. In the vast majority of cases, triangles/sec is about the least useful benchmark that exists. That usually measures the triangle setup time, which is almost never the bottleneck. You're going to be more interested in vertex shader performance, because that's going to be the real limiter of the number of triangles. If you're making a 2D game, even that's irrelevant; all that matters there is fillrate. \$\endgroup\$
    – Nicol Bolas
    Apr 13, 2012 at 14:49
  • 3
    \$\begingroup\$ It's one of those tricky questions that we all face: the content creators want budgets in terms of hard numbers, but it's not as simple as that. What I can tell you is: don't use triangles/sec. GPU manufacturers will use untextured, unlit triangles and get a stupidly high number that tells you only the theoretical limit of their vertex pipeline. My advice is to knock up some placeholder geometry, apply some representative shaders to it, put a sensible number of lights in the scene, and then run it on your low and high end hardware. Add or subtract geometry/lights until you find the limits. \$\endgroup\$
    – MrCranky
    Apr 13, 2012 at 15:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .