PowerVR Rogue Architecture

Series7XT: improved efficiency, more clusters, more features.

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

 

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?

 

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.

 

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?

 

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

 

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

 

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.

 

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

 

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.

 

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

 

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.

 

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.

 

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

 

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.

 

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.

 

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.