TI Announces OMAP4470 and Specs: PowerVR SGX544, 1.8 GHz Dual Core Cortex-A9by Brian Klug on June 2, 2011 3:01 AM EST
- Posted in
- Cortex A9
- OMAP 4
The last time we visited TI's OMAP 4 SoC was at Mobile World Congress, there we benchmarked the LG Optimus 3D and came away decently impressed with performance even on a pre-launch device. Back then, Anand wrote that the remainder of this year and the next is going to be a heated battle for dual core and quad core SoCs fighting in the tablet and smartphone space. After today, you can add Windows 8 to that list as well. Today, TI is announcing its latest SoC, the OMAP4470, which offers a 20% increase in CPU clocks and an entirely new SGX 544GPU over OMAP4460.
OMAP4470 is architecturally very similar to OMAP4460 with a number of notable changes. First off is that 20% increase in CPU clocks from 1.5 GHz in OMAP4460 to 1.8 GHz in OMAP4470. TI's comparison point for most of the OMAP4470 specs is the OMAP4430 which has its two Cortex-A9s clocked at 1.0 GHz. The two Cortex-M3 cores remain clocked at 266 MHz for handling multimedia processing and background realtime events. The end result is an effort to both let the two Cortex-A9s remain idle for more of the time, and unburden them during heavy processing. TI feels this dichotomy of two big and fast Cortex-A9 cores for web browsing and very computationally intensive tasks augmented with two ligher weight, low power Cortex-M3 cores offers it unique power savings potential. The two Cortex-M3 cores can offload Thumb and Thumb-2 instructions, as well as some hardware multiply and divide operations from the A9s.
The real interesting change with OMAP4470, however, is a similar two-pronged approach on the GPU side of things. First, OMAP4470 moves from the PowerVR SGX540 present in OMAP4430 and OMAP4460 to a more powerful single core (MP1, if you will) PowerVR SGX544 GPU which offers 2.5x the performance of OMAP4430's SGX540.
If you recall from Anand's excellent iPad 2 GPU exploration, SGX543/544 features four USSE2 pipes each with a 4-wide vector ALU churning thorugh 4 MADs per clock. I'm reproducing his table below, but if you mentally replace SGX543 with SGX544 you get the same picture. As an aside, the difference between SGX543 and SGX544 is purely that full DirectX 9 compliance is offered in the latter, making it a possible shoe-in for future Windows 8 platforms.
|Mobile SoC GPU Comparison|
|PowerVR SGX 530||PowerVR SGX 535||PowerVR SGX 540||PowerVR SGX 543/544||PowerVR SGX 543/544MP2||GeForce ULP||Kal-El GeForce|
|# of SIMDs||2||2||4||4||8||8||12|
|MADs per SIMD||2||2||2||4||4||1||?|
|GFLOPS @ 200MHz||1.6 GFLOPS||1.6 GFLOPS||3.2 GFLOPS||6.4 GFLOPS||12.8 GFLOPS||3.2 GFLOPS||?|
|GFLOPS @ 300MHz||2.4 GFLOPS||2.4 GFLOPS||4.8 GFLOPS||9.6 GFLOPS||19.2 GFLOPS||4.8 GFLOPS||?|
If you recall the clocks for the OMAP4430, and OMAP4460, you can start to see where TI's 2.5x claim over its own OMAP4430 comes into play. Going from 304 MHz to 384 MHz is an ~25% increase in clock speed, which adds into the 200% increase in MADs per clock from the change from USSE to USSE2 going from SGX540 to SGX544. Do the math and it works out to almost exactly 2.5x.
|TI OMAP 4xxx SoC GPU Comparison|
|GPU Used||PowerVR SGX540||PowerVR SGX540||PowerVR SGX544|
|Clock||304 MHz||384 MHz||384 MHz|
The next part of what's new in OMAP4470 is inclusion of a new hardware composition system for doing display composition without taxing the SGX544. TI wouldn't disclose whose IP this is, but did acknowledge that it's from a third party and includes a dedicated 2D graphics core for compositing the entire display. Ordinarily this is done on the GPU, but TI hopes to accomplish the same composition on this hardware accelerator in a more power and bandwidth efficient manner for driving large displays while maintaining low power profile.
When big 3D applications kick in, then SGX544 powers up and takes over, but for the majority of UI paradigms, TI believes its hardware composition engine can enable power savings - analogous to the way the two Cortex-M3 cores augment the two Cortex-A9s. It's an interesting approach, and TI claims the hardware composition abstraction layer (HAL) is already completed to enable Android and other mobile OSes to leverage that acceleration immediately.
|OMAP 4470 vs. 4430 Feature List - Provided by TI|
|Two ARM Cortex A9 MPCores @ 1.8GHz per core||80% increase in Web browsing performance|
|Two ARM Cortex-M3 cores||Smart multicore processing optimized for low-power and real-time responsiveness|
|SGX544 GFX Core running at 384 MHz||2.5x overall graphics performance increase; support for DirectX, OpenGL ES 2.0, OpenVG 1.1, and OpenCL 1.1|
|Hardware composition engine with dedicated 2D graphics core||Frees GPU to manage intensive tasks; maximizes power- efficiency|
|Display subsystem||Supports as many as three HD displays and up to QXGA (2048x1536) resolution; HDMI supporting stereoscopic 3D|
|Dual-channel, 466 MHz LPDDR2 memory||Higher memory bandwidth enables rendering and compositing of multilayer content at high resolutions|
|Complete pin-to-pin hardware and software compatibility||Rapid transition and maximum re-use of investment from OMAP4430 and OMAP4460 processors|
The real hope with OMAP4470 is the ability to drive very high resolution displays as well, up QXGA (2048x1536) and maintaining HDMI 1.4a stereoscopic 3D support. TI expects OMAP4470 devices to arrive in the first half of 2012 with sampling happening in the second half of 2011.
Post Your CommentPlease log in or sign up to comment.
View All Comments
dagamer34 - Thursday, June 2, 2011 - linkThat'd be a real waste of die space. Besides, pretty much every CPU since the Core days in 2006 has had the ability to underclock itself, and the Core iX series is able to turn of entire CPUs. And while web browsing may not be that demanding, there are always little background tasks that require some CPU.
ahmedz_1991 - Thursday, June 2, 2011 - linkagree with dagamer
Shadowmaster625 - Thursday, June 2, 2011 - linka 386 with 8k of cache would consume how much of a i7-2600k die? 2%? 1%? How can that be awaste of space if it enables 10% or more power consumption reduction? You are the epitomy of stagnation in the x86 world. No facts. No numbers. Not even any intelligent estimations. You just know it wont work.
sum1guy - Thursday, June 2, 2011 - linkYou don't understand how an Intel CPU works.
You could put a 66 MHz CPU on there that create your page in 100 ms, or the 3.43 GHz CPU can create the page in 2 ms and then go to sleep. Intel looked into what you're suggesting over a decade ago, and concluded that it always makes sense to have more power than you need. When you're working on an easy task, you just finish the task faster and then power down.
Galaxie500 - Thursday, June 2, 2011 - linkThe rules are a bit different on very low power devices though. Peak power draw, as opposed to average power over time, is also important. If that 3.43GHz CPU requires a huge inrush of current during that 2ms, the battery may not be able to supply it. It may actually be better to draw a steady, lower current for 100ms, especially if it simplifies the design of the power supplies.
Klinky1984 - Thursday, June 2, 2011 - linkSeriously a 386 w/ 8k cache would be pathetically underpowered for doing anything really useful besides idling. Those two 266Mhz M3 cores probably run circles around 386. Also the i386 instruction set is antiquated as most software is now optimized for i586 & i686 sets, plus all the MMX/SSE extensions.
Now integrating a low powered Atom CPU might be more valuable, but more research in clock throttling & powergating is probably a better use of our time. A lot of idle power consumption for recent computers has been the horrible idle power of GPUs. My Radeon 4850 sucks too much power sitting idle two minor 2d/3d composition in Win XP or Windows 7. Luckily this is starting to change as GPU vendors take idle & peak power more seriously.
Zoomer - Monday, June 20, 2011 - linkNot to mention that such a heterogeneous setup would need OS support for it to work well. Sure, one could build hardware support for switching, but that will be horribly inefficient, as the hardware can only guess at the workload. Also. it'll make the already horribly complex front end (x86 decode) even more complex.
Phones are mostly idle most of the time, but it needs to perform housekeeping tasks, like checking in with the mobile network periodically. SoCs may even support that in hardware. The ARM ISA is also vastly less loaded with historical BS; they could also revise it if necessary, since the issue of backwards compatibility is really a non-issue. It'll just be a recompilation. Not so for x86. We still need to run quake, and IPX/SPX not working was the last straw.
mustafaka - Thursday, June 2, 2011 - linkThey are following the footprints on a path already innovated by the x86 world. I know there are major differences between the architectures. However they have common problems and solutions as well.
FunBunny2 - Thursday, June 2, 2011 - linkThey hardware instruction set of an Intel processor might surprise you.
mustafaka - Thursday, June 2, 2011 - linkStill even the failures of the pioneers are hints to the followers.