iPad 2

These roadmaps aren't a secret. The GPU and SoC designers continually give developmemt and business updates saying how many cores and how much performance they're targeting years out, and just knowing how much silicon gets budgeted for a GPU or CPU core coupled with industry trends makes these things easy to narrow down.

If IMG says they'll be putting PS3 graphics in your pocket within a couple years, and if ST-Ericsson quotes a mobile SoC scheduled for late 2012/early 2013 with such specs, the potential becomes a lot more real.
 
http://multiplayerblog.mtv.com/2011/03/11/ipad-2-360-infinity-blade-dev/

Chair gave an interview about this iPad 2 update and are surprising frank in saying that despite all the complaints about the lack of Retina Display that is actually "the best news for gamers ever". It obviously provides more power for effects rather than pixel pushing. Perhaps with that quote, Apple can sell the lack of Retina Display as a feature. :smile:

That is a bit misleading. Even today on iOS you don't have to render at the native screen resolution: you can render at something less and ask the compositor (CoreAnimation) to scale the content.

Quite a few games on the iPhone 4 rely on this to continue rendering at 320x480 without increasing fill demands. 320x480+4xMSAA can often look almost as good as 640x960 w/o MSAA*, and is much friendlier on fill rate. Developers can pick intermediate points as well: rendering at 720x480 is also not uncommon for games on the iPhone 4.

* highly dependent on the specific content, of course.
 
High-end smartphones have been getting the same SoCs as high-end ARM tablets.
Why would that change for the next 2 years?
Well, the mass-market high-end ARM tablet market is pretty much not even a year old at this point. And we were speculating about devices that might get released in Q1/2013...

AFAIK a few SoCs have already been announced with high-end versions intended for tablets. I'm not saying that smartphones won't get SoCs from the same generation as tablets, but they will either be significantly lower clocked, feature/core stripped or delayed (power/process optimizations, die shrink etc.). E.g. I don't think we will see the same 40nm quad-core Tegra 3, running at the same frequency, at the same time in smartphones as in tablets, if at all.
 
Last edited by a moderator:
Cell level CPU depends upon whether the workload considered is really that of a CPU or of something extended like a vector processor.
 
That is a bit misleading. Even today on iOS you don't have to render at the native screen resolution: you can render at something less and ask the compositor (CoreAnimation) to scale the content.

Quite a few games on the iPhone 4 rely on this to continue rendering at 320x480 without increasing fill demands. 320x480+4xMSAA can often look almost as good as 640x960 w/o MSAA*, and is much friendlier on fill rate. Developers can pick intermediate points as well: rendering at 720x480 is also not uncommon for games on the iPhone 4.

* highly dependent on the specific content, of course.
I agree on the viability of intermediate resolutions. The problem might be the lack of consumer understanding of the issue though. As soon as the iPhone 4 was released with Retina Display, it seemed that any game released after that that didn't support 960x640 was commented as lacking. Personally, it'd be great if developers offered these things as an in game option. For example, toggles for 480x320 and 960x640 and toggles for 0xMSAA and 4xMSAA maybe placed under an advanced tab. Apps already have code for both resolutions anyways to support 3rd gen devices and lower, just that Retina Display devices can't access it. The ability to have 960x480 and 4xMSAA in the app would also be forward looking to subsequent devices.


Cell level CPU depends upon whether the workload considered is really that of a CPU or of something extended like a vector processor.
In subsequent generations, the GPU looks to improve very rapidly and will grow faster than the resolution since I can't see the need for resolution increase past the next Retina Display doubling for the iPad. The iPhone already has reached it's limit. So there will be a lot of excess GPU power not needed for pushing pixels. It'll obviously be used for more graphical effects, but with OpenCL, some of it can be used for vector processing as well which will help on the Cell CPU comparison front. So in two years it might be a SGX544MP4 with 1-2 of those cores used for OpenCL.
 
Last edited by a moderator:
http://www.anandtech.com/show/4216/...ance-explored-powervr-sgx543mp2-benchmarked/1

Anand has posted GPU benchmarks of the iPad 2. The iPad 2 has more than triple the triangle throughput as the iPad and twice the Xoom. Texturing performance has increased 5 times over the iPad and the gap is even higher against the Xoom.

And well, the iPad 2 basically walks all over the Xoom and iPad 2 in the Egpyt and Pro benchmarks. Interestingly, the iPad 2 actually has the same or better performance with FSAA enabled, which is kind of strange. I'm guessing FSAA uses dedicated hardware and the A5 SoC either has a lot of extra memory bandwidth or the SGX is very bandwidth efficient with FSAA to explain the lack of performance drop with it enabled.
 
http://www.anandtech.com/show/4216/...ance-explored-powervr-sgx543mp2-benchmarked/1

Anand has posted GPU benchmarks of the iPad 2. The iPad 2 has more than triple the triangle throughput as the iPad and twice the Xoom. Texturing performance has increased 5 times over the iPad and the gap is even higher against the Xoom.

