ARM Community: Of Philosophy and When is a Pixel Not a Pixel? - ARM Community

It’s been a busy few months here at ARM in the run up to the launch of the ARM® Mali™-T604 Graphics Processor (GPU) at ARM Techcon. In the post-launch lull (i.e. returning to a slightly more normal level of madness) I’ve been watching the blog-o-sphere for reaction to our new technology launch. While watching the various comments, I’ve noticed that people are having a few issues with some of the performance metrics being pushed at them. Take fill rate, for example. ARM believes in quoting our fill rate performance as bilinearly-filtered, fully textured pixels, written out to the frame buffer pixels (“BFT pixels“) as we believe that’s the most honest, the easiest to compare, and the easiest to understand metric. Pretty straightforward you would have thought? Well maybe not, as we shall see...

Existentialist pixels... when a pixel is
One particular problem people seem to be struggling with is meaningfully interpreting a quoted fill rate. Like other developers of Graphics Processor technologies, we quote a figure for fill rate – the ability to write visible pixels to the screen (or to be more pedantic about it, to a frame buffer that then gets copied to the screen). After all, this is one of the fundamental purposes of graphics acceleration, putting pretty pictures in front of people.

To quote Jon Peddie’s Second Law, “The more you can see, the more you can do.” Now if you know Jon or have hung out with him, you probably wouldn’t credit him with being an existentialist (despite his penchant for black sweaters) but, as in existentialist thinking, he asserts that existence is more important. More pixels drawn, more often, equals better pictures and better pictures equals happier users (the happiness being a product of the existence and the essence of the pixel... more of which in a later blog).

The new user experiences of recent times, whether they be of intuitive, easy-to-understand user interfaces (UIs) or of realistic, fantastical or bizarre interactive visual experiences, all have higher resolution screens and high frame rates at their heart.

ARM is by and large an existentialist company. We believe in provable existence of performance, so we structure our measurement of fill rate accordingly. Therefore we measure the actual rate at which the GPU processes pixels. A Mali-200 outputs one bilinearly-filtered, textured pixel per clock, so at 250 MHz, that is 250 Mpixels/s. A four-core Mali-T604 at 500 MHz does similarly, but outputs one pixel per clock, per core, so with four cores that becomes 2 GPixels/s.

Like nearly all of the graphics industry, that’s exactly what we quote in our marketing material. An ARM Mali pixel/s is a bilinearly-filtered, textured pixel, written out to the frame buffer. Nothing unusual about that, all seems pretty straightforward right?

Deterministic fatalist pixels...when a pixel is not
You would have thought it was straightforward, but there are some GPU manufacturers invoking “overdraw” as a factor in determining measurements of fill rate. Some GPU manufacturers claim a “typical overdraw factor” and use this to multiply the output pixel rate to make some sort of “effective pixel rate”. The philosophy being that the fate of the pixel is predetermined and therefore its existence only needs to be metaphysical in order to make a contribution to the final scene. Of course the problem with a metaphysical pixel is you can’t see it and you can’t prove it exists, so how did it make a contribution? To all intents and purposes, it could just be the sum total of someone’s imagination.

The issue is that content, particularly modern graphical content, is not that deterministic. Overdraw ranges between 1.0 to around 2.0 and all values in between with a great deal of dynamism.

Also, more in line with the existentialist view, the metaphysical state or “essence” of a pixel is not pre-determined. All sorts of dynamic interactions affect the fate of an overdrawn pixel. Blending transparent layers together (e.g. in a modern UI) or other common shader-based dependencies (dependent texture, depth or alpha) rely on the “life choices” made by the pixel. You really do have to allow all those pixels to live, not just the ones at the front, so claiming an increase in fill-rate for some metaphysical pixels is just not playing fair.

Pixels are BFT pixels
We will continue to quote our fill-rate as bilinearly-filtered, fully textured pixels, written out to the frame buffer. (“BFT pixels, pronounced “BeFit pixels” anyone?) We believe that’s the most honest, the easiest to compare, the easiest to understand, and is almost an industry standard.

At ARM, we will remain existentialist and assert that existence is overriding, whilst sipping our espressos.

What do you think?

Ed Plowman, Technical Marketing Manager - Media Processing Division, ARM, Ed has recently returned to ARM Ltd after a stint at Intel where he worked as a games industry evangelist. During his time at ARM Ed guided the graphics processing strategy for a number of years. Ed was also a founding member of Khronos and a significant force in the creation of the OpenGL ES working group. Ed has continued his work within Khronos occupying a seat on the Khronos board of promoters for many years and more recently has taken up the post of Khronos treasurer. Ed started his career as one of the founding members of Argonaut technologies which later became ARC cores, an off shoot of Argonaut Software, working on CPU based 3D graphics technology and later helping create the ARC processor core.