PowerVR Series 6 now official

[Ailuros]

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?

 

[Deleted member 13524]

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.

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.

 

[Mariner]

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.

 

[Ailuros]

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.

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

 

[Deleted member 13524]

Is it usual to add features in revisions?

 

[Ailuros]

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

 

[tangey]

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

 

[Ailuros]

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.

 

[tangey]

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

 

[Dominik D]

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.

 

[Ailuros]

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

 

[Rys]

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

 

[Ailuros]

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

 

[Ailuros]

Rys question:

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

PowerVR G6230: two Series6 USCs – 64 FP32 ALU cores with up to 128 FLOPs per cycle – 64 FP16 ALU cores with up to 192 FLOPs per cycle. That means up to 115.2 FP16 GFLOPS and up to 76.8 FP32 GFLOPS at 600MHz.

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



http://withimagination.imgtec.com/i...ng-compare-apples-apples#sthash.t0ZRhTfo.dpuf

 

[Entropy]

What process node for the beastly GX6650?

 

[Dominik D]

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

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

 

[Ailuros]

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.

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?

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

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

 

[Arun]

Well, here's what the blog post says:

The FP16 ALUs in PowerVR Series6 GPUs are capable of up to 3 floating point operations per cycle, and we’ve improved the FP16 ALUs in Series6XE and Series6XT to perform up to 4 FLOPs per cycle

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.

 

[Ailuros]

Now I'm more confused than before

 

[Rys]

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.