ST-Ericsson Nova A9600: dual-core ARM A15, PowerVR Series 6

Yeah, sorry, no real news.

The obvious assumption is an A9600 based Xperia Play "PlayStation" phone late next year, but ST-E of course gives a "no comment" to the question. Sony Ericsson is a big customer for them, though.

http://www.itproportal.com/2011/03/31/exclusive-st-ericsson-integrate-nfc-features-its-platforms/

Considering it's a gaming phone, the GLBenchmark scores for the first Play don't indicate it'll be an exceptional performer in Android games. Higher frame rates would actually matter to the target demographic of a game phone, another good reason for SE to choose ST-E's chip next time around.

On the matter of quad A9 versus dual A15, ST-E said their pick yielded "higher and more predictable peak performance and energy efficiency". nVidia will be moving on to Tegra 4 anyway by then, so I doubt there'll be debate.

http://blog.stericsson.com/blog/2011/02/application-processors/who-needs-all-that-speed/

As for the marketing of the next generation of application processors, all this GFLOPs talk will be lending itself to a lot of GPGPU/OpenCL PR when it comes to the mobile market.
 
Yeah, sorry, no real news....

Or you didn't read between the lines in your 2nd link ;)

In any case the Nova A9600, A9540, A9500 are not just dual core processors, they are indeed very sophisticated heterogeneous multi-core systems including up to 10 dedicated processor cores for imaging, video, 2D graphics, 3D graphics, sensor control and power management.

Up to 10 hm?

2 CPU cores
1 imaging
1 video
1 2D
1 sensor control
1 power
-----------------------------
7 out of 10
 
I assumed offloading to lower power CPU cores, but innovation must be within its implementation or somewhere else within the SoC's power management to achieve their goal. Also, I could see video being counted as two cores.
 
Yeah, sorry, no real news.

The obvious assumption is an A9600 based Xperia Play "PlayStation" phone late next year, but ST-E of course gives a "no comment" to the question. Sony Ericsson is a big customer for them, though.

