Curious About The Cpu

[MrDowntempo]

I'm still itchin' to get my hands on my 2nd batch pandora. But in the meantime I wanted to ask how the CPU stacks up against the 1ghz snapdragon that is in all the latest greatest android phones. I don't know much about ARM processors, but I do know that you can't compare AMD and Intel CPUs on mhz alone and I imagine that holds true for these CPUs as well.

Just curious, thanks =)
MrDowntempo

 

[Mr B]

Clock for clock they are fairly similar, being based of ARMv7-based Cortex-A8 groundwork. It's down to the stuff around the chips to make up for the difference, really.
B!

 

[Exophase]

Word on the street is that Scorpion (CPU in Snapdragon) is generally a slightly better performer than Cortex-A8, but it's impossible to say when we know incredibly little about it, except that its pipeline is probably a little longer (which is probably a negative, not a positive). All we really know is that it'll be better at some NEON operations since it has 4-way 32-bit float instead of the 2-way in Cortex-A8, and it'll be better at scalar floating point since it has a pipelined VFP unit.

 

[Aurekana]

Word on the street is also that the GPU in the snapdragon is less powerful than the PowerVR GPU in the OMAP3. Whether this would negate the clockspeed advantage of the snapdragon is up in the air at the moment, afaik right now.

 

[Exophase]

Word on the street is also that the GPU in the snapdragon is less powerful than the PowerVR GPU in the OMAP3. Whether this would negate the clockspeed advantage of the snapdragon is up in the air at the moment, afaik right now.

Oh, that's more common knowledge. We know a lot more about AMD Z430/Adreno than we know about Scorpion (go see i.MX51 documentation for instance), and it's pretty clear SGX530 has the advantage. Although I don't know what it's clocked at - the CPU being at 1GHz doesn't say anything about what the GPU is clocked at.

Anyway, he asked about the CPU >_>

 

[Elanzer]

AFAIK based off a few benchmarks on the net, the OMAP3 is about 20% faster per clock than the Snapdragon, so at 850mhz it should perform about the same as a 1ghz Snapdragon. The SGX 530 GPU in the OMAP3 is also apparently more capable than the one in the Snapdragon, but I've only seen this in word and not any comparable results.

Basically, if you overclock your Pandora to 800-900mhz like most people are getting for their results, it will perform about the same.

 

[Exophase]

AFAIK based off a few benchmarks on the net, the OMAP3 is about 20% faster per clock than the Snapdragon, so at 850mhz it should perform about the same as a 1ghz Snapdragon. The SGX 530 GPU in the OMAP3 is also apparently more capable than the one in the Snapdragon, but I've only seen this in word and not any comparable results.

Basically, if you overclock your Pandora to 800-900mhz like most people are getting for their results, it will perform about the same.

Reference?

 

[darkblu]

frankly, i don't know where all this '530 is better than the z430' comes from.

 

[Exophase]

frankly, i don't know where all this '530 is better than the z430' comes from.

At its core Z430 is 1 pixel and 4 depth per clock, where SGX530 is 2 pixels, 8 depth. TBDR is of course going to be typically more efficient than early-Z, which in Z430's case strongly promotes a Z pre-pass. I kind of wonder if it even has a stencil buffer, given I can't find mention of it anywhere.

ALU strength could be stronger, it's hard to tell. Looks like Z430 has one ALU vs two USSEs, but can issue two vec4 and one scalar per cycle. Of course, it's unknown if this really means say, 2 4-way FMACs per cycle, or if it's just one ALU operation and something else like a move or transpose (and unknown if multiply/add is fused). At the very least, the USSE format of optimizing for vec-4 at lowp instead of float seems more well suited for this target and better scaling.

 

[darkblu]

At its core Z430 is 1 pixel and 4 depth per clock, where SGX530 is 2 pixels, 8 depth. TBDR is of course going to be typically more efficient than early-Z, which in Z430's case strongly promotes a Z pre-pass. I kind of wonder if it even has a stencil buffer, given I can't find mention of it anywhere.

it does. stencil is mandatory to the standard, its availability is only a matter of context configs. just like the SGX, z430 has packed depth+stencil. as regarding the number of ROPs, more of those is all nice until you become ALU-starved.

