You can find out every last detail about the S5PC100 GPU from the user's guide:
http://forum.embedde..._UM_REV1.04.pdf
Which is not publicly available so you should probably download it while you can, if you want it.
It'll take me a while more before I feel like I have a really thorough understanding of it vs SGX 530, and of course even then I can totally be wrong. Also, bad drivers for either can be potentially game breaking, although in the case of S5PC100 you could very well write your own drivers using the data in the user's guide. Reading it is actually a pretty insightful look into how a somewhat modern 3D accelerator works.
I guess these are some possible thoughts on comparisons:
Cons vs OMAP3530 SGX530:
- Rendering is not tiled. Color and depth/stencil buffers go through caches, but for this to be effective polygon coverage has to have good locality of reference. You can tile in software, but unfortunately the sizes of the caches aren't listed so you'd have to empirically determine that. They're probably not large enough to make tiling worth it, and I don't think there are any options to make it easy to bin geometry.
- No deferred rendering, also there's no hierarchical-Z or early-Z rejection, so you get the full effects of overdraw (depth test/reject is only performed in raster op stage at the end of the pipeline)
- Although it should be capable of 2 pixel/clock throughput this isn't what's actually rated - for 133MHz one part of the document says 166 and the other 200. My guess is that you don't get 266 because of overhead in the caching and weakness in the memory architecture. What I'm saying is that it could be that the render buffer caches are blocking or don't support hit under miss for loads, ie for depth buffer reads, so when it writes back to the real render buffer it sits around doing nothing for a while. Then the actual performance will depend on how much the depth/stencil cache is retained between polygons, and it could explain why they list two different numbers.
- No threading/latency hiding for shaders. I'm not sure if the two pixel shaders are chained against the same program or not.
- Non-uniform shaders means that vertex shader can't do some things fragment shaders can.
- Seems like the shader support isn't robust - only lists Shader Model 3, only has 512 instruction slots, etc. It does loops but I'm not sure if it handles subroutines.
Pros vs OMAP3530 SGX530:
- Clock speed is listed as 133MHz, as opposed to the OMAP3530 SGX which is capped at 110MHz.
- Has two TMUs instead of one, so can theoretically load over twice as many texels, but of course you perform texture loads redundantly with overdraw with no way to reduce them, so in the end it probably needs more than 2x typically. It does also have a texture cache for each TMU, although without knowing size and associativity for either part I can't really say if this is an advantage.
- Non-uniform shaders gives 1:2 for vertex/fragment shading instead of 2 for both, which means vertex shading doesn't take away from your fragment budget.
- Shaders are much wider (32x4 floating point), so are probably better at vertex shading and good at fragment shading involving HDR effects.
- Pure immediate mode rendering and late testing means you don't pay a price for fragment discard. Same for some other raster ops.
Overall I think the Samsung GPU on S5PC100, with no overdraw eliminating techniques, tiling, and an overall low rated fillrate, is going to be very fill limited compared to the SGX 530. This is going to supersede its strengths. It also probably has fewer image quality related features. But the intriguing thing is that with the user guide all of the low level interface details of the 3D hardware (and some of the operational details) are exposed, which means you can write your own drivers or library code and can get a lot of flexibility out of it. SGX530 on OMAP3530 is currently quite limited by OpenGL ES 2.0, and where it isn't limited some things will be too slow to be useful. This hardware gives you some realistic options for circumventing that. And I'd like to further note that although Samsung does not make the user guide publicly available, there's also nothing in it that indicates that it's confidential material.
