Performance Of The Sgx 530?


FlippantBird

Still Fresh
Joined
Feb 26, 2007
Messages
37
The impending release of the Pandora makes me want to get back into low poly 3d modeling. I would love to contribute artwork to promising community games. Wikipedia says the 530 capable of outputing 14 million polys/s. It also supports vertex, pixel and geometry shaders.

What does that mean to an artist? Without looking at other games made for the same hardware, I really don't know what level of quality I should be aiming for. Can any of the hardware gurus tell me how many polys I should use per model? (Ballpark figures are fine) What kind of performance hit would I see from using more complex shaders, such as specular maps, or normal maps? Heavy use of transparency? Is the hardware capable of realtime shadows?

Please help! I want to start now, but I really don't want to over estimate and have to redo any work, but I also want to push the hardware and make the games as visually appealing as possible.
 
That is going to depend heavily on the efficiency of the engine / project. While it'll run Q3, and possibly even more advanced engines if optimized for the hardware, an engine that isn't well written or written for a different platform and not optimized for the Pandora will require a lower set of polys.

I think the goal would be to match the general "feel" of the game. Find a project that looks interesting to you - maybe something like the DraonBallZ project, ask if they need artists, and match your artwork to what they've already produced. My 2c.
 
Well, if you want 50+ FPS, then you get 280,000 triangles per frame.
If you actually use any features like lighting, texturing, simple shaders, that will probably dip to like 100,000 triangles.
Then you add in specular shading for some things, GUI overlay, and time needed to process other shit...

Probably like 40,000 triangles per scene.
So aim low.
 
lulzfish said:
Well, if you want 50+ FPS, then you get 280,000 triangles per frame.
If you actually use any features like lighting, texturing, simple shaders, that will probably dip to like 100,000 triangles.
Then you add in specular shading for some things, GUI overlay, and time needed to process other shit...

Probably like 40,000 triangles per scene.
So aim low.

Oh crap. How deep did you reach into you ass to pull this out?
 
Last edited by a moderator:
FlippantBird said:
The impending release of the Pandora makes me want to get back into low poly 3d modeling. I would love to contribute artwork to promising community games. Wikipedia says the 530 capable of outputing 14 million polys/s. It also supports vertex, pixel and geometry shaders.

What does that mean to an artist? Without looking at other games made for the same hardware, I really don't know what level of quality I should be aiming for. Can any of the hardware gurus tell me how many polys I should use per model? (Ballpark figures are fine) What kind of performance hit would I see from using more complex shaders, such as specular maps, or normal maps? Heavy use of transparency? Is the hardware capable of realtime shadows?

Please help! I want to start now, but I really don't want to over estimate and have to redo any work, but I also want to push the hardware and make the games as visually appealing as possible.

On the new iPhone 3gs ( which is using quite a bit faster version of the same chip - SGX 535) you can realistically expect about 40 K worth of polys per frame while running at 30-40 fps.

I was able to display about 45K worth of untextured but lighted triangles running at 40 fps ( 9 counter strike source models )
http://www.warmi.net/tmp/test_vbo.png
 
Last edited by a moderator:
Butterman said:
lulzfish said:
Well, if you want 50+ FPS, then you get 280,000 triangles per frame.
If you actually use any features like lighting, texturing, simple shaders, that will probably dip to like 100,000 triangles.
Then you add in specular shading for some things, GUI overlay, and time needed to process other shit...

Probably like 40,000 triangles per scene.
So aim low.

Oh crap. How deep did you reach into you ass to pull this out?
Pretty deep. But my point is that you can't reduce a graphics card to a single number and have it mean jackshit.
 
Last edited by a moderator:
warmi said:
FlippantBird said:
The impending release of the Pandora makes me want to get back into low poly 3d modeling. I would love to contribute artwork to promising community games. Wikipedia says the 530 capable of outputing 14 million polys/s. It also supports vertex, pixel and geometry shaders.

What does that mean to an artist? Without looking at other games made for the same hardware, I really don't know what level of quality I should be aiming for. Can any of the hardware gurus tell me how many polys I should use per model? (Ballpark figures are fine) What kind of performance hit would I see from using more complex shaders, such as specular maps, or normal maps? Heavy use of transparency? Is the hardware capable of realtime shadows?

Please help! I want to start now, but I really don't want to over estimate and have to redo any work, but I also want to push the hardware and make the games as visually appealing as possible.

