Check out my performance tests of the iPad 2 and 3 with just under 10 million polygons:
[media][/media]

Check out my performance tests of the iPad 2 and 3 with just under 10 million polygons:
[media]

[/media]

"6-8fps... just about real time," bwah?

Ok but there's just a tiny problem with your demonstration. It's the same teapot repeated about four thousand times. Instancing is very misleading in terms of performance, perhaps having an actual scene drawn instead would be a better proof of concept...

Ok but there's just a tiny problem with your demonstration. It's the same teapot repeated about four thousand times. Instancing is very misleading in terms of performance, perhaps having an actual scene drawn instead would be a better proof of concept...

I think the test was to see just how many polys could be rendered at once. Without instancing it usually becomes a bandwidth issue before it becomes a poly count issue.
So unless I misunderstood the point, instancing was an excellent way to measure the raw poly pushing power of the iPad.

I think the test was to see just how many polys could be rendered at once. Without instancing it usually becomes a bandwidth issue before it becomes a poly count issue.
So unless I misunderstood the point, instancing was an excellent way to measure the raw poly pushing power of the iPad.[/quote]
It's a double-edged sword, as instanced polygons can be cached by the GPU which can then render them much, much faster than a for the same amount of polygons, even assuming infinite bandwidth.

Pretty cool nonetheless of course. I didn't know the iPad had that much horsepower. Sorry if I sounded blunt and derogatory, it wasn't my intention

It's a double-edged sword, as instanced polygons can be cached by the GPU which can then render them much, much faster than a for the same amount of polygons, even assuming infinite bandwidth.

I think this might actually be a stickier point than you imagine.

For starters, OpenGL ES 2.0 has no explicit support for instancing. No ARB_draw_instanced, etc. So any instancing is of the old fashioned 'stick data in buffer and render variety'.

Given that we can only performa software instancing on iOS, does it make a huge difference whether we render 1 model or many? My gut feeling is no. In either case, all the vertex data should be resident in vertex buffers, so the only costs are binding buffers, and uploading modelview matrices. Matrix upload needs to occur in either case, so all we save is a few buffer binds - and given that one tends to pack multiple models into a single buffer on iOS, and that binds are not all that expensive... M guess would be that it doesn't make a huge difference.

Just like the iPhone 4(S), pushing polys themselves won't be much of a problem. The trouble is that the device is going to be so badly limited by pixel rate that you'll want to drag as much vertex pipeline as possible on to the CPU instead.

Thank you for sharing Josh. Have you investigated batch length behavior?

Just a comment on performance on the Ipad itself - I'm sure I remember hearing those kind of figures for GPUs *many* years ago, which is more than enough time for that to propagate down to smaller devices. E.g., people claim 90 million polygons per second the PowerVR SGX540 used in even small smartphones (e.g., http://smartphoneben...-arm-cortex-a9/ ). So I wouldn't be particularly surprised by this. Not to mention that millions of polygons isn't always a good indicator of performance.

I can't help feeling that this falls into the problem where netbooks are often viewed as "crap for games" because they can't run the latest AAA games, whilst a similarly sized tablet is viewed as amazing, because it can run 10 year old games...

Don't get me wrong, nothing wrong with your demo And the question of how best to optimise 3D code for the kind of GPUs (rather than the more usual AMD/NVIDIA/Intel combination) is indeed interesting and useful. I'm just not joining in the "wow, Ipads can do 3D" amazement. Unless of course one's initial expectation was that Ipads were completely crap ;)