Though the first PowerVR Series 6XT-equipped products have only recently launched – including the unexpectedly powerful iPad Air 2 – the development cycle for SoCs and the realities of IP licensing mean that Imagination is already focusing on GPU designs for late 2015 and beyond. Just as one design reaches consumer hands the next generation gets completed, and the SoC integration work begins.

Taking place this week are Imagination Technologies’ Chinese idc14 and Imagination Summits developer events. While Imagination holds these events in multiple countries over the year, the Chinese event is in many respects the most important from a hardware standpoint. With the bulk of SoC GPU licensees headquartered in the Asia-Pacific region – firms such as Allwinner, Rockchip, and Samsung – Imagination’s Chinese event is perhaps their biggest customer event and consequently an important venue for product announcements. Again this backdrop Imagination will be using this week’s events to announce the next generation of PowerVR GPUs, PowerVR Series7.

PowerVR Series7 is the the successor to Imagination’s current PowerVR Series 6XT lineup of GPUs. Like Series 6XT, Series7 is composed of two variants, Series7XT for the high end and Series7XE for the low-end, and in turn each contains a number of individual configurations. Ranging from half a shader cluster (USC) to 16 clusters, Imagination is seeking to cover virtually the entire range of SoC-equipped devices, from high-end IoT/wearables to tablets, set top boxes, and even HPC severs.

From an architectural standpoint Series7 will be a further iteration on Imagination’s Rogue architecture, which was first used in 2012’s Series6. With each generation Imagination has further tweaked and expanded their designs to improve performance/efficiency and to cover new use cases, and for Series7 the story is much the same. This year Imagination has sat down with us to give us an overview of what’s new and changed in their architecture for Series7, so let’s dive right in.

PowerVR GPU Comparison
  Series7XT Series7XE Series6XT Series6XE
Clusters 2 - 16 0.5 - 1 2 - 8 0.5 - 1
FP32 FLOPs/Clock 128 - 1024 32 - 64 128 - 512 32 - 64
FP16 FLOPs/Clock 256 - 2048 64 - 128 256 - 1024 64 - 128
Pixels/Clock (ROPs) 4 - 32? 2 - 4? 4 - 16 2 - 4
Texels/Clock 4 - 32 1 - 2 4 - 16 1 - 2
OpenGL ES 3.1 3.1 3.1 3.1
Android Extension Pack / Tessellation Yes Optional Optional No
Direct3D Base: FL 10_0
Optional: FL 11_1
FL 9_3 FL 10_0 FL 9_3
OpenCL Base: 1.2 EB
Optional: 1.2 FP
1.2 EB 1.2 EB 1.2 EB
Architecture Rogue Rogue Rogue Rogue


PowerVR Series7 Architecture

From an architectural standpoint Imagination is already starting in a strong position for Series7 with the Rogue architecture. With the Rogue USCs implementing a modern shader pipeline, there’s no innate weakness to the design that requires correction. However as is the case for all SoC GPUs, there is a constant need to deliver better power efficiency and space efficiency, as these are the primary factors limiting overall performance and fabrication improvements alone can’t deliver all of the necessary gains. For this reason Imagination has continued to iterate on the Rogue architecture for Series7 to further improve its efficiency and resulting performance.

Outside of the underlying architecture however, there is also the need to deliver new features to keep up with modern APIs, developer demands, and of course the competitive landscape. In that respect Series6XT is a bit more dated; while it supports OpenGL ES 3.1 its base configuration (by far the most common) does not have the hardware features to support the more extensive Android Extension Pack, and for that matter it also lacks the features necessary to support Direct3D feature level 11. For these reasons Series7 will also be responsible for delivering feature improvements to Imagination’s GPU lineup to keep it up to date with the latest standards.

Looking at the overall architecture then (with an emphasis on 7XT), what we find is still very much Rogue in nature and is called as much by Imagination. While various blocks have been upgraded or overhauled in some manner, there is only a single new block. Available on the base configuration of the 7XT and as an option for the 7XE it is the Tessellation Co-Processor. Exactly as the name describes it, the Tessellation Co-Processor is hardware block responsible for and working in conjunction with the Vertex Data Master to implement full tessellation support. The tessellator itself is fixed function for power efficiency reasons, with hull and domain shading handled through shading hardware. The addition of tessellation hardware along with the standard inclusion of ASTC support are the major functional changes that enable Android Extension Pack support on the base Series7XT over the base Series6XT.

For the other blocks, Imagination has implemented improvements all throughout the architecture. The geometry performance of the Vertex Data Master (geometry frontend) has been doubled to alleviate bottlenecking there. Meanwhile the Compute Data Master has been upgraded as well to allow it to setup wavefronts more quickly (up to 300% faster), which is especially helpful for quickly processing large numbers of small kernels, something Imagination tells us was more common than expected.

Finally the Coarse Grain Scheduler has also been upgraded in conjunction with the USCs. Primarily focusing on reducing inter-tile dependencies, Series7 can now more frequently issue work to idle USCs that in Series6/XT/XE were waiting on other USCs to finish their work before the whole block moved on. With fewer dependencies, idle USCs can now be issued work from other sources or move on to their next tile in a larger number of circumstances.

Diving into the Series7 USC, what we find is again largely similar to Series6XT. The number of FP16 and FP32 ALUs and resulting floating point operation throughput is unchanged, however the Special Function Unit (SFU) has received a pair of changes. First and foremost, the SFU can now natively handle FP16 operations along with FP32 operations, whereas the 6XT SFU would promote everything to FP32. By offering native FP16 execution, Imagination is able to avoid wasting power by not doing unnecessary higher precision work on FP16 data sets. Keep in mind that SFU operations are already relatively expensive, so native FP16 special functions should have a tangible impact on power consumption. Meanwhile though it’s drawn as a single SFU in Imagination’s logical diagrams, I suspect that part of this change is that Imagination has implemented separate FP16 and FP32 SFUs as part of the existing FP16 and FP32 ALU blocks, in which case there are actually 2 SFUs (though just like the ALUs you can only use one at a time).