ALU strength could be stronger, it's hard to tell. Looks like Z430 has one ALU vs two USSEs, but can issue two vec4 and one scalar per cycle. Of course, it's unknown if this really means say, 2 4-way FMACs per cycle, or if it's just one ALU operation and something else like a move or transpose (and unknown if multiply/add is fused). At the very least, the USSE format of optimizing for vec-4 at lowp instead of float seems more well suited for this target and better scaling.

lowp hardly cuts it for anything beyond color blending. don't forget that same ALU has to do your vertex work too, where lowp is clearly inadequate. a single USSE is vec2 at midp, so while the two in the 530 can compete somewhat with the z430 there, the latter obliterates them at highp, which is where most vertex work is at. but that's ALUs only, the register files - particularly the uniforms, are notably shallower on the 530 (per thread) - 4 times so for the fragment shader, which could put an extra skew on the balance between your vertex and fragment work.

then come the TUs - even though both parts have a single TU, i'm yet to see a 53x that appears to do AF (which the z430 does).

anyhow, i hope to have some proper (not android-beaten) comparison charts soon, involving a few of the present SoC GPUs, and the 530 and z430 will surely be there.

 

[Exophase]

Yeah, ALU has to do the vertex load, which I hear is around 10% of the ALU workload on current handheld games. Hardly compelling for optimization. Color blending, on the other hand, accounts for an awful lot more. Packed depth plus stencil is more of a side note for SGX, given that it's just the resolve format. Dunno about Z430 here.

Shallower register file per thread to me suggests shallower threads on the Z430. How much register space per thread is really necessary for this workload level?

Anisotropic I'll give you, but I wonder how many are even turning it on...

 

[darkblu]

Yeah, ALU has to do the vertex load, which I hear is around 10% of the ALU workload on current handheld games. Hardly compelling for optimization.

current handheld games are hardly an indicator of 'normal games' workloads. how many of those current handheld games have any depth-only/stencil-only passes, say for dynamic shadow casting (where the shadow entities generation is purely vertex work)? how many of those do multi-pass (rather inevitable if you mean to do fancy stuff with such small files)?

Color blending, on the other hand, accounts for an awful lot more.

actually, texturing normally accounts for the most part in that category of software you're referring to, and there the 530 has no advantage over the z430.

Packed depth plus stencil is more of a side note for SGX, given that it's just the resolve format. Dunno about Z430 here.

likely the same on the z430, given it's a tiler itself. i was just mentioning the level of formal support - i.e. it formally saves you a renderbuffer in your fbo, which may or may not actually save you memory management work behind the scene, scatter/gathers at resolve, etc.

Shallower register file per thread to me suggests shallower threads on the Z430. How much register space per thread is really necessary for this workload level?

depends what you do. for basic skinning techniques, for instance, you'd need 3x the # of bones for the skeleton in the uniforms file of the vertex shader, which makes skeletons of 64 bones virtually impossible on the 53x (read: those would come at the cost of draw call break-ups). but let's say that's too much to ask for from something like a handheld. the general question is, when you do your fancy illumination (maybe not today, but likely tomorrow), you are going to try to maximize the lighting work per pass (as deferred shading, with its appetite for bandwidth, is still a far shot in the future of handhelds), and there you normally get ~4x uniforms per light in the fragment shader. at 64 uniforms worth of fragment file, that immediately caps you at 16 lights as theoretical maximum. not bad per se, but you'd saturate your uniforms with light source data alone.

Anisotropic I'll give you, but I wonder how many are even turning it on...

well, you can't turn on something which is not there (in the predominant architecture).

 

[Exophase]

current handheld games are hardly an indicator of 'normal games' workloads. how many of those current handheld games have any depth-only/stencil-only passes, say for dynamic shadow casting (where the shadow entities generation is purely vertex work)? how many of those do multi-pass (rather inevitable if you mean to do fancy stuff with such small files)?

And I'm not sure "normal game" workloads are hardly what we should be talking about when evaluating current (or, slightly last-gen, rather) mobile GPUs. Is this really relevant? Of course, for depth/stencil only it'd probably be nice to reuse transformed geometry altogether, and if you really do require full scene passes you're kind of hurting the tiler strengths..

actually, texturing normally accounts for the most part in that category of software you're referring to, and there the 530 has no advantage over the z430.

How is this an "actually" to color operations being more predominant in shader ALUs than vertex ones? Besides that, given the trend towards far more ALUs than TMUs I'd tend to disagree. Of course, when I say "color operations", I'm really talking about a lot of per-pixel math, where lowp is good for more than just colors (normals, for instance).

