Qualcomm's lower-end chips with OpenGL ES 2.0 and Scorpion CPU

Sunday 15th February 2009, 06:40:00 PM, written by Arun

Qualcomm has announced new chips that integrate their proprietary Scorpion CPU (ala Cortex-A8) and ATI's OpenGL ES 2.0 GPU (which they now own). They're on TSMC's 45nm process, but unlike some of their other chips they do not integrate RF. That is, if the other ones did in the first place.

The exciting part of this is obviously that it's a big step in the direction of making superscalar CPUs and OpenGL ES 2.0 GPUs more mainstream in the handheld market, although these chips are not likely to be extremely cheap either given that the Scorpion CPU is quite expensive (larger than the Cortex-A8, performance between the A8 and the A9 apparently) and they also integrate things like 21 to 42Mbps HSPA+.

It is unclear what is the implementation of ATI's OpenGL ES 2.0 IP in these chips; it is likely to be similar to Snapdragon2 (which is focused towards netbooks and has a dual-core Scorpion CPU) but there are no details as to what that actually looks like. Both Snapdragon and MSM7850 had a single-pipeline variant (with 1 TMU, 1 ROP, a shader core with 6 ALUs, etc.) but perhaps that has changed by now, since newer variants of mini-Xenos were supposed to be more flexible and efficient at higher pipeline counts.

As we said in the introductory paragraph, this news makes it unclear whether Qualcomm's so-said 'single chip solutions' on 45nm were really single chip. Back in the 65nm era, their so-called single chips really had 2 (if not 3) chips; for example, the QSC6270 was really a multi-chip package with a MSM6246 and RF/analogue chip or chips. Since QTR8610 integrates 3G RF, Bluetooth, GPS and audio codecs, it would be tempting to say that their previous 45nm single-chips were simply MCPs with a similar (although not identical) analogue chip.

In itself, this doesn't really matter a lot. This kind of thing matters more in the low-end. However, Qualcomm has often seemed to lag behind in terms of 'digitizing' RF/analogue circuitry, and their rapid announcement of 45nm single-chip solutions made it seem as if they had suddenly caught up on everybody. Now, it's harder to say for sure; if they already had the RF blocks to integrate on 45nm, why go back to a multi-chip solution in devices that aren't even very high-end? Because that integrated RF really wasn't that good? That's possible, but it would be even more bizarre. Who knows at this point... We'll see what we can find out.


Discuss on the forums

Tagging

qualcomm ± amd, mini-xenos, 45nm


Latest Thread Comments (70 total)
Posted by Arun on Tuesday, 24-Mar-09 13:52:54 UTC
The next-gen Imageon is quite a performance leap, to say the least, see http://www.linleygroup.com/Newsletters/LinleyMobile/lm090303.html - "The new MSM8260 doubles the main specifications of the MSM7230, pushing the data rate to 28Mbps, the video resolution to 1080p, the 3D performance to 88 million polygons per second." - I know for sure that is a comparable figure to the 22M triangles/s of Snapdragon1; I don't know how much the fillrate numbers improve, but I wouldn't be surprised if it was just as much.

And thanks convergedw, I guess I missed that - it does seem credible though, even slightly better than I assumed... :)

Posted by Wishmaster on Tuesday, 24-Mar-09 14:55:39 UTC
Quoting Ailuros
SGX540 silicon codenamed 'Ares' was presented in late 2008. I'd hardly call that "next generation".
But it won't appear in devices earlier than 2011 so for today it can be considered next generation.

Quoting Arun
The next-gen Imageon is quite a performance leap, to say the least, see http://www.linleygroup.com/Newslette.../lm090303.html - "The new MSM8260 doubles the main specifications of the MSM7230, pushing the data rate to 28Mbps, the video resolution to 1080p, the 3D performance to 88 million polygons per second." - I know for sure that is a comparable figure to the 22M triangles/s of Snapdragon1; I don't know how much the fillrate numbers improve, but I wouldn't be surprised if it was just as much.
Impressive. Good to see that they are taking it all seriously.