And well, the iPad 2 basically walks all over the Xoom and iPad 2 in the Egpyt and Pro benchmarks. Interestingly, the iPad 2 actually has the same or better performance with FSAA enabled, which is kind of strange. I'm guessing FSAA uses dedicated hardware and the A5 SoC either has a lot of extra memory bandwidth or the SGX is very bandwidth efficient with FSAA to explain the lack of performance drop with it enabled.

I'm surprised how badly it crushes tegra2. Anyone see any other comparison results that are less impressive?
 
I thought the SGX540, especially with newer drivers, is pretty comparable to the Tegra 2. As such, the SGX543MP2 being 2-3 times faster than Tegra 2 is to be expected.

Well the GL2 bench is pretty near 4x, but I guess the resolution difference was throwing me off.
 
http://multiplayerblog.mtv.com/2011/03/11/ipad-2-360-infinity-blade-dev/

Chair gave an interview about this iPad 2 update and are surprising frank in saying that despite all the complaints about the lack of Retina Display that is actually "the best news for gamers ever". It obviously provides more power for effects rather than pixel pushing. Perhaps with that quote, Apple can sell the lack of Retina Display as a feature. :smile:

We don't know how much games, especially games with high-performance graphics, are played on the iPad.

Retina Display for iPad may initially set back gaming graphics (until new GPUs push the bar higher) but there are many other apps. which will benefit, such as browsing, reading books and other text content, video, etc.

Seems like those other uses will outweigh whatever setback a big jump in resolution causes in games.

One thing I noticed is that there are a lot of screen sharing apps -- VNC and RDC clients of various types. Higher resolution iPad would be great for these apps., since the remote computer will often have much higher resolution than the current iPad resolution.
 
http://www.anandtech.com/show/4216/...ance-explored-powervr-sgx543mp2-benchmarked/1
Interestingly, the iPad 2 actually has the same or better performance with FSAA enabled, which is kind of strange. I'm guessing FSAA uses dedicated hardware and the A5 SoC either has a lot of extra memory bandwidth or the SGX is very bandwidth efficient with FSAA to explain the lack of performance drop with it enabled.
Oh, SGX IS very bandwidth efficient with MSAA - with tile based defered rendering this needs no extra memory bandwidth at all (under the right circumstances). That it's faster is strange though indeed, it still needs to do extra depth tests.
What I haven't seen anywhere though, how is the "MPx" part implemented? How do these cores work together? Since there's a MP4 part I guess it isn't just plain AFR. I could see the rasterization phase easily divided up between multiple "cores" (the cores just working on different tiles), but I'm not sure how that'll work for the vertex part.
 
http://www.anandtech.com/show/4216/...ance-explored-powervr-sgx543mp2-benchmarked/1

Anand has posted GPU benchmarks of the iPad 2. The iPad 2 has more than triple the triangle throughput as the iPad and twice the Xoom. Texturing performance has increased 5 times over the iPad and the gap is even higher against the Xoom.

And well, the iPad 2 basically walks all over the Xoom and iPad 2 in the Egpyt and Pro benchmarks. Interestingly, the iPad 2 actually has the same or better performance with FSAA enabled, which is kind of strange. I'm guessing FSAA uses dedicated hardware and the A5 SoC either has a lot of extra memory bandwidth or the SGX is very bandwidth efficient with FSAA to explain the lack of performance drop with it enabled.

In a TBDR, high quality AA modes might cost some area depending on implementation, but they should not affect bandwidth in any way.
 
In a TBDR, high quality AA modes might cost some area depending on implementation, but they should not affect bandwidth in any way.
That's not *strictly* true: the pixel shader must be run multiple times for every pixel that has multiple different subpixels. This implies additional texture fetches and potentially blending. Of course, that's a very small cost compared to IMRs so I'm just nitpicking... :)
 
That's not *strictly* true: the pixel shader must be run multiple times for every pixel that has multiple different subpixels. This implies additional texture fetches and potentially blending. Of course, that's a very small cost compared to IMRs so I'm just nitpicking... :)
I had MSAA in mind. In that case, why would shade more than once per pixel, no matter what the sample count?
 
I had MSAA in mind. In that case, why would shade more than once per pixel, no matter what the sample count?
Because you need to shade every triangle that covers a sample within a pixel. With n samples you can have up to n triangles within a pixel, but that only happens at triangle edges.
 
the same. Look at Sony's NGP. 133Mio Vertex. A single SGX543 reaches 35 Mio vertex. So a nice 95% scaling is possible.
Yes, but HOW is it done? If you'd want to work in parallel on the vertices (not just dumb AFR), you'd need some arbiter when generating the display lists. I'm just interested in how the "multiple GPU" scaling is done.

That's not *strictly* true: the pixel shader must be run multiple times for every pixel that has multiple different subpixels. This implies additional texture fetches and potentially blending. Of course, that's a very small cost compared to IMRs so I'm just nitpicking... :)
I agree that additional texture fetches might cause a tiny increase in bandwidth required, but as far as I can tell blending (with or without msaa) should be completely free in terms of bandwidth.
 
I agree that additional texture fetches might cause a tiny increase in bandwidth required, but as far as I can tell blending (with or without msaa) should be completely free in terms of bandwidth.
Oops, yes, that is obviously true.
 
Back
Top