That might give Sony some problems, it would mean a gaming handset with sony/playstation branding would be out that had MUCH better performance than their dedicated portable less than a year after its launch. (agreed of course that it wouldn't have the same screen size or proper control inputs)
 
Yeah, sorry, no real news.

The obvious assumption is an A9600 based Xperia Play "PlayStation" phone late next year, but ST-E of course gives a "no comment" to the question. Sony Ericsson is a big customer for them, though.

After going through all the trouble of "convincing" the major smartphone game companies to optimize their games to the Adreno 205 in the first Xperia Play?

I doubt that.
 
After going through all the trouble of "convincing" the major smartphone game companies to optimize their games to the Adreno 205 in the first Xperia Play?

I doubt that.

I don't see that being a major issue, as most of the the big companies writing for the "play" will be writting for other platforms too, which are either totally PowerVr or include PowerVr in the platform, thus the games will have already been optimised for PowerVr.
 
After going through all the trouble of "convincing" the major smartphone game companies to optimize their games to the Adreno 205 in the first Xperia Play?

I doubt that.

Performance is obviously not going to be a concern, so I'll presume you're referring to portability concerns.

You can see some of the extensions here:

http://stackoverflow.com/questions/3881197/opengl-es-2-0-extensions-on-android-devices

Most of the extensions are for debugging and/or profiling. The only real sticking points I see are the AMD compressed texture formats and GL_QCOM_tiled_rendering. GL_QCOM_writeonly_rendering is probably safe to ignore.

The change in texture compression will probably require recompressing the textures, which is not really a big deal so long as a similar size can be achieved without degradation in quality. GL_QCOM_tiled_rendering can probably be implemented with scissoring, although I doubt games even rely on this much and it can possibly just be ignored too. Either way it wouldn't necessarily be much of a problem to add to the driver's transparently.
 
Presentation from todays ST investors meeting:-

http://phx.corporate-ir.net/Externa...9Mzc5MjA3MXxDaGlsZElEPTQyODAzM3xUeXBlPTI=&t=1 (this is just the ST-ericsson relevant slides)

Not much new in there. but a few points:-

NovaThor L9600 chipset based on A9600 not available until 2012-2013. (sampling this year).

A9540 is quoted as being x3 U8500 in graphics. In the original announcement it was quoted as being "up to x4".
http://www.stericsson.com/press_releases/NovaThor.jsp

I wonder might this be another implementation of Mali400MP3 ?

U8500 has design wins with 5 leading smartphone manufacturers, ramping up H2 '11.


The full ST investors presentation is also available, which might also be interesting to some, and suggests that Mali is also designed into some of their high-end controllers.
http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9OTQ1MDZ8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1
 
1/2 OT: What are the differences between the U8500 and the Samsung Exynos?
For me they look nearly the same on the paper.
 
I talked with ST-E at MWC11, and my understanding is it's definitely a lot more than talk. However, ST-E was obviously taken by surprise like everyone else, and they had zero driver development on Windows Phone 7 (they do have experience with WinCE on older chips though). So my guess is that they've got 12 "design ins" but those will only become "design wins" if they execute on the driver front (and if Nokia does decide to go ahead with those specific models for other reasons unrelated to ST-E). Two big questions are GPU support (because right now Windows Phone 7 requires DXTC which Mali-400 doesn't have) and dual-core (Windows Phone 7 is still based on the WinCE6 kernel which doesn't support multicore). Maybe the start of fragmentation sadly...

As for Microsoft deciding silicon partners rather than Nokia, don't be silly. Nokia executives should be fired immediately (even more than they already deserve to be) if they didn't insist on a contract that gave them that kind of influence.
 
But given that they standardized on Qualcomm for the first gen devices, dosent it make more sense for Microsoft to go for Qualcomm dual cores for the next gen phones?
 
At some point, Microsoft will need to certify other SoC suppliers so that their device partners have a real market for choice in design.
 
The texel fill of this thing is still hard for me to get my head around. Obviously, the clock speeds are very high, and I assume this is using a low power graphics core for display compositing like the OMAP4470 to save the Rogue GPU from powering up much of the time (implying the possibility for a very very high clock ceiling for the GPU), but still... over 5G tex/sec base!?

I'm guessing the family of Rogue cores will include just one variant, which will serve as a building block for MP configurations, per line of feature support -- a line for Halti and DirectX 10+ and a line for DirectX 11+. But even the base cores must have quite a few TMUs, which I guess targeting 28nm and below affords.
 
Last edited by a moderator:
These numbers imply either 8 TMUs @ ~667MHz or 12 TMUs @ ~450MHz, and given the 2.5GHz frequency on the CPU and some of the power saving tricks I know about, I'd much rather bet on the former. It also implies 40 flops/TMU, which may seem strange but could be easily explained in at least three different ways: 1) 5-way FMAC with 4 shader cores per TMU, 2) 4-way FMAC with 4 shader cores per TMU + interpolation (on or off shader core?), 3) 4-way FMAC with 5 shader cores per TMU. All of them (and more) are perfectly plausible, so let's leave it at that.

Compared to the SGX544s in OMAP5, that's more than twice the GFlops per TMU, and also significantly improved API support (OpenGL ES Halti and OpenCL Full Profile with on-chip local memory from what I've heard on the grapevines).

http://www.beyond3d.com/content/articles/112/

Either case scenario of the 2 Arun proposes implies 4 TMUs/core. He's suggesting either MP2@667MHz or MP3@450MHz. If each core truly has 4 TMUs it's definitely high time we see some AF in embedded devices. On chip local memory is far more tickling as a shred of information though than anything else.
 
Since the Mali400 doesn't support DXTC, I wonder if that doesn't dictate the U8500 can only be used in Symbian models?
They've been claiming "Gigahertz processors" in future symbian devices for a while, even after the February 11th Elopcalipse.
 
Since the Mali400 doesn't support DXTC, I wonder if that doesn't dictate the U8500 can only be used in Symbian models?
They've been claiming "Gigahertz processors" in future symbian devices for a while, even after the February 11th Elopcalipse.

I'm sure lack of DXTC in hardware won't lock out phones from WP7 if Nokia really wants to deploy it this way. It'll just mean that the textures are decompressed in the drivers, same with paletted textures on a lot of GPUs today.
 
Back
Top