likely the same on the z430, given it's a tiler itself. i was just mentioning the level of formal support - i.e. it formally saves you a renderbuffer in your fbo, which may or may not actually save you memory management work behind the scene, scatter/gathers at resolve, etc.

I wonder if that's actually true though, given that Z430's tile cache is 4x32-bit SRAM, not exactly optimized for storing 32-bit depth with 8-bit stencil per pixel.

depends what you do. for basic skinning techniques, for instance, you'd need 3x the # of bones for the skeleton in the uniforms file of the vertex shader, which makes skeletons of 64 bones virtually impossible on the 53x (read: those would come at the cost of draw call break-ups). but let's say that's too much to ask for from something like a handheld. the general question is, when you do your fancy illumination (maybe not today, but likely tomorrow), you are going to try to maximize the lighting work per pass (as deferred shading, with its appetite for bandwidth, is still a far shot in the future of handhelds), and there you normally get ~4x uniforms per light in the fragment shader. at 64 uniforms worth of fragment file, that immediately caps you at 16 lights as theoretical maximum. not bad per se, but you'd saturate your uniforms with light source data alone.

I still don't get why you're even talking about the "likely tomorrow" effects for IP that's already obsolete, especially given the pace the handheld releases. Are we seriously going to talk about 16 lights with something that has this few ALUs? The space restrictions seem appropriately matched to the computational capabilities, unless you want to make slideshows..

well, you can't turn on something which is not there (in the predominant architecture).

Indeed; but I wonder what's bothering to turn it on when it is there.

 

[darkblu]

And I'm not sure "normal game" workloads are hardly what we should be talking about when evaluating current (or, slightly last-gen, rather) mobile GPUs. Is this really relevant? Of course, for depth/stencil only it'd probably be nice to reuse transformed geometry altogether, and if you really do require full scene passes you're kind of hurting the tiler strengths..

normal games on tiny screens is what the handheld market is constantly being promised by the industry - you can't neglect that if you're striving for a piece of that market. so, back to said normal games: there are entire classes of effects/algorithms where you can't reuse your vertex work (I brought up dynamic shadowing on purpose), and hurting or not, you may need to occasioanlly revert to multipass if your shading effect does not fit your files.

How is this an "actually" to color operations being more predominant in shader ALUs than vertex ones?

in the same way vertex workload is being examined in current handheld games - we are looking for true-to-life GPU pipeline workloads. you say 'current handhelds ALU workload is 1/10 in fragment's favor', and i reply 'your current handhelds fragment workload is not in the ALU at all'.

Besides that, given the trend towards far more ALUs than TMUs I'd tend to disagree. Of course, when I say "color operations", I'm really talking about a lot of per-pixel math, where lowp is good for more than just colors (normals, for instance).

the trend towards far more ALUs than TMUs is in that same 'normal games' context which you are so reluctant to consider. otherwise, simple rendering scenarios have always been bound by texturing capabilites and ROPs.

I wonder if that's actually true though, given that Z430's tile cache is 4x32-bit SRAM, not exactly optimized for storing 32-bit depth with 8-bit stencil per pixel.

the packed format is 24/8 across all architectures i've seen.

I still don't get why you're even talking about the "likely tomorrow" effects for IP that's already obsolete, especially given the pace the handheld releases. Are we seriously going to talk about 16 lights with something that has this few ALUs? The space restrictions seem appropriately matched to the computational capabilities, unless you want to make slideshows..

the most dominant piece of tablet on the market is 53x-based, it was only recently released, and it's already seeing its share of 'normal games' downports/original titles. then, there are plenty of contemporary handhelds deviced based on the omap3 & snapdragons. tech turnaround times in the handheld segment are not your desktop tech turnaround times; the fact TI are touting omap4 today, does not mean you'll go out and buy an omap4 handset by this evening. sure, there's one 540 device on the mark already, and it seems to beat handily everything else, but let's not get carried away with 'already obsolete' talk of things that constitute 99% of the current market. tomorrow's handheld games are being written on today's hw base.

 

[Exophase]

normal games on tiny screens is what the handheld market is constantly being promised by the industry - you can't neglect that if you're striving for a piece of that market. so, back to said normal games: there are entire classes of effects/algorithms where you can't reuse your vertex work (I brought up dynamic shadowing on purpose), and hurting or not, you may need to occasioanlly revert to multipass if your shading effect does not fit your files.