On the new iPhone 3gs ( which is using quite a bit faster version of the same chip - SGX 535) you can realistically expect about 40 K worth of polys per frame while running at 30-40 fps.

I was able to display about 45K worth of untextured but lighted triangles running at 40 fps ( 9 counter strike source models )
http://www.warmi.net/tmp/test_vbo.png


Cool stuff, how much overhead does the text add? Its probably some quads too, possibly lots of draw calls and it also has a texture to it. The background also contributes to the scene I guess..
Is 5 "Renderables" the amount of drawcalls? If so - which? Indexed were almost twice as fast as others in my tests. Also using a degenerated triangle strip is often pushing performance a good bit if the bandwidth is your bottleneck

//Edit: And how do you calculate your Frametime? Count FPS and then get Frametime from that (Meaning its actually counting the CPU stuff too)? Or is it just the real Frametime spent in the rendering code?
//Edit: Precission of the values? Per pixel or per vertex lighting? - Questions questions questions.. you better summarize your findings and share them in a new topic or the wiki, would be very helpful and informative :) I'm writing some tool for benchmarking such stuff right now and will also contribute soon.
 
Last edited by a moderator:
JayFoxRox said:
warmi said:
FlippantBird said:
The impending release of the Pandora makes me want to get back into low poly 3d modeling. I would love to contribute artwork to promising community games. Wikipedia says the 530 capable of outputing 14 million polys/s. It also supports vertex, pixel and geometry shaders.

What does that mean to an artist? Without looking at other games made for the same hardware, I really don't know what level of quality I should be aiming for. Can any of the hardware gurus tell me how many polys I should use per model? (Ballpark figures are fine) What kind of performance hit would I see from using more complex shaders, such as specular maps, or normal maps? Heavy use of transparency? Is the hardware capable of realtime shadows?

Please help! I want to start now, but I really don't want to over estimate and have to redo any work, but I also want to push the hardware and make the games as visually appealing as possible.

On the new iPhone 3gs ( which is using quite a bit faster version of the same chip - SGX 535) you can realistically expect about 40 K worth of polys per frame while running at 30-40 fps.

I was able to display about 45K worth of untextured but lighted triangles running at 40 fps ( 9 counter strike source models )
http://www.warmi.net/tmp/test_vbo.png


Cool stuff, how much overhead does the text add? Its probably some quads too, possibly lots of draw calls and it also has a texture to it. The background also contributes to the scene I guess..
Is 5 "Renderables" the amount of drawcalls? If so - which? Indexed were almost twice as fast as others in my tests. Also using a degenerated triangle strip is often pushing performance a good bit if the bandwidth is your bottleneck

//Edit: And how do you calculate your Frametime? Count FPS and then get Frametime from that (Meaning its actually counting the CPU stuff too)? Or is it just the real Frametime spent in the rendering code?
//Edit: Precission of the values? Per pixel or per vertex lighting? - Questions questions questions.. you better summarize your findings and share them in a new topic or the wiki, would be very helpful and informative :) I'm writing some tool for benchmarking such stuff right now and will also contribute soon.

This was just a simple test to see if VBOs actually work as advertised on the latest iPhone ... and they do as you can see ... the top image marked as VBO is the same geometry submitted using VBOs while the bottom one is using generic client arrays.
It used to make no difference on the older (GLES 1.x) iPhones but now it is huge.

Beside testing VBOs ,I didn't really care for anything else ... so all I had was just a simple directional light and 5 render calls ( 1 for the background image , 1 for the diagnostics stuff and 3 for the actual models - clustered together in 2s or 3s to avoid 0xFFFF index array limitations)

Obviously the text adds a few dozen quads but it doesn't really matter in the larger scheme of things.

FPS/Ftime is just an overall frametime averaged over I think 25 samples.
 
Last edited by a moderator:
So 40k'ish polys in a scene seems to be the best guess? I can work with that. I would still like to know the performance hit from using more expensive shaders. Anyone capable of testing please do.
 
Gonna mirror JayFoxRox on this one, can you post your shaders? SGX535 claims 28M/sec. What you're getting here is 1.819M/sec. That's not anywhere in the same ballpark. iPhone 3GS's SGX535 is probably not clocked at the speed reflecting the 28M/sec claim, but these numbers are still nothing short of pathetic, especially when you're not texturing (except the BG) and have no blending on the screen. Your pixel shader looks to just be implementing gauraud shading.

