Nokia to reveal Ngage 2 at E3!
- Thread starter TEXAN
- Start date
I really dont know.
Is the poly count of lite equal to that of DC? i.e 5-6mpps fully lit, textured, including A.I&Physics but only 1mpps for the majority of programmers?
The DC was like that, it did 7 million lit&tex theoretical, 5-6 million in a gameplay environment, but majority of your average devs couldn't get anything more than 1m-1.5m out of it. However the more talented ones like melbourne house and am2 went 3-6m.
So is that how lite is?
If not, then why did renesas use the 5-6mil figure? even though Simon confirmed they are using the lite in the SH3707.
Is the poly count of lite equal to that of DC? i.e 5-6mpps fully lit, textured, including A.I&Physics but only 1mpps for the majority of programmers?
The DC was like that, it did 7 million lit&tex theoretical, 5-6 million in a gameplay environment, but majority of your average devs couldn't get anything more than 1m-1.5m out of it. However the more talented ones like melbourne house and am2 went 3-6m.
So is that how lite is?
If not, then why did renesas use the 5-6mil figure? even though Simon confirmed they are using the lite in the SH3707.
PowerVR represents their technology but not their customers' implementations of it, so the figures they provide are guidelines for what an average implementation would yield.
They also don't design for performance much outside realistic usage scenarios, so the speed of their parts is competitive in target applications but not necessarily as high in theoretical measurements. The numbers they report tend to be the performance which can be realistically sustained.
Quoted geometry rates for games usually refer to the number of triangles transformed, not the ones rendered. Because transformation occurs before hidden surface removal, those polygon figures quoted for games don't need to be multiplied by the factor of overdraw. What does get multiplied to find the PowerVR equivalent, though, is fillrate.
I think Renesas's SH3707 as an MBX-Lite is a misunderstanding.
They also don't design for performance much outside realistic usage scenarios, so the speed of their parts is competitive in target applications but not necessarily as high in theoretical measurements. The numbers they report tend to be the performance which can be realistically sustained.
Quoted geometry rates for games usually refer to the number of triangles transformed, not the ones rendered. Because transformation occurs before hidden surface removal, those polygon figures quoted for games don't need to be multiplied by the factor of overdraw. What does get multiplied to find the PowerVR equivalent, though, is fillrate.
I think Renesas's SH3707 as an MBX-Lite is a misunderstanding.
Found my answer!
DC Count
http://dextremes.com/sega/specials/pvrsg2.html
MBX Lite count
www.khronos.org/opengles/presentations/gdc_mar04.ppt
It would seem that the poly count of the mbx lite is based on the DC
Both can do 1.2 million front facing poly's but with deffered rendering that equates to around 3 - 4 million, that's why we always heard the 3m figure for the DC.
But the regular mbx, the HR-S, can do 2.5 million front facing poly's per second, thats double of the lite and DC's figure. thus meaning the HR-S within the ngage 2 via deferred rendering is equal to 6-8 million double the 3-4 figure of DC/Lite.
In other words it completely annihilates the PSP, for which Sony have told devs to go for the 3 million marker.
Damn I cant wait for the n-gage 2.
Glad to finally have found this info.
DC Count
http://dextremes.com/sega/specials/pvrsg2.html
MBX Lite count
www.khronos.org/opengles/presentations/gdc_mar04.ppt
It would seem that the poly count of the mbx lite is based on the DC
Both can do 1.2 million front facing poly's but with deffered rendering that equates to around 3 - 4 million, that's why we always heard the 3m figure for the DC.
But the regular mbx, the HR-S, can do 2.5 million front facing poly's per second, thats double of the lite and DC's figure. thus meaning the HR-S within the ngage 2 via deferred rendering is equal to 6-8 million double the 3-4 figure of DC/Lite.
In other words it completely annihilates the PSP, for which Sony have told devs to go for the 3 million marker.
Damn I cant wait for the n-gage 2.
Glad to finally have found this info.
TEXAN said:
Errr i tend to disagree.
The CPU could apparently do T&L for 10 million pps, with the PoverVR chip able to draw up to 7 million textured pps. Peak figures, of course. Two of the same graphics chips were later paired up with a single Elan T&L chip (in Naomi 2) which could put out up to 12 million pps.
I don't think DC and MBX geometry rates are directly related. Some MBX implementations are made to do less than the Series 2 part in DC, and some of the Renesas MBX implementations are made to do more.
A PowerVR rendering core has to set up and perform hidden surface removal to the polygons it's going to rasterize to the screen, so I don't think its draw rate would be different even though it'll only ever end up drawing the visible polygons. If the actual number of polygons drawn to the screen were known, that figure could be multiplied by the overdraw factor to find an IMR equivalent rate, but all of those extra polygons would have to have been set up by the renderer in the first place. Since the polygon figures given are almost always before the hidden surfaces have been removed, it makes no sense to multiply them by the overdraw factor as there are no hidden surfaces to account for.
I think the 1.2M-pol/sec benchmark was just an estimate for a specific PC system. The CLX chip in DC could set up about 7M-pol/sec. The 3M-pol/sec figure was just the estimate for what it could sustain in realisitc applications. Just like for any system, some developers did, and some developers didn't. MBX numbers given also seem to be estimates for sustained conditions and not theoretical maximums.
A PowerVR rendering core has to set up and perform hidden surface removal to the polygons it's going to rasterize to the screen, so I don't think its draw rate would be different even though it'll only ever end up drawing the visible polygons. If the actual number of polygons drawn to the screen were known, that figure could be multiplied by the overdraw factor to find an IMR equivalent rate, but all of those extra polygons would have to have been set up by the renderer in the first place. Since the polygon figures given are almost always before the hidden surfaces have been removed, it makes no sense to multiply them by the overdraw factor as there are no hidden surfaces to account for.
I think the 1.2M-pol/sec benchmark was just an estimate for a specific PC system. The CLX chip in DC could set up about 7M-pol/sec. The 3M-pol/sec figure was just the estimate for what it could sustain in realisitc applications. Just like for any system, some developers did, and some developers didn't. MBX numbers given also seem to be estimates for sustained conditions and not theoretical maximums.
Fox5:
DC's SH-4 would of course need a good amount of overhead, and I think it could actually transform at least 12M-pol/sec.
Right, as mentioned, throughput was limited more by set up and ultimately by display list storage. It could never reach 10M-pol/sec, but it could certainly do more than 1M.
DC's SH-4 would of course need a good amount of overhead, and I think it could actually transform at least 12M-pol/sec.
Megadrive1988
Veteran
I remember reading that DC's 200MHz SH-4 could transform max 20 million polys (or verts) per second. but the most commen numbers was 10 million polys/verts per second. anyway, these higher transform figures are needed so that not only is there enough to send to the PowerVR2DC rasterizer, but also probably so that there was some overhead / leftover computations for the game. I still wish Sega had gone with a Lockheed Martin solution, where Real3D would have made an outstanding full fledged GPU, an extention of the Model 3 / Real3D Pro technology, and not based on the crappy watered down i740 developed for Intel. ahh but thats water under the bridge isnt it.
No dedicated geometry hardware on DC, coupled with slow general purpose performance of the CPU, you would be lucky to see 50% of CPU time devoted to processing geometry in a realworld application.PCEngine said:
Then there's also a fair bit of geometry that uses more then just trivial transforms in your average game, and the VRam limitation that Lazy mentioned.
PC-Engine wasn't questioning that, actually. He and I were confused by the wording of Fox5's reply which we had wrongly interpreted as some kind of further clarification of how the various DC polygon figures were derived.
It's now clear that Fox5 was making the point that the DC might still become transform limited in the scenarios where too much CPU power was being devoted to other tasks beside simple transform. We hadn't been arguing that.
The scaling of MBX polygon counts and other performance rates with the different gate/feature sizes, indeed, accounts for a lot of variation between the chips. Though, technically, Renesas's chips don't use the HR-S since that's an ARM specific implementation that the company licenses for their architecture (and which TI adopted for OMAP2); Renesas uses a SuperH complementing alternative.
It's now clear that Fox5 was making the point that the DC might still become transform limited in the scenarios where too much CPU power was being devoted to other tasks beside simple transform. We hadn't been arguing that.
The scaling of MBX polygon counts and other performance rates with the different gate/feature sizes, indeed, accounts for a lot of variation between the chips. Though, technically, Renesas's chips don't use the HR-S since that's an ARM specific implementation that the company licenses for their architecture (and which TI adopted for OMAP2); Renesas uses a SuperH complementing alternative.
Similar threads
