JayFoxRox said:
Most likely as he said its in OGLES1.x mode with pre-made shaders. And the default would be gouraud shading.
That doesn't have anything to do with what I asked. Even with ES 1.1 you still provide separate parameter lists for vertexes, colors, normals, texture coordinates, etc. I was asking if he was interleaving these lists.
JayFoxRox said:
Look again, there is a light gray box behind the text which is behind all lines but "LightSwitch", the last row included in the box is "LightingSwitch", just look at the green difference.
I didn't see this. Still, it's the text itself being blended, not the quad in the background.
JayFoxRox said:
I also asked for this, but after thinking about it, I figured that there are so many influencing factors that it shouldn't matter.
Why shouldn't it matter? That quad span is at least increasing fillrate demands by some amount.
JayFoxRox said:
We can't really tell how parallel the CPU and SGX work in the iPhone,
What work is the CPU supposed to be doing here exactly, except sending a few draw calls? I assume that the VBO data is static.
JayFoxRox said:
nor would any performance interested person use the premade shaders because shaders are usually case optimized. Uber-Shaders probably don't work too well with the limited hardware we have I think.
But in this case the pixel shading is just gouraud, and I think it's safe to assume that SGX has fixed function interpolation units doing most of the work for this. Perspective correct interpolation seems like a lot to burden a shader with, although we know that blending is being handled by the shader. Another question worth asking then is if blending is enabled for all those other polygons.
JayFoxRox said:
Do you have some informations on how the SGX processes shaders exactly? What sort of instructions exist? How many cycles does each take etc?
Nothing beyond the hints given, but it's hard to imagine the USSEs being dominated by more than straight pixel copies off the interpolation units to whatever framebuffer conversion units. I doubt USSE performance is the bottleneck here, unless the shader is doing way more than we realize.
JayFoxRox said:
//Edit: I read that Apple claims that degenerated Tri-Strips can be a few times faster than Tri-Lists, this should be obvious, however, one of the reasons is that its not only better in terms of bandwidth, but also that some triangles get discarded in an early-out test if they wouldn't be visible. So it SHOULD matter how big the polygons are.
Why should it be obvious that degenerate tri-lists should be faster than tri-lists, assuming that both are indexed? With 2byte indexes vs vertexes that are probably at least 16 bytes it's hard to imagine a big bandwidth win, and we know he's using vertex indexing. But this is assuming that his vertexes are properly shared in the first place. The numbering doesn't make that clear. Assuming they mostly are that'd mean somewhere around 30-50 MB/sec bandwidth, and if they aren't three times that. Plus 11MB/sec for the indexes themselves. I would hope that this isn't where the bottleneck is, but who knows. There's probably a lot of extra bandwidth from the SGX reading back the tiled data, although this is supposed to be compressed.
Frustum and face culling should be performed regardless of if the triangles were submitted as lists or strips, in fact, I doubt by this point there'll be a difference between how the two are presented. This process, as well as tiling, should also be performed in parallel with rendering. I don't see what any of this really has to do with polygon size, except that bigger (visible) polygons get thrown into more bins. I expect that not to matter that much if the tiling is happening in parallel.
I'm writing some tool for benchmarking such stuff right now and will also contribute soon.
