PowerVR Rogue Architecture

[mavere]

[URL='http://blog.imgtec.com/powervr/powervr-series7xt-gpus-push-graphics-and-compute-performance']Series7XT[/url]: improved efficiency, more clusters, more features.

Can't wait to see the future 16-cluster iPad.

 

[Ailuros]

Series7XT and Series7XE GPUs achieve up to a 60% architectural performance increase on the latest industry standard benchmarks compared to equivalent configurations of previous generation PowerVR Series6XT/6XE GPUs, maintaining and extending PowerVR’s reputation as the most efficient, highest performance, lowest power GPU. Application developers can take advantage of the significant parallel processing power in Series7 for both graphics and GPU compute tasks. Series7 architectural enhancements include:

· Instruction set enhancements including added co-issue capability, resulting in improved application performance and increased GPU efficiency

· New hierarchical layout structure that enables scalable polygon throughput and pixel fillrate improvements in addition to increased clock frequencies

· GPU compute setup and cache throughput improvements resulting in up to 300% better parallel processing performance.

If any of the IMG boys are allowed to tell: "added co-issue capability" stands for SOME FP16 & FP32 ALUs that can be run in parallel this time?

 

[Rys]

We can now co-issue either the F16 or F32 pipe with the SFU pipe. Feel free to ask a bunch of other questions about Series7 now it's announced, either in here if they're architectural or in the other Series7 thread if they're more product or market related.

 

[roninja]

I also see Alex Voica has two blog articles which also reference FP64 ALUs as optional add ons? Or are these part of the GT7900 standard package for example?

 

[Ailuros]

We can now co-issue either the F16 or F32 pipe with the SFU pipe. Feel free to ask a bunch of other questions about Series7 now it's announced, either in here if they're architectural or in the other Series7 thread if they're more product or market related.

Does that mean that you couldn't co-issue in anything prior Series7 any sort of ALU with the SFU?

 

[Rys]

FP64 is not part of the configs we announced, and there was no SFU co-issue in any 6-family Rogue.

 

[Ailuros]

FP64 is not part of the configs we announced, and there was no SFU co-issue in any 6-family Rogue.

Poof goes my theory that FP16/FP32 ALU co-issue would be the biggest part of the up to 60% boost compared to 6XT cores

 

[Rys]

The "up to 60%" thing is mostly marketing, not architectural. There are cases, depending on configuration and performance metric, where a like-for-like setup of 6XT and 7 would show over 100% improvement in Series 7. The 60% is a number we came up based on performance analysis of real content, not the base microarchitecture's capabilities.

 

[roninja]

5 configs announced yet a mention of FP64 sounds like a mid season i.e. 6 month refresh to me.

 

[Rys]

There's not really the notion of a mid life refresh for us now (note the new naming to reflect it, XT there from day zero), it's just base arch for a series plus config options, and then straight on to working on the next one.

 

[roninja]

Ok just read the Anandtech review and the HPC feature pack option.

 

[ltcommander.data]

Rys, I believe you've previously said that ASTC is quite area intensive at least compared to PVRTC. GPUs like in the A8 and Tegra K1 and the Android Extension Pack currently only claim/require LDR ASTC support. That might just be an extension exposure issue rather than the capabilities of the underlying hardware, but would there be significant area savings by just implementing LDR ASTC and not HDR ASTC? And would 3D ASTC support be even more area intensive? Your Series7XT diagrams only show LDR + HDR ASTC so is 3D ASTC not supported? Admittedly, I don't know how useful 3D ASTC is so I don't know whether its presence is important or not.

 

[Rys]

There is significant extra area in supporting the HDR variant, especially in terms of the amount of SRAM you need (if I remember correctly at least) for the decoder tables. Not really sure about 3D ASTC, but I'll do some digging about our support and its expected area increase. The main reason the HDR variant is separate though is time to market: the HDR part of the spec simply wasn't complete enough at the time architectures needed to be finalised.

 

[ltcommander.data]

Thanks for this.

I'm also curious whether the DX11/OGL4.4 feature pack includes support for tiled resources/sparse textures and/or bindless textures which are optional features of those specs but present in recent DX11/OGL4 GPUs from AMD and nVidia?

 

[Ailuros]

Thanks for this.

I'm also curious whether the DX11/OGL4.4 feature pack includes support for tiled resources/sparse textures and/or bindless textures which are optional features of those specs but present in recent DX11/OGL4 GPUs from AMD and nVidia?

It should unless there's a typo in there:

http://www.imgtec.com/news/detail.asp?ID=933

DirectX 11 Feature Pack: for customers targeting Microsoft operating systems, this pack for Series7XT GPUs provides a full DirectX 11.2 feature set, building on Imagination’s many years of market-proven support for DirectX.

 

[Grall]

What mobile GPU IP exists than Img's stuff? It's ideal for mobile, with the overdraw-free architecture they have. No wasted power on drawing invisible pixels = better battery life and higher performance.

[Moderator Edit]
This post was originally part of the Apple A8 and A8X thread. In the context of this thread it looks out of place, so be mindful that's where it was originally posted, where it fit much better.

 

[silent_guy]

What mobile GPU IP exists than Img's stuff? It's ideal for mobile, with the overdraw-free architecture they have. No wasted power on drawing invisible pixels = better battery life and higher performance.

They're still drawing the pixels, aren't they? Just not writing them to external memory?
Or do they always do Z first?

 

[BRiT]

They're still drawing the pixels, aren't they? Just not writing them to external memory?
Or do they always do Z first?

If only there was a website that had some articles on their architecture... {Article from 2001}

Though will have to see if those articles are still available after we switched the forum software over.

 

[Grall]

Or do they always do Z first?

From what I understand, PVR doesn't 'always do Z first', they do depth sorting and discard hidden surfaces entirely before drawing anything. ...Although I could easily be mistaken of course. Wouldn't be the first time.

 

[Ailuros]

From what I understand, PVR doesn't 'always do Z first', they do depth sorting and discard hidden surfaces entirely before drawing anything. ...Although I could easily be mistaken of course. Wouldn't be the first time.

If an application is early Z optimised it'll work as is on a TBDR too. I think many misunderstand a bit the entire HSR story on the PowerVR; if your game engine is idiotic enough to not give any information what's behind a wall you're facing, then it'll draw whatever there's behind it whether there's hw hsr present or not.

In the good old KYRO days I had one such dumb case in RTCW where I was walking down a practically empty corridor; turn to left framecounter extremely high (just a wall remember). If I turned to the right performance dropped significantly all of the sudden while I was facing the same damn wall as while turning left. I then asked a developer what the heck is going on and he gave me a pages long explanation how BSPs, portals, earlyZ, low level HSR and what not all work.