SGX comments (pruned from Amd z430 thread)

Considering Samsung's boast of GPU performance, I actually expect that they were fairly aggressive with the clock rate for the GPU in the Galaxy S app processor.

This particular implementation of Galaxy S isn't having great compatibility with GLBenchmark, but Qualcomm's Neocore allowed the 540 to flex a bit more.

android-neocore.png
 
55.7 fps actually means it's vsync/refresh rate limited (Galaxy S screen refresh is ~56 Hz).
 
Nice.

I'll be buying myself a Vibrant this month, so my situation is looking great from a hardware standpoint then.

The Vibrant's release will actually represent the first PowerVR phone officially for T-Mobile USA. Even though PowerVR is so common across the flagship devices of all of the phone manufacturers, the flagship phones of the non-US manufacturers have almost no representation at the US carriers, and each of the other three carriers already got their PowerVR offering through an exclusive deal with one of three big US phone makers: Motorola Droid with Verizon, Palm/HP Pre with Sprint, and Apple iPhone with AT&T.

I'm grateful for Samsung's wide-ranging Galaxy S introduction; I've actually been really annoyed that my hardware couldn't support Google Earth on my new myTouch Slide (no CPU FP support, thanks Qualcomm), an app which I'd been enjoying on my iPhone for years until I was kinda forced to change from AT&T to T-Mobile and switch phones.
 
Gizmodo just posted up a side-by-side video of a Galaxy S (1Ghz hummingbird +SGX540) against a HTC desire (snapdragon + adreno) running Quake2. The difference is astounding, the Galaxy appears to be running at least 3-4 times quicker.

There is also a video on that same page of Quake III running smoothly on the galaxy.

http://gizmodo.com/5580123/quake-2-test-htc-desire-vs-samsung-galaxy-s
Considering that SGX540 was always faster and better(on paper and now IRL) than adreno 200(z430) on qualcomm it's not surprising, wonder how adreno 220 will fair against SGX540
 
55.7 fps actually means it's vsync/refresh rate limited (Galaxy S screen refresh is ~56 Hz).

Hum.. do you know if this refresh rate is a limitation of their SuperAMOLED technology? I'd feel a lot more comfortable with a value much closer to 60.
 
Considering that SGX540 was always faster and better(on paper and now IRL) than adreno 200(z430) on qualcomm it's not surprising, wonder how adreno 220 will fair against SGX540

Indeed, 535 is the one we'd need to get compared to 200, not 540
 
Hum.. do you know if this refresh rate is a limitation of their SuperAMOLED technology? I'd feel a lot more comfortable with a value much closer to 60.
I don't know why they picked 56 Hz, but I doubt it's a limitation inherent in SuperAMOLED technology.
At the end of the Quake 2 video you can see the fps counter peaking at 56 fps, too.
 
With the inconsistent and sometimes conflicting benchmarks currently available for mobile graphics, actual developer feedback and testing has been invaluable in confirming the indications and trends of performance suggested by the benchmarks.

Game developers have found the Motorola Droid to be the most capable among the last batch of Android phones, so the 535-equipped 3GS handily outperforming the Nexus One was little surprise when Distinctive Developments compared the two with a simulated game scenario.
 
As has been indicated, each SGX variant is the result of customized performance and sometimes features, not just the scaling of ALUs and TMUs. In the context of 200 MHz and < 50% shader load:

IMG was originally very specific about the performance of the 530, indicating a figure down to the half-million, 13.5M tri/sec, which logically implies that they weren't being too rough about their rounding. They later charted the 520 at 7M tri/sec, the 530 at 14M tri/sec, and the 540 at 28M tri/sec. Some of the pixel fill numbers from the old SGX tech docs did imply, as was mentioned, that the 520 was somehow even less than half of the 530 (the cancelled 510 was even far less, using a USSE-lite pipeline.)

All indications were that the 53x family shared similar geometry performance characteristics. Indeed, GMA 500 docs state a performance of 1 triangle per 15 cycles which equals 13.3M tri/sec, and Intel even rates it explicitely at 13M tri/sec where they commonly set the clock at 200 MHz. NEC claimed 15M tri/sec for the 535 in their NaviEngine SoC, so the 13M tri/sec range seems very probable for the 53x line of variants.

I've been inclined to believe IMG has customized each successive variant for incrementally higher geometry performance as provided in their original, respective press releases: 35M tri/sec for the 543, ~40M tri/sec for the 545, 100M tri/sec for the cancelled 555, and 95% of 35M tri/sec multiplied by the number of MP cores.
 
Last edited by a moderator:
Interesting, so those Wikipedia figures were official. Except 535 was the one listed at 28 instead of 540, with ensuing confusion.

Lazy8s, do you have a link for the GMA500 documentation?
 
Thanks.

So, the 15 cycles/triangle figure is "transform only", ie should be shading throughput, presumably performing the operations described in 9.1.3 - so I guess vertex multiplication by projection/modelview matrix and the entire OGL lighting model calculations. I'm assuming perspective divide and screen space conversion are performed in fixed function rather than by shaders, but maybe someone else has a different answer for this.

I wonder if 15 cycles means chip cycles or per-USSE. If it's the former it'd be 30 USSE cycles that are needed for transformation of one vertex, which is probably pretty reasonable for a platform that can presumably do 1 32-bit FMAC per or 1 SIMD operation over colors per cycle.

"Transform only" also suggests that the bottleneck after shading could be worse - either during culling, binning, or rasterization. This is also assuming no additional incurred overhead such as multiple triangle setup due to splitting a triangle over tile edges.

On the other hand, the shading could be the bottleneck, possibly what the 0.5 peak vertex to triangle ratio means. In which case, vertexes with no shading (no lighting and maybe even no geometry transformation) might yield a higher peak triangle rate.
 
On the other hand, the shading could be the bottleneck, possibly what the 0.5 peak vertex to triangle ratio means.
That just means that indexed triangles are used which gives you a typical peak of 2 triangles for every vertex, compared to triangle strips which give, at best, 1 triangle per vertex.
 
That just means that indexed triangles are used which gives you a typical peak of 2 triangles for every vertex, compared to triangle strips which give, at best, 1 triangle per vertex.

I figured that's what it meant, but I guess somehow this didn't click for me. Maybe I need to look at a diagram, because in my mind it "feels" like one vertex/triangle is more what you get. I guess I should start by considering all the points a triangle strip would start sharing if you say, zig-zagged it left to right, top to bottom? Well, you can see I'm pretty disconnected from real 3D ;P
 
I figured that's what it meant, but I guess somehow this didn't click for me. Maybe I need to look at a diagram, because in my mind it "feels" like one vertex/triangle is more what you get. I guess I should start by considering all the points a triangle strip would start sharing if you say, zig-zagged it left to right, top to bottom? Well, you can see I'm pretty disconnected from real 3D ;P

Well, you can concoct special cases, but for surfaces, it just follows from Euler's law that says
Code:
V + F = E + 2
where V = number of verts
F = number of faces
E = number of edges

Since we are dealing with triangular faces, we have 3 edges per face but each edge is shared between 2 faces, so E = F * 3/2

We thus get:
Code:
V + F = 1.5 F + 2
=> V = 0.5 F + 2
 
Just tried to split the thread but there's no direct tool to do it. Might have to copy and then prune. Sigh
 
Back
Top