Normal games on tiny screens is far removed from what current hardware can actually do, regardless of what anyone is promising.

in the same way vertex workload is being examined in current handheld games - we are looking for true-to-life GPU pipeline workloads. you say 'current handhelds ALU workload is 1/10 in fragment's favor', and i reply 'your current handhelds fragment workload is not in the ALU at all'.

It just strikes me as two completely different things. You talked a lot about ALU strength, and I'm saying that where ALU matters it's preferable to have faster lowp (like USSE1x2 vs Z430's shader does) vs faster highp. I'm pretty skeptical about what you're saying, that fragment workload is dominated by the TMU - it would seem to me that for any reasonable per pixel lighting you will easily have a scenario with more than 2:1 ALU to TMU.. and you're saying that the ratio is actually less than that. I'm not so much citing the trend towards FAR more ALUs than TMUs as I am ANY preference towards ALU at this level.

the packed format is 24/8 across all architectures i've seen.

Missed the point, 128KB SRAM is the tile memory, not resolve target. You were the one claiming that the depth/stencil format would be the same as SGX here, ie 32-bit floating point depth internally. Lacking specific reference to Z430 having this capability I'm going to remain in doubt. Its tile memory is better optimized for the packed format directly.

the most dominant piece of tablet on the market is 53x-based, it was only recently released, and it's already seeing its share of 'normal games' downports/original titles. then, there are plenty of contemporary handhelds deviced based on the omap3 & snapdragons. tech turnaround times in the handheld segment are not your desktop tech turnaround times; the fact TI are touting omap4 today, does not mean you'll go out and buy an omap4 handset by this evening. sure, there's one 540 device on the mark already, and it seems to beat handily everything else, but let's not get carried away with 'already obsolete' talk of things that constitute 99% of the current market. tomorrow's handheld games are being written on today's hw base.

SGX535 != SGX530. With all of your emphasis on TMUs I'm surprised you can consider this. When talking about the future of handheld gaming I don't really see the need to emphasize hardware with only 1 TMU. SGX535 is current, SGX530 and Z430 are at least becoming obsolete.

Tech pacing in the handheld world is getting much more aggressive. People are now by and large willing to accept substantial new smart phone updates every year from the same vendor. If you compare rate of improvement and adoption five years ago you'll see a marked difference now. You can probably partially blame Apple for this. I think OMAP4 and contemporaries will be adopted much more quickly than OMAP3 was, although the Tegra 2 delays are off-putting. You can actually buy an OMAP4 device right now, but that's pretty moot and probably not up for consideration ;p

 

[darkblu]

It just strikes me as two completely different things. You talked a lot about ALU strength, and I'm saying that where ALU matters it's preferable to have faster lowp (like USSE1x2 vs Z430's shader does) vs faster highp. I'm pretty skeptical about what you're saying, that fragment workload is dominated by the TMU - it would seem to me that for any reasonable per pixel lighting you will easily have a scenario with more than 2:1 ALU to TMU.. and you're saying that the ratio is actually less than that.

well, i was not talking about per-pixel lighting. when i said 'current handheld games', i assumed the average title found on apple's app store, etc. did you mean actually per-pixel lighting when you originally mentioned the vertex/fragment ALU disparity? if so, you might be getting dangerously close to 'normal games' waters ; )

anyhow, back to the ALU subject. your position is that sgx's ALU park of 2x (4-way lowp vector / 2-way midp / 1 scalar highp) is fundamentally better model for the medium, than z430's 2x 4-way + scalar highp. i say sgx's model is clearly more power-envelope-conscious, while also more oriented towards the current-gen of handheld titles (i.e. more emphasis on lowp ALU fragment work), but it's not 'fundamentally better', not in the long run, not at varying power budgets, etc. it may allow for smaller transistor budgets for the register files / larger register files (ironically, not the per-thread case on the 53x, but i think that was a conscious trade-off they made at some point to allow more threads in flight), but it comes with its own prices tag, like the need for a comprehensive set of type-convertion ops to service all those formats (and their frequent application), a clear performance disadvantage at anything that cannot get away with lowp (normals may or may not fit into lowp, depending on what you intend to do with them afterwards), and generally is a more case-constrained approach than a homogeneous, sufficiently-wide vector ALU as found in the z430 (i.e. of throughput 2 vector ops).

Missed the point, 128KB SRAM is the tile memory, not resolve target. You were the one claiming that the depth/stencil format would be the same as SGX here, ie 32-bit floating point depth internally. Lacking specific reference to Z430 having this capability I'm going to remain in doubt. Its tile memory is better optimized for the packed format directly.

indeed, i missed it. if that was your original point, then yes - most likely z430 and sgx differ there. after all that high-precision depth in the sgx is a transient format that never gets exposed to the user. the moment you need it for your purposes, it becomes same ol packed format. so, to backthread to the original argument then, i doubt sgx offers anything more than 8 bit stencil internally, so z430 is good there.

SGX535 != SGX530. With all of your emphasis on TMUs I'm surprised you can consider this. When talking about the future of handheld gaming I don't really see the need to emphasize hardware with only 1 TMU. SGX535 is current, SGX530 and Z430 are at least becoming obsolete.

my emphasis on TMU was again in the context of 'current crop of handheld games'. TMU advantage nonwithstanding, 535 offers the exact same programming model as the 530. if some shader had issues fitting into 530's programming model, it would continue to have the same on the 535. otherwise if i really wanted to emphasize z430's advantage in the TMU department over the 530 i'd have delved into a point-by-point TMU comparison. yes, z430 has the better TMU, but let's just leave it at that.

Tech pacing in the handheld world is getting much more aggressive. People are now by and large willing to accept substantial new smart phone updates every year from the same vendor. If you compare rate of improvement and adoption five years ago you'll see a marked difference now. You can probably partially blame Apple for this. I think OMAP4 and contemporaries will be adopted much more quickly than OMAP3 was, although the Tegra 2 delays are off-putting. You can actually buy an OMAP4 device right now, but that's pretty moot and probably not up for consideration ;p

hmm. by an omap4 device you don't mean the evaluation kit, do you? : )

 

[Exophase]

well, i was not talking about per-pixel lighting. when i said 'current handheld games', i assumed the average title found on apple's app store, etc. did you mean actually per-pixel lighting when you originally mentioned the vertex/fragment ALU disparity? if so, you might be getting dangerously close to 'normal games' waters ; )

To be honest, I don't know exactly where the bar is for current handheld games, but it seems like a waste to even have fragment shaders without pushing any sort of per-pixel lighting. Maybe you can give me an indication of what the expected fragment workload is ALU-wise. As for the current selection on the app store, I imagine many of these are plain old OGL ES 1.1.

It would be kind of bad if handheld gaming doesn't mean per-pixel lighting in the "usual" case now, since even 3DS is going to feature it (albeit via fixed function)

anyhow, back to the ALU subject. your position is that sgx's ALU park of 2x (4-way lowp vector / 2-way midp / 1 scalar highp) is fundamentally better model for the medium, than z430's 2x 4-way + scalar highp. i say sgx's model is clearly more power-envelope-conscious, while also more oriented towards the current-gen of handheld titles (i.e. more emphasis on lowp ALU fragment work), but it's not 'fundamentally better', not in the long run, not at varying power budgets, etc. it may allow for smaller transistor budgets for the register files / larger register files (ironically, not the per-thread case on the 53x, but i think that was a conscious trade-off they made at some point to allow more threads in flight), but it comes with its own prices tag, like the need for a comprehensive set of type-convertion ops to service all those formats (and their frequent application), a clear performance disadvantage at anything that cannot get away with lowp (normals may or may not fit into lowp, depending on what you intend to do with them afterwards), and generally is a more case-constrained approach than a homogeneous, sufficiently-wide vector ALU as found in the z430 (i.e. of throughput 2 vector ops).

Indeed, it isn't really a clear cut comparison. I guess we can both agree that both approaches have their advantages and disadvantages and an overall valuation is going to depend enormously on what matters to you and how you approach things. That probably goes for a lot of the differences (early-Z has its benefits too, I'd much rather use it if fragment discard were necessary) and it was probably not warranted for me to say SGX530 is a clear winner over Z430. Driver implementations out in the wild have probably distorted this; as you suggest things seem held back in Android (vs ie, iPhone).

I still wonder exactly what those two vector ops are; all things considered given the VLIW architecture it probably is one mov/permute and one math. I don't think the type conversion ops for SGX cost very much, especially if they don't saturate.

indeed, i missed it. if that was your original point, then yes - most likely z430 and sgx differ there. after all that high-precision depth in the sgx is a transient format that never gets exposed to the user. the moment you need it for your purposes, it becomes same ol packed format. so, to backthread to the original argument then, i doubt sgx offers anything more than 8 bit stencil internally, so z430 is good there.

SGX is 8-bit stencil internally like you say. All of that's true, regarding export, but the advantage of a 32-bit float depth buffer vs a 24-bit fixed one (presumably, or possibly 24-bit float?) can't be denied.

my emphasis on TMU was again in the context of 'current crop of handheld games'. TMU advantage nonwithstanding, 535 offers the exact same programming model as the 530. if some shader had issues fitting into 530's programming model, it would continue to have the same on the 535. otherwise if i really wanted to emphasize z430's advantage in the TMU department over the 530 i'd have delved into a point-by-point TMU comparison. yes, z430 has the better TMU, but let's just leave it at that.

There are advantages aside from AF?

hmm. by an omap4 device you don't mean the evaluation kit, do you? : )

I mean Blaze, and much to TI's discredit I don't think it can really be called an evaluation kit given the lack of documentation and board exposure. On the other hand, as a self contained device with monitors and keyboards and something any random joe can purchase it really can be legitimately called an expensive, limited run mobile device (kinda like the Pandora.. just kidding, put down those torches). Not really in a drastically different class from any other mobile device.

 

[darkblu]

To be honest, I don't know exactly where the bar is for current handheld games, but it seems like a waste to even have fragment shaders without pushing any sort of per-pixel lighting. Maybe you can give me an indication of what the expected fragment workload is ALU-wise. As for the current selection on the app store, I imagine many of these are plain old OGL ES 1.1.

yep. in those titles ALU fragment work constites mainly of 'texture combiner' -type of ops - a few lowp vector muls and adds, doing essentially modulation and blending. the rest is all texturing.

Indeed, it isn't really a clear cut comparison. I guess we can both agree that both approaches have their advantages and disadvantages and an overall valuation is going to depend enormously on what matters to you and how you approach things. That probably goes for a lot of the differences (early-Z has its benefits too, I'd much rather use it if fragment discard were necessary) and it was probably not warranted for me to say SGX530 is a clear winner over Z430. Driver implementations out in the wild have probably distorted this; as you suggest things seem held back in Android (vs ie, iPhone).

