The complete guide to PowerVR Rogue GPUs: specifications, features, API support

17th July 2014 Consumer multimedia 36 Comments

While writing the conclusion for the article announcing OpenGL® ES 3.1 conformance for PowerVR Rogue GPUs, I suddenly realized that we now have more than ten apps processors using PowerVR Rogue GPUs; this includes various configurations of dual or quad-cluster PowerVR Series6 graphics processors.

Therefore, I came up with this idea of offering a bite-sized blog post that summarizes our current line-up of GPUs. You can use the menu below to navigate between our GPU families:

This article is meant to offer you a comprehensive look at the specifications, features and API support for the PowerVR Rogue family. I highly recommend you add it to your bookmarks and come back from time to time because I will continue updating it when we announce next-generation GPUs.

If you want a better understanding of the internal architecture of the USC (Unified Shading Cluster), please read Rys’s expose (Graphics cores: trying to compare apples to apples) and check out Imagination’s PowerVR Rogue Architecture Explored (lots of diagrams included), an in-depth review from Ryan Smith at Anandtech.

For those of you who want to query this information in code, Joe Davis from our Developer Support team has uploaded a C++ helper function to GitHub that takes a PowerVR Rogue model number string as input (e.g. an OpenGL ES GL_RENDERER string) and outputs a structure of basic hardware capabilities. Try it out on a mobile device that has a PowerVR GPU and let us know what you think we should add or improve.

In summary, our PowerVR Rogue graphics architecture brings a number of unique features designed to improve overall system performance, lower power consumption and reduce memory bandwidth:

  • Scalar processing to achieve the highest utilization of ALUs and ease graphics programming
  • PVR3C™ triple compression: a combination of lossy texture compression (PVRTC and ASTC), lossless image compression (PVRIC) and lossless geometry compression (PVRGC) techniques to reduce memory bandwidth
  • PowerGearing™ to manage different power consumption levels and balance overall SoC power consumption
  • A mix of FP32 and FP16 ALUs for high-precision/low-power computing.

There are currently three families of GPUs based on the PowerVR Rogue architecture (see the roadmap below); the tables that follow describe how the features above map to each GPU.

PowerVR Rogue GPUs - Graphics IP roadmap

PowerVR Series6XT GPUs: ultra-high performance, ultimate feature set

Introduced at CES 2014: press release | blog article

PowerVR GPUNo. of USCsNo. of ALUsTexture compressionFrame buffer compressionGeometry compression
GX6240264 (FP32)
128 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		–PVRGC
GX6250264 (FP32)
128 (FP16)		PVRTC1/2
ASTC (LDR + HDR)
ETC1/2
BC1/2/3		PVRIC2PVRGC
GX64504128 (FP32)
256 (FP16)		PVRTC1/2
ASTC (LDR + HDR)
ETC1/2
BC1/2/3		PVRIC2PVRGC
GX66506192 (FP32)
384 (FP16)		PVRTC1/2
ASTC (LDR + HDR)
ETC1/2
BC1/2/3		PVRIC2PVRGC

API support*: OpenGL ES 1.1/2.0/3.1, OpenGL 3.3, OpenCL 1.2 EP, RenderScript, DirectX 10_0

^Go back to the main menu

PowerVR Series6 GPUs: performance efficiency and a balanced feature set

Introduced at CES 2012: press release

PowerVR GPUNo. of USCsNo. of ALUsTexture compressionFrame buffer compressionGeometry compression
G6200264 (FP32)PVRTC1/2
ETC1/2
BC1/2/3		–PVRGC
G6230264 (FP32)
96 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		PVRICPVRGC
G64004128 (FP32)PVRTC1/2
ETC1/2
BC1/2/3		–PVRGC
G64304128 (FP32)
192 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		PVRICPVRGC
G66306192 (FP32)
288 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		PVRICPVRGC

API support: OpenGL ES 1.1/2.0/3.1, OpenGL 3.3, OpenCL 1.2 EP, RenderScript, DirectX 10_0

^Go back to the main menu

PowerVR Series6XE GPUs: OpenGL ES 3.1 for everyone!

Introduced at CES 2014: press release | blog article

PowerVR GPUNo. of USCsNo. of ALUsTexture compressionFrame buffer compressionGeometry compression
G60501/216 (FP32)
32 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		––
G60601/216 (FP32)
32 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		PVRIC2–
G6100132 (FP32)
64 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		–PVRGC
G6110132 (FP32)
64 (FP16)		PVRTC1/2
ETC1/2
BC1/2/3		PVRIC2PVRGC

