http://docs.google.com/viewer?url=h.../POWERVR_SGX_Series5_IP_Core_Family_[2.3].pdfPowervr specs sheet
POWERVR SGX Series5 family Smart and feature phones
Family members SGX520/530/531/535/540/545
Triangles/sec* 7m 40m
Pixels/sec* 250m 1000m
2.6 mm2 12.5 mm2 Area (65nm process)
* Realistic, sustainable, SoC performance at 200 MHz (e.g. less In-car navigation and driver information than 50% shader load); peak performance significantly higher Electronic dashboards dependent on content and operating conditions. Ultra-mobile PCs, laptops and netbooks
http://docs.google.com/viewer?url=h...OWERVR_SGX_Series5XT_IP_Core_Family_[1.0].pdfPowerVR SGX Series 5XT specs sheet
POWERVR SGX Series5XT family Smart and feature phones
Family members
Series 5: SGX520/530/531/535/540/545
Series 5XT: SGX543/SGX543MP
Triangles/sec* 7m 140m
Pixels/sec* 250m 4000m
2.6 mm2 32 mm2 Area (65nm process)
* Realistic, sustainable, SoC performance at 200 MHz (e.g. less than 50% shader load); peak performance significantly higher dependent on content and operating conditions.
Those specs are well above the Tegra2. I'm looking forward to a SOC that provides the 545 pvr chip to see an eye to eye comparison.
Hope that's ok to share. It was publicly listed..
For future reference PowerVR's PDF download section: http://www.imgtec.com/downloads.asp#WhitePapers
If those are like the specs imgtec used to put out back in the day, they're taking into account the tile based deferred rendering of their chips. While of course it would offer some benefit, they typically marketed it at 5x to 10x the performance, whereas actual performance was 2x to 3x.
So that's 250mpixels base, and then with tbdr they go up to 1.25gpixels or maybe even 2.5gpixels. With their max specs listed, that probably means their top end chip does between 400mpixels to 800mpixels base, and realistically we could expect 2x to 3x that in actual performance.
Same for the polys really, though I often remember hearing that high polygon counts were a weakness of a tbdr, primarily because it's difficult to sort the polygons in a way that gets the full performance benefit.
I'm not sure of the specifics, but a tbdr basically collapses down the 3d image into a 2d one, and only renders what is visible. Normally fillrate and polygon counts would be eaten up by overdraw. This gives basically free multi-texturing and anti aliasing on a tbdr, and a big boost to usable fillrate (until you get into pixel shaders perhaps).
Unfortunately, in the case of polygon rendering, I think the tech only works with front to back sorted polys (ie, the polygons are sorted in order of increasing depth from the view).
I don't know the specifics of why that is bad either, but since the tbdr tech relies on what is visible, having the polys sorted in a random or non-optimal order could break it. It might even mean that highly efficient static geometry is difficult to use on a tbdr, forcing it to use slower dynamic geometry. The other option is just to ignore the problems and render things incorrectly, which is part of the reason tbdrs failed on the desktop.
And in the case that the polygons ARE sorted front to back, then both nvidia and ati possess hidden surface removal tech to boost their polygon and fillrate counts. Because of how few apps are rendered like this, nvidia and ati don't boost their specs by including mention of it.
So basically, I'd say the fillrate counts imgtech is given out are overrated (unless you want to assume they're including high levels of anti aliasing in that fillrate, in which case it's a misleading way to say free anti aliasing). The polygon counts are practically outright lies, if my understanding of the limitations of the technology are correct.