Posted by Simon82 on Wednesday, 25-Mar-09 14:28:35 UTC
They seems to build chipset that should be used to move the world but nowdays there's no use of them. Just see at the MSM6245 low budject chipset on some phones that could make lot of multimedia stuff even 3D related but even the o.s. are not optimized on it.

Posted by Ailuros on Thursday, 26-Mar-09 09:14:36 UTC
Quoting Wishmaster
But it won't appear in devices earlier than 2011 so for today it can be considered next generation.
OMAP4 is truly slated to enter mass production in H2 2010. It still won't be the only IMG IP that might be available in 2011.

Posted by Wishmaster on Sunday, 24-May-09 19:32:52 UTC
Arun what do you think about that?
http://www.youtube.com/watch?v=nF3m2RD_GWE
If this is true then snapdragon is capable of displaying 720p h.264 high profile video at 2mbps.

If so then snapdragon is very powerful cause even when streaming that video browser was quite responsive.

Posted by Arun on Sunday, 24-May-09 21:08:31 UTC
I can believe that, yes - remember that Snapdragon has a very powerful DSP as well as a 128-bit NEON-like engine. So even if they don't have CABAC accelerators, they can do it in software although it's obviously going to take more power than otherwise. In fact I heard someone from NV said they could decode YouTube's HD videos on Tegra too. I'll have to check to make sure about Tegra though, I'm not sure what they'd run CABAC on...

Posted by Wishmaster on Sunday, 24-May-09 21:21:18 UTC
Quoting Arun
I can believe that, yes - remember that Snapdragon has a very powerful DSP as well as a 128-bit NEON-like engine. So even if they don't have CABAC accelerators, they can do it in software although it's obviously going to take more power than otherwise.
Maybe they combine DSP with NEON so it can playback 720p h264 HP but if not needed NEON is powered off to lower the power consumption (after all they worked very hard on making NEON as power efficient as possible) and only DSP is used?
Quote
In fact I heard someone from NV said they could decode YouTube's HD videos on Tegra too. I'll have to check to make sure about Tegra though, I'm not sure what they'd run CABAC on...
It would have to use ARM11 core but would that be enough...

Posted by Wishmaster Qualcomm SnapDragon at 28nm this time next year? on Friday, 03-Jul-09 18:54:11 UTC
I found this (http://www.electronicsweekly.com/blogs/david-manners-semiconductor-blog/2009/06/qualcomm-and-altera-by-pass-32.html) few minutes ago and I thought it is worth posting here!

If all turns out how it is supposed to we may expect huge announcement just before MWC 2010. Probably new msm9xxx series consisting of single and multi core solutions(wouldn't be surprised if it would mean 1,5GHz-2GHz Scorpion CPU with improvements), better graphics than msm8xxx and battery life that should satisfy all peoples needs! Combine it with wm7 or android 3.0 and we have a winner!

Wonder how much ahead of competition(?) they will be if it succeeds...

Posted by no_way on Thursday, 26-Nov-09 23:02:34 UTC
Quoting Captain Chickenpants
Pretty much, there are several layers at which you could accelerate things under OpenMax.
You could write an OpenMax IL component which is pretty much writing a full encoder that accelerates (or decelerates :-) )the whole encode process.

Or you could write OpenMax DL primatives which accelerate specific parts of the encode/decode process e.g. DCT / Motion Estimation. It is this that you would probably look at doing with a DSP or a specialised processor instruction set.

CC
How many real OpenMax DL implementations are actually out there ? Theres one from ARM, but for x86, MIPS, PPC ?

Posted by Manabu on Monday, 30-Nov-09 22:58:16 UTC
Quoting Arun
The justification for NEON is also pretty damn pitiful:

[software compatibility]
As the thread was resurrected, I'm also posting here:

http://x264dev.multimedia.cx/?p=142

ARM support and 260% speed increase so far back then. They think they can get 4~5x speed increases in ARM using SIMD. That is only one example of one program. This shows that the silicon area and compatibility worries pay-off.

If only the rest of ARM environment gave more importance for standardization... developers need stability and standards in order to take their time developing or improving one application.


Add your comment in the forums