I'm slightly curious as to what you'd get using triangle strips instead of triangle lists, but vertex cache is supposed to negate that.

I think even if the clock speed is within even 1/2 what IMG advertises then this is number is shockingly low. I know that GPU manufacturers tend to exaggerate, but if something else isn't going wrong here then this looks more like straight up lying. I wonder if this is due to render to texture screen compositing in iPhone...
 
Exophase said:
Gonna mirror JayFoxRox on this one, can you post your shaders? SGX535 claims 28M/sec. What you're getting here is 1.819M/sec. That's not anywhere in the same ballpark. iPhone 3GS's SGX535 is probably not clocked at the speed reflecting the 28M/sec claim, but these numbers are still nothing short of pathetic, especially when you're not texturing (except the BG) and have no blending on the screen. Your pixel shader looks to just be implementing gauraud shading.

I'm slightly curious as to what you'd get using triangle strips instead of triangle lists, but vertex cache is supposed to negate that.

I think even if the clock speed is within even 1/2 what IMG advertises then this is number is shockingly low. I know that GPU manufacturers tend to exaggerate, but if something else isn't going wrong here then this looks more like straight up lying. I wonder if this is due to render to texture screen compositing in iPhone...

This test was ran in GLES 1.x mode using their internal shaders which presumably are reasonably optimized but that's beside the point .... I suspect the issue here is not how many triangles you can render but how many vertices you can submit for rendering - this was the bottleneck with the original iPhone (on the CPU side) and , while it is much better, it still exists to some extend on the latest device.
 
Last edited by a moderator:
Exophase said:
Gonna mirror JayFoxRox on this one, can you post your shaders? SGX535 claims 28M/sec. What you're getting here is 1.819M/sec. That's not anywhere in the same ballpark. iPhone 3GS's SGX535 is probably not clocked at the speed reflecting the 28M/sec claim, but these numbers are still nothing short of pathetic, especially when you're not texturing (except the BG) and have no blending on the screen. Your pixel shader looks to just be implementing gauraud shading.

I'm slightly curious as to what you'd get using triangle strips instead of triangle lists, but vertex cache is supposed to negate that.

I think even if the clock speed is within even 1/2 what IMG advertises then this is number is shockingly low. I know that GPU manufacturers tend to exaggerate, but if something else isn't going wrong here then this looks more like straight up lying. I wonder if this is due to render to texture screen compositing in iPhone...
I remember these number games from console systems like DC and PS2 etc back in the day. These xx M polys/sec numbers they throw around are very best case with the most favorable condidtions. Mostly they get these numbers from flat shaded triangles no more than a small number of pixels big(like 50) or so and with no other code running (such as needed for games). Obviously fill rate comes into play so they keep the polys at a distance. So technically it isn't lying, but the numbers are often VERY misleading. It is like saying a certain make of car can go 180 MPH but that is with wind to the back and going down a 30 degree hill, technically not lying but also very misleading.
 
Last edited by a moderator:
warmi said:
This test was ran in GLES 1.x mode using their internal shaders which presumably are reasonably optimized but that's beside the point .... I suspect the issue here is not how many triangles you can render but how many vertices you can submit for rendering - this was the bottleneck with the original iPhone (on the CPU side) and , while it is much better, it still exists to some extend on the latest device.

Aren't VBOs supposed to mitigate that? You shouldn't be using an awful lot of CPU now, and the SGX shouldn't be using a lot of raw memory bandwidth for fetching the vertex parameters. Especially with no tex-coord params. Are your parameters interleaved per-triangle?

MDave said:
I see a quad with transparency behind the text, so that might have an effect.

I don't see any transparency or blending. On the other hand, the text quads themselves need to have some mechanism for providing transparency. So that brings up a few questions:

- Are they done with alpha test or alpha blend?
- Are they being sent in draw calls after all the other stuff?
- If they're using alpha test, is alpha test enabled for the entire scene? I hear this could halve performance.

Maybe you can determine performance w/o the text being drawn at all?

Questions of how big the polygons are don't really come into play, w/o blending and alpha test the fill rate shouldn't exceed the screen resolution. Shaders can be the bottleneck here, so it'd also be interesting to test performance with lighting completely off. If the SGX is clocked at say, 166MHz, and there are two USSEs, then that'd mean 2161 USSE cycles per pixel per second, or about 54 per frame here. Of course vertex shading is using some percentage of that. Gouraud shading really should just use a couple pixel shader cycles at most since the linear interpolation should be done outside the shaders.
 