API support*: OpenGL ES 1.1/2.0/3.1, OpenGL 3.2, OpenCL 1.2 EP, RenderScript, DirectX 9_3

^Go back to the main menu

PowerVR Wizard ray tracing GPUs: interactive cinematic realism for mainstream devices

Introduced at GDC 2014: press release | blog article

PowerVR GPUNo. of USCsNo. of ALUsTexture compressionFrame buffer compressionGeometry compressionRay tracing performance at 600 MHz
GR65004128 (FP32)
256 (FP16)		PVRTC1/2
ASTC
ETC1/2
BC1/2/3		PVRIC2PVRGC300 million rays per second
24 billion node tests per second
100 million dynamic triangles per second

API support*: OpenGL ES 1.1/2.0/3.1, OpenGL 3.3, OpenCL 1.2 EP, OpenRL 1.x, RenderScript, DirectX 9_3

^Go back to the main menu

I hope that this article provides a useful overview of our PowerVR Rogue GPUs. If you have any questions, please don’t hesitate to use the comment section below.

For the latest news and announcements on PowerVR graphics, GPU compute and ray tracing, follow us on Twitter (@ImaginationPR, @PowerVRInsider, @PowerVR_RT, @GPUCompute) and keep coming back to the blog.

Editor’s Note

* All PowerVR Rogue GPUs are based on published Khronos specifications and are expected to pass the Khronos Conformance Testing Process. PowerVR Series6 GPUs have already passed the Khronos Conformance Testing Process. Current conformance status can be found at www.khronos.org/conformance.

OpenGL is a registered trademark and the OpenGL ES logo is a trademark of Silicon Graphics Inc. used by permission by Khronos.

OpenCL and the OpenCL logo are trademarks of Apple Inc. used by permission by Khronos.

Categories: Consumer multimedia Tags: PowerVR developers PowerVR graphics ray tracing

About the author Alex Voica

Before deciding to pursue his dream of working in technology marketing, Alexandru held various engineering roles at leading semiconductor companies in Europe. His background also includes research in computer graphics and VR at the School of Advanced Studies Sant'Anna in Pisa. You can follow him on Twitter @alexvoica.

View all posts by Alex Voica
More posts by Alex Voica
Sizing up the IoT, IoE and connected devices market
Bus Blaster V3c is an affordable debug probe for MIPS CPUs
Debian 8 comes to Creator Ci20
Ensigma RPUs: the next big thing in SoC integration
Related Blog Posts
Understanding PowerVR Series5XT: YUV colour space conversion…
Updated Creator Ci20 features improved board layout, out of …
My week with Dell Venue 8, the first Android tablet to use a…
From “more” pixels to “better” pixels: the rise of H…

