I still don't really think this is fair. First, just because an implementation isn't tile based doesn't mean that there's no hidden surface removal whatsoever. The other companies aren't putting in any kind of factor to account for this. Second, PowerVR didn't actually say what this factor is, nor how they derived it. I hear that Quake 3 has an average overdraw factor of 3.8, but it seems to me that a first person shooter is going to have a lot more overdraw than games with very different camera angles, like overhead perspective. Third, I don't think TBDR can remove overdraw 100% (the remaining pieces that are inside the tiles), so 3.0 would have to be a 3.0 reduction, and I just don't think overdraw is that high in most normal things.dmdm said:Clearly the third option would yield a ridiculously high fillrate but that wouldn't be realistic and wouldn't represent real world performance unless you had a vast amount of overdraw... similarly option 1 would be far too pessimistic and also wouldn't represent real-world performance... so i'm afraid option 2 is the only sensible option although i definitely agree it is not nice to have to resort to a magic "factor" in the calculation however this is the only way to get accurate and representative figures i'm afraid.
I guess the reason why I'm bothered by this is because PowerVR is and always has been heavily promoting the benefits of TBDR, they shouldn't be granted a grossly artificially adjusted fillrate number in addition to that. That and it really just isn't honest (and I don't see anyone else doing it). They would have probably done as well to give the real fillrate and explain why that can get a lot further.Adventus said:QUOTE
Second, PowerVR didn't actually say what this factor is, nor how they derived it.
I think its a historical value that was produced between the Kyro I/II vs Geforce 2/3 time. Kyro gave similar performance to Geforces at the same clock which had 3x the theoretical fillrate. When compared to a modern Geforce I agree, its unlikely to hold due to the fancy z testing, but compared to other embedded cards its probably in the right ballpark (given the constraints).
Feel free to disagree. At least until we actually get our hands on one.
Exophase said:More on target... I hear that SGX530 has 8 unified shader units. Unfortunately I don't have any very good sources for this, so we can just hope that it's true.
Wouldn't 8 USSE @ 200 MHz * 3x overdraw translate to > 4Gpixels/s (while you were previously quoting 1.2Gpixels/s)?
Anyway I think we can't conclude anything from any number, we will just have to wait and see how it performs... or how it doesn't perform
Laurent said:Answers to a couple of questions, Exophase, yes a TBDR is completely efficient and will remove 100% of the overdraw even within tiles.... you are correct in your assertion that the fillrate is therefore shared between the surfaces we are rendering to etc which is why you can easily get away with quite a low theoretical peak fillrate and still match performance.Exophase said:More on target... I hear that SGX530 has 8 unified shader units. Unfortunately I don't have any very good sources for this, so we can just hope that it's true.
Wouldn't 8 USSE @ 200 MHz * 3x overdraw translate to > 4Gpixels/s (while you were previously quoting 1.2Gpixels/s)?
Anyway I think we can't conclude anything from any number, we will just have to wait and see how it performs... or how it doesn't perform
SGX530 only contains 2 USSE pipelines however they are SIMD in nature, so comparisons with a GF3 will probably be difficult given its less flexible 1:4 Vertex to Pixel shader ratio etc. As i say i still believe my original statement will hold true and in most games i would expect you to be shader limited... vertex/polygon throughput and memory bandwidth are highly unlikely to be the limiting factor.
If I'm not mistaken, fillrate when using AA in TBDR's doesn't take that much of a hit and it's definitely a reasonable trade-off to have it enabled. Bilinear filtering is also absolutely free, disregarding memory usage.Exophase said:With supersampling AA you could always use more fillrate, but here just doing a straight 800x480 should be more than enough. Still, if we're going to be talking about how much overdraw things tend to have then it's fair to assess how much remains after TBDR is used. I don't expect what's there to be a problem though.
Is it really?? Excuse my ignorance, but is DOT3 per-pixel lighting possible in hardware for the PSP?Lazy8s said:PSP is a fixed function graphics platform around OpenGL ES 1.1 in feature set.
As to the topic question, Pandora's GPU approximately has GeForce 3 performance with GeForce 7 graphics features.
Laurent said:Okay, going to try this again. Texture mapping units are not shaders. That is and always has been the number from which fill rate is devised. A shader can't texture map in a single cycle.Exophase said:More on target... I hear that SGX530 has 8 unified shader units. Unfortunately I don't have any very good sources for this, so we can just hope that it's true.
Wouldn't 8 USSE @ 200 MHz * 3x overdraw translate to > 4Gpixels/s (while you were previously quoting 1.2Gpixels/s)?
Anyway I think we can't conclude anything from any number, we will just have to wait and see how it performs... or how it doesn't perform
I guess there must be something I'm missing about TBDR then, since that's not really the intuitive explanation. I would figure something would have to scale time-wise with the number of polygons in a tile.dmdm said:Answers to a couple of questions, Exophase, yes a TBDR is completely efficient and will remove 100% of the overdraw even within tiles....
Only two shaders? Source please. I was under the impression that all GPU shaders ever made were vector coprocessors and hence were SIMD by default. All of the assembly language I've seen for them seems to agree with this.dmdm said:SGX530 only contains 2 USSE pipelines however they are SIMD in nature, so comparisons with a GF3 will probably be difficult given its less flexible 1:4 Vertex to Pixel shader ratio etc. As i say i still believe my original statement will hold true and in most games i would expect you to be shader limited... vertex/polygon throughput and memory bandwidth are highly unlikely to be the limiting factor.
Would also like a source on the SGX clock for Pandora. If it's 110MHz at 600MHz for the Cortex then that'd mean 165MHz at 900MHz if they're divided off of the same clock. But there's no guarantee that they would be. The Cortex-A8, C64x+, and SGX530 clocks we've been seeing all seem pretty weird in relation to each other.Lazy8s said:Pandora's SGX530 probably has eight of those, giving it a maximum effective opaque and also stencil fill rate of 1200 megapixels (at the 150 MHz clock speed that corresponds to the 900 MHz Cortex of the reportedly developer clocked OMAP3530s.)
Yes, pipelines referring to TMUs, where I got that figure (Wikipedia says that the two are often analogous). Shader count doesn't have to be the same as TMUs.Adventus said:Para-phrasing: "With double the pipelines of the already blisteringly-powerful SGX530" .... "POWERVR SGX540 is the first 4 pipeline version of the SGXfamily."
It's a bit difficult to compare specs- the XBox had an x86 CPU for starters...Soulkiller said:...Omg wait... when this things is fully clocked out to 900mhz... I think its about as powerful as an xbox if I remember the specs...actually I think its a litte bit more
Holy **** Am I comparing this wrong or can someone else look at the xbox specs and agree with this?
USSE is the name for PowerVR's unified shader architecture.Adventus said:However, how did you extrapolate only 2 shaders from dmdm saying there is only 2 USSE pipelines?
Guess that settles that then. All we really needed to hear.Adventus said:PS: I would guess dmdm is a source himself, since he said he's one of the SGX designers.
Great, this was the same OMAP3 you guys are using right? Bet that means it can at least handle 600 / 4, if not 600 / 3, and 900 / 5 or 6. At any rate, something better than a divider of 6 (or that slow fixed clock).MWeston said:If I remember correctly, the SGX core has two ways to set its clock. It can be set to a fixed frequency of 96MHz or it can be a divided down frequency of the CPU clock. The legal dividers are 3, 4, 5 and 6. It's been a while since I looked that up but I think it's right.
The demos we saw in Texas were running at 500MHz with the SGX core at 166MHz which means they were using a divider of 3. Based on that, you can speculate which values would work for 600, 800 and 900 MHz.