Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Research Collaboration and Enablement
    • DesignStart
    • Education Hub
    • Innovation
    • Open Source Software and Platforms
  • Forums
    • AI and ML forum
    • Architectures and Processors forum
    • Arm Development Platforms forum
    • Arm Development Studio forum
    • Arm Virtual Hardware forum
    • Automotive forum
    • Compilers and Libraries forum
    • Graphics, Gaming, and VR forum
    • High Performance Computing (HPC) forum
    • Infrastructure Solutions forum
    • Internet of Things (IoT) forum
    • Keil forum
    • Morello Forum
    • Operating Systems forum
    • SoC Design and Simulation forum
    • 中文社区论区
  • Blogs
    • AI and ML blog
    • Announcements
    • Architectures and Processors blog
    • Automotive blog
    • Graphics, Gaming, and VR blog
    • High Performance Computing (HPC) blog
    • Infrastructure Solutions blog
    • Innovation blog
    • Internet of Things (IoT) blog
    • Operating Systems blog
    • Research Articles
    • SoC Design and Simulation blog
    • Tools, Software and IDEs blog
    • 中文社区博客
  • Support
    • Arm Support Services
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
Arm Community blogs
Arm Community blogs
Graphics, Gaming, and VR blog Of Philosophy and When is a Pixel Not a Pixel?
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI and ML blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded blog

  • Graphics, Gaming, and VR blog

  • High Performance Computing (HPC) blog

  • Infrastructure Solutions blog

  • Internet of Things (IoT) blog

  • Operating Systems blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tell us what you think
Tags
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Of Philosophy and When is a Pixel Not a Pixel?

Ed Plowman
Ed Plowman
September 11, 2013
3 minute read time.

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?

Anonymous
  • Ravindran Antonysamy
    Offline Ravindran Antonysamy over 9 years ago
    Good One & Waiting for More...!!!
    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Graphics, Gaming, and VR blog
  • More speed with Arm Mobile Studio 2023.1

    Julie Gaskin
    Julie Gaskin
    What's new in Arm Mobile Studio? Here's a round-up of the latest improvements we've made to our free profiling tools for Android.
    • May 12, 2023
  • Yet more ASTC compression

    Peter Harris
    Peter Harris
    This blog explains the performance and quality benefits that developers can expect if they switch to the latest astcenc 4.4 compressor release.
    • April 24, 2023
  • Arm Immortalis-G715 Developer Overview

    Peter Harris
    Peter Harris
    The new Arm®︎ Immortalis™︎ -G715 GPU is now available in consumer devices. This blog explores what is new, and how developers can get the best performance out of it.
    • March 20, 2023