Comments

  • tubby_glossop

    Thanks Alex, informative article. Looking forward to series 7 “gluttony”! Or will it be “sloth”?

    • Haha, good one! I think we’ll be sticking with Rogue for the moment but I’m sure David Fincher approves of your suggestions.

      • Jack Bauer

        Didn’t the boss say we will get to hear about series 7 by year end.

        • Yes, he did. It’s still July, there’s plenty of time left.

  • tubby_glossop

    Thanks Alex, informative article. Looking forward to series 7 “gluttony”! Or will it be “sloth”?

    • Haha, good one! I think we’ll be sticking with Rogue for the moment but I’m sure David Fincher approves of your suggestions.

      • Jack Bauer

        Didn’t the boss say we will get to hear about series 7 by year end.

        • Yes, he did. It’s still July, there’s plenty of time left. When we will introduce new Rogue GPUs, I will update this article too.

  • Excellent.

    It would be great to also know the local memory and register file sizes.

    I just want to know what’s in the box.

    • Your Brad Pitt is amazing. I’ve asked the guys to reply.

    • Hi Allan,

      We expose 16KB of programmer addressable local memory where the API permits. As for the RF size, it’s core dependent and a healthy size. We scale back number of threads in flight depending on temp allocation in the USC program.

      Rys

  • Excellent article.

    It would be great to also know the local memory and register file sizes.

    I just want to know “what’s in the box”. (Get it?)

    • Your Brad Pitt is amazing. I’ve asked the guys to reply.

    • Hi Allan,

      We expose 16KB of programmer addressable local memory where the API permits. As for the RF size, it’s core dependent and a healthy size. We scale back number of threads in flight depending on temp allocation in the USC program.

      Rys

  • LM

    Hi Alex,
    What about the PowerVR GR6500? Where is it? And at which level performance is placed at comparing with the other ones?
    Cheers
    LM

    • Good point, I guess I should add that in even though it is part of the Wizard family (the tables above are Rogue-only).

      Come back later today and you will see it included.

      Regards,
      Alex.

    • I’ve now updated the article to include ray tracing GPUs too.

      • LM

        Thank you! 🙂

  • LM

    Hi Alex,
    What about the PowerVR GR6500? Where is it? And at which level performance is placed at comparing with the other ones?
    Cheers
    LM

    • Good point, I guess I should add that in even though it is part of the Wizard family (the tables above are Rogue-only).

      Come back later today and you will see it included.

      Regards,
      Alex.

    • I’ve now updated the article to include ray tracing GPUs too.

      • LM

        Thank you! 🙂

  • krishfr1

    How much gigaflops hexa-core PowerVR Series6XT GPU delivers

  • krish

    How much gigaflops hexa-core PowerVR Series6XT GPU delivers

  • Jeff

    Hi Alex, thank you for sharing this information. I’m confused with regards to PVRIC. Can you please elaborate on all the low-level details?
    On a mobile device:
    -The texture is stored in main memory. Is the texture data itself lossless compressed?
    -Or, is PVRIC used for transferring the texture data from main memory to the texture cache? Does PVRIC compress the texture data real-time, send the data over the bus, then decompress real-time, and write to texture cache?
    How does PVRIC fit into render-to-texture?
    Is the texture data (which contains the render output) lossless compressed?
    Or is PVRIC just used for transferring the GPU render output to the texture data with less memory bandwidth? The more details the better.
    Thanks,
    Jeff

    • Q1: It depends, textures provided by an application such as a game
      are typically provided in a lossy compressed format such as PVRTC by the
      developer. Formats such as PVRTC allow for high compression ratio with high quality (in the case of PVRTC as low as 2bpp) but are generated offline by a content creation tool. In cases where a developer does not deliver a
      pre-compressed texture the hardware can apply the PVRIC lossless compression thus reducing the bandwidth usage while maintaining perfect quality.

      Q2: Yes, PVRIC is a lossless compression technology which sits
      between the GPU and memory, any textures or render targets which are normally uncompressed e.g. RGBA8888 buffers, will be sent through the lossless compression to reduce the memory bandwidth and power consumption in the fabric and memory subsystem.

      Q3: These will be compressed using PVRIC on the tile write out by the harware, on read back (usage as texture or even by the display) they will be decompressed.

      Q4: Do you mean memory footprint e.g. size in memory? If so this is unchanged as it’s a lossless compression technique and we cannot guarantee compression rate also we have to support modification of resources over time.

      Q5: Yes, The main aim of lossless compression in hardware is to reduce bandwidth and power.

      Hope this helps.

      Regards,
      Alex.

      • Jeff

        Thanks Alex!

  • Jeff

    Hi Alex, thank you for sharing this information. I’m confused with regards to PVRIC. Can you please elaborate on all the low-level details?
    On a mobile device:
    -The texture is stored in main memory. Is the texture data itself lossless compressed?
    -Or, is PVRIC used for transferring the texture data from main memory to the texture cache? Does PVRIC compress the texture data real-time, send the data over the bus, then decompress real-time, and write to texture cache?
    How does PVRIC fit into render-to-texture?
    Is the texture data (which contains the render output) lossless compressed?
    Or is PVRIC just used for transferring the GPU render output to the texture data with less memory bandwidth? The more details the better.
    Thanks,
    Jeff

    • Q1: It depends, textures provided by an application such as a game
      are typically provided in a lossy compressed format such as PVRTC by the
      developer. Formats such as PVRTC allow for high compression ratio with high quality (in the case of PVRTC as low as 2bpp) but are generated offline by a content creation tool. In cases where a developer does not deliver a
      pre-compressed texture the hardware can apply the PVRIC lossless compression thus reducing the bandwidth usage while maintaining perfect quality.

      Q2: Yes, PVRIC is a lossless compression technology which sits
      between the GPU and memory, any textures or render targets which are normally uncompressed e.g. RGBA8888 buffers, will be sent through the lossless compression to reduce the memory bandwidth and power consumption in the fabric and memory subsystem.

      Q3: These will be compressed using PVRIC on the tile write out by the harware, on read back (usage as texture or even by the display) they will be decompressed.

      Q4: Do you mean memory footprint e.g. size in memory? If so this is unchanged as it’s a lossless compression technique and we cannot guarantee compression rate also we have to support modification of resources over time.

      Q5: Yes, The main aim of lossless compression in hardware is to reduce bandwidth and power.

      Hope this helps.

      Regards,
      Alex.

      • Jeff

        Thanks Alex!