agreed. that was more or less what i meant with my original remark.

I still wonder exactly what those two vector ops are; all things considered given the VLIW architecture it probably is one mov/permute and one math. I don't think the type conversion ops for SGX cost very much, especially if they don't saturate.

i don't know either. i really need to sit and properly scrutinize that little gpu. it's not like it's not sitting on my desk :/

SGX is 8-bit stencil internally like you say. All of that's true, regarding export, but the advantage of a 32-bit float depth buffer vs a 24-bit fixed one (presumably, or possibly 24-bit float?) can't be denied.

not denying it at all. high precision depth checks are good, and IMGTEC can afford to go silly with those, at no cost.

There are advantages aside from AF?

support for a vector-friendly compression scheme (3dc) and volume textures are two other things that immediately jump to mind.

I mean Blaze, and much to TI's discredit I don't think it can really be called an evaluation kit given the lack of documentation and board exposure. On the other hand, as a self contained device with monitors and keyboards and something any random joe can purchase it really can be legitimately called an expensive, limited run mobile device (kinda like the Pandora.. just kidding, put down those torches). Not really in a drastically different class from any other mobile device.

ah, balze.. yes. those things are never cheap. well, unless you're nvidia and give out gdc discount coupons ; )

 

[Aurekana]

Don't know if the above discussion has made this point moot, but Anandtech recently did a review comparing the OMAP 3430, the OMAP 3630, and the Snapdragon.

http://www.anandtech.com/show/3826/motorola-droid-x-thoroughly-reviewed/5

 

[darkblu]

Don't know if the above discussion has made this point moot, but Anandtech recently did a review comparing the OMAP 3430, the OMAP 3630, and the Snapdragon.

http://www.anandtech.com/show/3826/motorola-droid-x-thoroughly-reviewed/5

not meaning to diss anand, but benchmarking those gpu's the way it was done in the article - ie. through ES 1.1 benchmarks and legacy software, is like benchmarking cpus by running a foreign architecture bogomips test on an emulator running on each of those cpus. it's more a benchmarks of the emulator, than of anything else in that setup.