Last edited by a moderator:
Exophase said:
Are your parameters interleaved per-triangle?
Most likely as he said its in OGLES1.x mode with pre-made shaders. And the default would be gouraud shading.

Exophase said:
I don't see any transparency or blending. On the other hand, the text quads themselves need to have some mechanism for providing transparency.
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.

Exophase said:
- Are they done with alpha test or alpha blend?
Most likely alpha blended because they blend with the green color in the background

Exophase said:
- Are they being sent in draw calls after all the other stuff?
As they are alpha blended, yes. and..

Exophase said:
- If they're using alpha test, is alpha test enabled for the entire scene? I hear this could halve performance.
...therefore no.

Exophase said:
Maybe you can determine performance w/o the text being drawn at all?
I also asked for this, but after thinking about it, I figured that there are so many influencing factors that it shouldn't matter. We can't really tell how parallel the CPU and SGX work in the iPhone, 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.

Exophase said:
Questions of how big the polygons are don't really come into play, w/o blending and alpha test the fill rate shouldn't exceed the screen resolution. Shaders can be the bottleneck here, so it'd also be interesting to test performance with lighting completely off. If the SGX is clocked at say, 166MHz, and there are two USSEs, then that'd mean 2161 USSE cycles per pixel per second, or about 54 per frame here. Of course vertex shading is using some percentage of that. Gouraud shading really should just use a couple pixel shader cycles at most since the linear interpolation should be done outside the shaders.
Do you have some informations on how the SGX processes shaders exactly? What sort of instructions exist? How many cycles does each take etc?
//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.
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
Exophase said:
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.

From my experience with working with the PSP, an untextured quad, using no texture blend modes (duh!) with alpha covering the screen does have an effect on performance. Only slight, though.

Kurok shows this when you change the brightness in the menu, because I use a quad coloured in white filling the screen, with the alpha being the brightness value. When the alpha is 0, I don't render the quad.

Like I said though, this is the PSP, so it probably doesn't apply or have the same impact on performance.
 
Last edited by a moderator:
Exophase said:
- Are they done with alpha test or alpha blend?
- Are they being sent in draw calls after all the other stuff?
- If they're using alpha test, is alpha test enabled for the entire scene? I hear this could halve performance.

Maybe you can determine performance w/o the text being drawn at all?

Questions of how big the polygons are don't really come into play, w/o blending and alpha test the fill rate shouldn't exceed the screen resolution. Shaders can be the bottleneck here, so it'd also be interesting to test performance with lighting completely off. If the SGX is clocked at say, 166MHz, and there are two USSEs, then that'd mean 2161 USSE cycles per pixel per second, or about 54 per frame here. Of course vertex shading is using some percentage of that. Gouraud shading really should just use a couple pixel shader cycles at most since the linear interpolation should be done outside the shaders.
No alpha-test just alpha-blend and there is a quad underneath . Everything is sorted based on a custom mask which in this case sorts based on blend states/texture changes and some other stuff. The models themselves are using indexed triangle lists exported with my own exporter (POD) from Lightwave - before being exported everything was sorted using Imagination Technologies PVRTGeometrySort method ( comes in their SDK).
 
Last edited by a moderator:
lulzfish said:
Well, if you want 50+ FPS, then you get 280,000 triangles per frame.
If you actually use any features like lighting, texturing, simple shaders, that will probably dip to like 100,000 triangles.
Then you add in specular shading for some things, GUI overlay, and time needed to process other shit...

Probably like 40,000 triangles per scene.
So aim low.
Doesn't Quake 1 use more than that? That seems pretty low for the Pandora.

Chris
 
Last edited by a moderator:
christo930 said:
lulzfish said:
Bullshit I made up about poly counts being also BS.
Probably like 40,000 triangles per scene.
So aim low.
Doesn't Quake 1 use more than that? That seems pretty low for the Pandora.
Not at once, surely?
http://www.youtube.com/watch?v=f34y_9LJMTk

Maybe I shouldn't have said "scene". I mean, "frame". As in, "don't try to draw more than 40,000 polys all at once.
Quake probably has levels with loads of polys, but it only draws the visible ones.
 
Last edited by a moderator:
Back
Top