PowerVR Series 6 now official

Things are as always way less complex as we'd imagine. How about A17 being nothing else but a higher A12 revision? Mediatek had announced quite a while ago that they're planning A12 SoCs this year and now we have this.

*ahem*

http://semiaccurate.com/2014/02/04/rockchip-rk3288-beats-everyone-coretex-a12-mali-t760-h-265/



Notice the "2" of the A12?

 

It couldn't be A12 because that one doesn't support big.LITTLE.
According to anandtech, the A17 is practically an A12 with support for big.LITTLE and some tweaks in the memory subsystem.

 

Anand's write-up indicates 2015 as the earliest date for the arrival of Cortex-A17 in any chipsets. This doesn't, however, explain Mediatek's early announcement of the part. They don't tend to pre-announce chipsets too long before release (6589 announced in January, available in March, 6592 announced in November, released in devices in December) so an announcement 10 or so months early would seem to be out of character!

I'd imagine some of this discussion could be moved into the new A17 thread.

 

I said a higher A12 revision; gosh then it's a renamed A12 that supports big.LITTLE who cares?

 

Is it usual to add features in revisions?

 

It's not usual either for ARM's partners to get confused as in the Rockchip example above where they weren't obviously sure what the heck they've licensed. There's a lot that's strange about that release, but it doesn't make any difference to me. If it's all about you being right I don't have that kind of agonies so yes you're right. Life goes on

 

Tomshardware have a block diagram of the MT6595, showing the gpu to be a rogue "Han" @ 600mhz.

Also says the video IP is mediatek's own.

http://www.tomshardware.com/news/mediatek-mt6595-octo-core-cortex-a17-lte,26003.html

 

That's almost 7x times more FLOPs than in the MT6589T. The Han in the MT8135 Tom's mentions should be clocked around 450MHz; at 600 you get roughly an iPad4 GLB2.7 score.

 

Anandtech " deep dive" into rogue

This brings us to today. In what should prove to be an extremely eventful and important day for our coverage and understanding of SoC GPUs, we’d like to welcome Imagination Technologies to the “open architecture” table. Imagination chosen to share more details about the inner workings of their Rogue Series 6 and Series 6XT architectures, thereby giving us our first in-depth look at the architecture that’s powering a number of high-end products (not the least of which is all of Apple’s current-gen products) and descended from some of the most widely used SoC GPU designs of all time.

http://www.anandtech.com/show/7793/imaginations-powervr-rogue-architecture-exposed

 

They're linking to an interesting article written by Rys:
http://withimagination.imgtec.com/index.php/powervr/graphics-cores-trying-compare-apples-apples
It's a must-read, IMO. Especially for those who keep comparing SGX MP cores with Rogue.

 

ROFL for the latter

In any case it obviously took a GK20A in Tegra K1 to make the cat want to come out of the bag for Imagination. And since those decisions come typically from the upper management: no need to be afraid gentlemen, the press doesn't bite and it doesn't really matter whether we find out sooner or later. It's just fucking time that some of you come out of the closet and sniff how the coffee smells in the real world.....there I said it

 

GK20A isn't what made me push for more disclosure, but it did help me make my case.

 

I never thought I'd consider NV's marketing a eulogy

 

Rys question:

http://withimagination.imgtec.com/index.php/powervr/graphics-cores-trying-compare-apples-apples

...is it possible to use those FP16 ALUs and merge 2 at a time for FP32?

 

What process node for the beastly GX6650?

 

Imagination is full of awesome engineers who would be able to do that if/when that would make sense.

Seriously though: I don't know if that's happening or not, but as far as my computer architecture knowledge goes it's not as simple as going from 2xWORD to 2xDWORD with integer operations (where, for the most part, you've got to deal with a carry bit to achieve that). So that would mean (a lot?) of extra silicon space. Again: whether it's happening or not, I don't know.

I do have some knowledge about API-level code and IMO AnandTech understates the importance of FP16 operations. It's absolutely OK to perform color-channel operations on FP16 instead of FP32. At the end of the computation you've truncating to 8 bits and only the fanciest of the fancy pixel shaders would accumulate enough error for FP32 to matter. And even there compiler can probably be smart enough and order operations with error minimization in mind. There's a reason for min precision types in HLSL:

http://msdn.microsoft.com/en-us/library/windows/desktop/hh968108(v=vs.85).aspx

 

Wouldn't you want to know though? They've gone out on a limb for a change, a wee bit more can't hurt can it?

That's a field I cannot comment on lack of any relevant knowledge.

 

Well, here's what the blog post says:

That seems to slightly contradict the diagram (i.e. 2x4 flops rather than 4x2 flops). Also the issue with sharing resources between FP16 and FP32 is that it's a ~4x difference for the multiplier's size (like FP32->FP64) not 2x.

 

Now I'm more confused than before

 

The F16 ALUs can't be combined to do higher precision. Hopefully we talk about exactly what happens inside each pipe soon, I just couldn't swing that by the powers that be before this stuff needed to be released.