Speaking of utilizing, the second SFU enhancement has to deal with when it can be used. Starting with Series7, SFU operations can now be co-issued with ALU operations, allowing for both blocks to be used at once as opposed to one or the other on 6XT. Now to be clear here only SFUs can be co-issued, and wavefronts can only use either the FP16 or FP32 ALUs (and not both at once), but there is now a degree of co-issue capability within a USC that was not available before. Imagination tells us that SFUs were coming up in code more than expected, and as a result adding co-issue capabilities would improve performance.

To accomplish this, Imagination has expanded their instruction set to enable co-issue functionality along with further improving performance. New bundled/fused instructions have been added, which are what trigger the co-issued SFU. These fused instructions also allow for certain common sequences that are issued over multiple instructions to instead be issued as a single fused instruction, which in turn reduces code size slightly and potentially allows for these operations to be performed in fewer cycles.

Meanwhile, exclusive to Series7XT is optional support for FP64 operations. If the FP64 is included in the exact 7XT core licensed, each pipeline gets a single FP64 ALU, which allows them to process up to 2 FLOPs/USC/clock.

Finally, while not a graphics feature pre-se, Series7 will be introducing one more feature to the family. A base feature in 7XT and optional to 7XE will be GPU support for hardware security zones, which uses virtualization technology to create up to 8 zones that are fully isolated from each other.

Within the mobile space application sandboxing is already common, and indeed this functionality is already present on a number of CPUs. However in the case of security zones that are only supported on the CPU, the zone separation essentially has to be emulated on the GPU, requiring a full task flush and reload of the entire GPU in order to switch between tasks. Besides not being performant, software enforced security is functionally less robust than hardware enforced security and in turn means the GPU can in theory be used to attack other zones.

Consequently for Series7 Imagination is adding security zone support to their hardware to go along with the security zones already supported with CPUs. From a practical standpoint what we’re looking at is the capability to do better application sandboxing to keep applications from getting out and touching other parts of the system. This is something of a mixed bag for users since sandboxing can be used for both good and evil. Hardware zones can be used to secure certain high-profile applications (banking, health, Apple Pay, etc), but said zones are also responsible for enabling stronger DRM on video content and hardening the system against jailbreaks in cases where direct root access is not allowed by the manufacturer.

Series 7XT & Series 7XE
Comments Locked


View All Comments

  • darkich - Monday, November 10, 2014 - link

    Actually, there is no comparison, considering that HD 5000 sucks 3 times more power.
    In an unrestricted environment, this should absolutely demolish Intel GPU, even the new architecture brought with the Core M.

    But the Maxwell Tegra GPU looks even worse for Intel.
  • darkich - Monday, November 10, 2014 - link

    It really will be interesting to see what happens to Core M if Intel decides to continue using PowerVR in Atom lineup.. Intel's own integrated graphics are no match at all in a given power envelope
  • Alexvrb - Monday, November 10, 2014 - link

    Intel decides which design to implement... if they want to intentionally use fewer clusters, they can. If they want to limit max GPU clocks and willfully deploy a gimped IMC to starve it for bandwidth, they can. They'll make sure Atom still slots in below higher-end Core solutions.

    What would be more interesting is if they were to implement a full-blown Series 7 setup in some of their higher-end chips. 16 clusters with aggressive clocks would definitely be interesting. But it'll never happen.
  • darkich - Tuesday, November 11, 2014 - link

    But that's the thing, the sole purpose of Atom chips is to compete on the most competitive chip environment there is - battling ARM in an effort to get some ground in mobile.

    If Intel intentionally cripples Atom just to stay bellow the Core M, then it can continue to watch ARM chips reigning supreme.
  • ET - Tuesday, November 11, 2014 - link

    I'd really love to see Intel using a high performance core for tablet CPU's. I know Intel plans to improve on Bay Trail's GPU performance, but I think we need something really good. (Then again, using PVR might result in driver related problem.)
  • przemo_li - Tuesday, November 11, 2014 - link

    They aren't.

    They have their own tech, and they are sticking too it.
    (Hint, they use FLOSS drivers for Android, you can check code repos to see whats coming).

    They still have some good arguments for themselfs:
    1) They are still kings of node process.
    2) They have open source gpu drivers. (Game devs do not need to sit in front of black box, guessing why their code is so slow!)
    3) They still have huge cash stockpile.

    I'm not saying that 1-3 mean that they will win lots of designs, but they can wait for their turn.
  • djgandy - Monday, November 17, 2014 - link

    2) Yeah they know why its slow. Because its running on an Intel GPU.
  • przemo_li - Tuesday, November 11, 2014 - link

    Intel GPU have (in iris configs) 500 mb of on die cache.

    Can't do on smarphone.
  • TheinsanegamerN - Tuesday, November 11, 2014 - link

    First of all, iris pro has 128MB of cache, not 500MB. Second, you are comparing a chip that pulls ~55 watts to a gpu used in sub 5 watt chips. not even a close comparison. Third, if this powervr 7 can hit 300 GFLOP, then it will already be a third of the way to meeting the fastest version of iris pro (832 GFLOP), and heck, the A8X already is a fourth of the way there with 231 GFLOP. Fourth, it;s called a smartphone, not a smarphone.
  • przemo_li - Wednesday, November 12, 2014 - link

    Correct 128mb.

    But still that mean unachievable performance.
    (Not saying that Intel can actually at their 22nm process, squeeze that into smartphones.)

Log in

Don't have an account? Sign up now