Pandora How Much Performance Can Give The Pandora Gpu

[Lazy8s]

A low number of shader units isn't bad if their utilization is high, which is the point of Imagintation Technology's heavily multithreaded approach.

Imgtec is the same company of which Metagence is also a division, remember.

 

[Exophase]

A low number of shader units isn't bad if their utilization is high, which is the point of Imagintation Technology's heavily multithreaded approach.

Imgtec is the same company of which Metagence is also a division, remember.

Could you elaborate? I don't see why utilization would be low for rendering for any setup with two shaders, which should easy to parallelize, well beyond 2 pixels at a time. If GPUs had any problem keeping 2 shaders full I doubt we'd be seeing dozens (or even hundreds).

 

[Adventus]

QUOTE
So.. yeah, that sounds too bad. :/
hmmm, well I'm still not entirely convinced. I am a stubborn bugger. .

Assuming that a "Multi-Threaded Execution Unit" is what we're calling a shader, I would think a "USSE" refers to a collection of shader units, as per the block diagram:

Based on what i read on B3D, IMHO some of these things don't add up if there is only 2 Shaders.

If you assume the SGX510 is 1 Shader and acheives ~2M poly/sec@200mhz then how do you scale that to a 2 shader ~13.5M poly/sec@200mhz (6.75x) of the SGX530? To achieve that poly rate, It would be reasonable if the SGX530 was 2 USSE pipelines with 4 "shaders" in each.

Presumably the lower than expected effective fillrate of the SGX510 (200M Pixel/sec != half of 1200M Pixel/sec) is because the shader is the bottleneck not the TMU. Based on what they said for the MBX v MBX-lite, I dont think PVR quote exact TMU*Clock numbers for fillrates, it just happens that the TMUs are the bottlenecks in the SGX530.

What i would guess dmdm meant by SIMD was that each pipeline of 4 shaders would be executing the same instruction at once, kind of like having two really big shaders.

BUT yeah, I'm probably out of my depth.

 

[Exophase]

QUOTE
So.. yeah, that sounds too bad. :/
hmmm, well I'm still not entirely convinced. I am a stubborn bugger. .

Assuming that a "Multi-Threaded Execution Unit" is what we're calling a shader, I would think a "USSE" refers to a collection of shader units, as per the block diagram:

Based on what i read on B3D, IMHO some of these things don't add up if there is only 2 Shaders.

If you assume the SGX510 is 1 Shader and acheives ~2M poly/sec@200mhz then how do you scale that to a 2 shader ~13.5M poly/sec@200mhz (6.75x) of the SGX530? To achieve that poly rate, It would be reasonable if the SGX530 was 2 USSE pipelines with 4 "shaders" in each.

Presumably the lower than expected effective fillrate of the SGX510 (200M Pixel/sec != half of 1200M Pixel/sec) is because the shader is the bottleneck not the TMU. Based on what they said for the MBX v MBX-lite, I dont think PVR quote exact TMU*Clock numbers for fillrates, it just happens that the TMUs are the bottlenecks in the SGX530.

What i would guess dmdm meant by SIMD was that each pipeline of 4 shaders would be executing the same instruction at once, kind of like having two really big shaders.

BUT yeah, I'm probably out of my depth.

Okay, I think you're on to something here. It'd be good to know how many execution units are part of a USSE. The block diagram also does show that the TMUs are tied to the USSE pipes (so we know there are two), as well as the final pixel output. I hope this puts to rest any dispute about real fillrate (not that it necessarily matters, as established).

One thing that I would like to address are those polygon count numbers. We don't really know that the bottleneck is vertex shading. It could be binning and/or memory bandwidth instead.

I also don't see how shaders could possibly be a bottleneck for fillrate, although PowerVR has never been talking about real fillrate to begin with.

A SIMD engine would not be shown as having several threaded execution units - I would not imagine that those could be capable of anything less than each of those executing a unique instruction at once. Otherwise they would not be separate threads and would not need scheduling. I think this refers to the instructions themselves, which operate on vectors. I was under the impression that a typical shader could at the very least do a dot product in a single cycle, which would require 4 FMACs. However, recent shader technology in the latest video cards have what are described as "scalar shaders" - the distinction makes me think that at least older generation cards had true vector shaders. I imagine that the reason the shaders were made simpler is so that more of them could be stacked on the chip. 128 scaler (1-way) shaders is potentially much more powerful than 32 vector (4-way) shaders. This would be because you do still have to do scalar operations (or at least, as shader programs have gotten more complex you'd be inclined to), so increasing the raw number of executional units instead of bunching them up as SIMD would yield higher throughput, at an overall cost of complexity (but simpler units means easier modular design for having a ton of them).

 

[Adventus]

QUOTE
I also don't see how shaders could possibly be a bottleneck for fillrate, although PowerVR has never been talking about real fillrate to begin with.
Now that i think about it neither can I, unless PVR are being extremely generous and assuming a certain number of operations on each pixel.

As you say, the smaller diesizes probably have a limited memory bandwidth, so it ends up being the bottleneck in fillrate & poly/sec.

QUOTE
However, recent shader technology in the latest video cards have what are described as "scalar shaders" - the distinction makes me think that at least older generation cards had true vector shaders.
Ahh that makes sense, dmdm was differientating it from modern unified Geforces not the oldschool stuff, which as you say were SIMD. T'was a bit puzzled by that comment.

Gee, I hope its 8 shaders.

 

[Exophase]

Another snippet from the http://focus.ti.com/lit/ug/spruff6a/spruff6a.pdf document, page 8, says 16 simultaneous threads. Simultaneous being the key word, that should mean 16 physical units running at the same time, for each USSE no less.

If I'm reading this correctly then the SIMD they is restricted to integer (or fixed point for the 2-way, for whatever reason...) within 32bit. If 8bpp colors are used then this can be useful, but I don't think it'll be used for vertex coordinates. This is assuming floating point colors are not the norm, but I don't think they'd even bother with something like this otherwise. I would say that they did opt for the "lots of scalar units" approach, but threw in integer SIMD because it's relatively cheap to subdivide ways out of an ALU. If the snippet really refers to SGX530 and it really has 16 execution units that can operate in parallel per USSE then that's a ton of processing power. It doesn't say if it can do FMACs or just FMULs and FADDs, so maybe it can take 4 or 8 cycles to do a dot product (this is throughput, disregarding latency, assuming that it wouldn't be a factor - I don't know if these shaders have any such latency for their operations)

There was something I missed in Lazy8s' comment about high utilization. I assume the purpose of all this highly parallel multithreading with zero cost thread switching is the same as Intel's hyperthreading, to give the units something to do when they incur cache misses or other pipeline stalls. This might be more of an issue for the SGX than a PC card because it'll have very low memory bandwidth (relative to clock speed) compared to them.

Maybe dmdm can let me know if I'm way off about any of this, but it has gone from sounding kind of bad to much too good to be true - a total of 32 execution units that can each do scalar floating point operations or 32bit SIMD (and other good stuff like zero overhead predication).

EDIT: Or, 16 simultaneous threads could just mean that 16 exist and can be swapped amongst. But I took the 64 "data instancs" to refer to this (data instance as in working register set, the stuff you'd actually swap between in a task switch).. hm, I'd love to know >_>

 

[Adventus]

QUOTE
If I'm reading this correctly then the SIMD they is restricted to integer (or fixed point for the 2-way, for whatever reason...) within 32bit. If 8bpp colors are used then this can be useful, but I don't think it'll be used for vertex coordinates. This is assuming floating point colors are not the norm, but I don't think they'd even bother with something like this otherwise. I would say that they did opt for the "lots of scalar units" approach, but threw in integer SIMD because it's relatively cheap to subdivide ways out of an ALU.
Yep, your right on this point at least, and i sure hell hope your right about the rest.

From the PowerVR SGX SDK:
QUOTE
To achieve best performance for a variety of tasks, the USSE supports multiple precisions. The GLSL ES precision modifiers, lowp, mediump, and highp, map to 10 bit fixed point, 16 bit float and 32 bit float types, respectively. While lowp computations are performed as 3 and 4 component vector operations, mediump operations use 2 component vectors. When using highp precision, the USSE operates on scalar values.

 

[Exophase]

Yep, your right on this point at least, and i sure hell hope your right about the rest.

From the PowerVR SGX SDK:
QUOTE
To achieve best performance for a variety of tasks, the USSE supports multiple precisions. The GLSL ES precision modifiers, lowp, mediump, and highp, map to 10 bit fixed point, 16 bit float and 32 bit float types, respectively. While lowp computations are performed as 3 and 4 component vector operations, mediump operations use 2 component vectors. When using highp precision, the USSE operates on scalar values.

lowp struck me as weird, at first I was wondering if they really meant 10.6 but nope, sign + 1.8 (according to OpenGL ES docs). We know it can do 2-way 16bit fixed point so that's covered there. The implication here is that it can do SIMD 3 or 4 way over 10bit fixed point (40 bit ALU??? sounds like a DSP), and 2 way over 16bit float (which is less expected because floats are harder to split up, fadds anyway), two things that the previous snippet did not mention. And then of course the 1 way 32bit float, which it did (but that's kinda a no brainer). I wonder... >_>

 

[delmarko]

Woaaahh so many questions!

Ok, Polygon throughput is not shader limited unless you are running very complex vertex shaders which is highly unusual... it is therefore a function of the speed that vertices can be processed/transformed and binned in the Tile Accelerator, hence the different figures for SGX510 to SGX530 independent of number of shaders etc.

Next question Peak Fillrate again this is a function of the number of TMU pipelines not necessarily Shaders and due to texture caching and compression etc making memory bandwidth a small consideration therefore you should get close to the maximum figure unless the pixel shading programs become quite complex.

I've got to be more carefult talking about the USSE (Unified Shader) pipelines as there is a lot less information available in the public domain however I would like to point out you're more on the right lines with your assertions that the 16 simultaneous threads are sort of in-flight at the same time and the core can swap between them and the working registers in order to keep the functional units full on every cycle in order to get the maximum efficiency out of the USSE's.

will try to answer more as a i spot them....

 

[Exophase]

Woaaahh so many questions!

Ok, Polygon throughput is not shader limited unless you are running very complex vertex shaders which is highly unusual... it is therefore a function of the speed that vertices can be processed/transformed and binned in the Tile Accelerator, hence the different figures for SGX510 to SGX530 independent of number of shaders etc.

Finally, I was right about something I guess that's the only real drawback to TBDR, but the figures we're given are more than enough (and I assume that it won't have much problem actually reaching those, since they should be harder numbers than shader oriented limits)

Next question Peak Fillrate again this is a function of the number of TMU pipelines not necessarily Shaders and due to texture caching and compression etc making memory bandwidth a small consideration therefore you should get close to the maximum figure unless the pixel shading programs become quite complex.

Yay, right about something else too.

I've got to be more carefult talking about the USSE (Unified Shader) pipelines as there is a lot less information available in the public domain however I would like to point out you're more on the right lines with your assertions that the 16 simultaneous threads are sort of in-flight at the same time and the core can swap between them and the working registers in order to keep the functional units full on every cycle in order to get the maximum efficiency out of the USSE's.

will try to answer more as a i spot them....

Great, the technology is sounding really interesting afterall. At the very least I think we can determine from this that it does mean more than just one unit working at once per USSE, but like a real modern CPU there might be other bottlenecks in the frontend (limits in fetch, decode, dispatch, etc)

Once we have the thing, or if someone wants to test on a Beagleboard, then benchmarks could be done to get an idea of the cycle-level performance of the shaders. That is assuming that we can dispatch actual shader ASM directly on the things (sadly I don't know much about how that works these days but I figure it doesn't HAVE to be compiled at runtime)

 

[Tobriand]

I'm moving this to the Developers' forum (with a link of course), simply because for the last couple of pages it has been material that there's no way joe public is going to understand. Keep going though - even if I understand only a fraction of it, it's still really interesting!

 

[sindbad]

I would like to see some benchmarks too. I'm quite curious just how much overdraw tile-based architectures can eliminate. The intel cards are a bad example.

 

[renejr902]

(i cant believe i created a topic that have so many posts ever today. it my best topics ever. long live to me
my personal top record: 111 replies and more than 6200 views. im so proud of it LOL
my topic dont ever got 10 replies in general)

 

[delmarko]

Woaaahh so many questions!

Ok, Polygon throughput is not shader limited unless you are running very complex vertex shaders which is highly unusual... it is therefore a function of the speed that vertices can be processed/transformed and binned in the Tile Accelerator, hence the different figures for SGX510 to SGX530 independent of number of shaders etc.

Finally, I was right about something I guess that's the only real drawback to TBDR, but the figures we're given are more than enough (and I assume that it won't have much problem actually reaching those, since they should be harder numbers than shader oriented limits)

Next question Peak Fillrate again this is a function of the number of TMU pipelines not necessarily Shaders and due to texture caching and compression etc making memory bandwidth a small consideration therefore you should get close to the maximum figure unless the pixel shading programs become quite complex.

Yay, right about something else too.

I've got to be more carefult talking about the USSE (Unified Shader) pipelines as there is a lot less information available in the public domain however I would like to point out you're more on the right lines with your assertions that the 16 simultaneous threads are sort of in-flight at the same time and the core can swap between them and the working registers in order to keep the functional units full on every cycle in order to get the maximum efficiency out of the USSE's.

will try to answer more as a i spot them....

Great, the technology is sounding really interesting afterall. At the very least I think we can determine from this that it does mean more than just one unit working at once per USSE, but like a real modern CPU there might be other bottlenecks in the frontend (limits in fetch, decode, dispatch, etc)

Once we have the thing, or if someone wants to test on a Beagleboard, then benchmarks could be done to get an idea of the cycle-level performance of the shaders. That is assuming that we can dispatch actual shader ASM directly on the things (sadly I don't know much about how that works these days but I figure it doesn't HAVE to be compiled at runtime)


Yeh there is some quite nifty features in the USSE's and certainly being able to switch between the 16 threads in-flight at once means you can hide all the data hazards etc so it should be able to manage an instruction on every cycle (on one of those 16 threads). As for the SIMD nature is does depend a lot on the data type ie 8bit/10bit Integer etc however even at F32 it is able to execute more than a single op (MUL, ADD) etc per cycle which was the "SIMD nature" i was talking about although don't get carried away, this is not the same as having 4 or 8 identical FPU's etc like a superscalar CPU.... its sort of imbetween.

 

[Adventus]

QUOTE
Finally, I was right about something
That must be an unusual thing in your day . This is the first time I've ever seen you wrong.... - ish ....

QUOTE
Yeh there is some quite nifty features in the USSE's and certainly being able to switch between the 16 threads in-flight at once means you can hide all the data hazards etc so it should be able to manage an instruction on every cycle (on one of those 16 threads)
Hmmmm, Some Quasi-mathematical speculation:

1 [instruction/cycle] * 2 [USSE] * 200M [cycle/sec] = 400M [instructions/sec]
400M [instructions/sec] / 30 [frame/sec] = 13.33M [instructions/frame]

Guessing maybe a third of those instructions will be neccessary for vertex transforms (~120,000 tri's @ ~12 instructions per transform) . Your left with:

8.89M [instructions/frame] / 384 000 [pixels/frame] = ~ 23 [instructions / pixel] @ 800x480
8.89M [instructions/frame] / 96000 [pixels/frame] = ~ 92 [instructions / pixel] @ 400x240

Since I dont really know how many instructions it takes to do common things.... i cant really take it any further. Or is my maths just totally off....

 

[cb88]

would the instructions need to be ran on all the pixels in a frame i think not?

 

[Adventus]

QUOTE
would the instructions need to be ran on all the pixels in a frame i think not?
True, depends entirely on the effect and what's currently in frame. Its probably not that common that you can 100% gaurantee an effect wont be applied fullscreen in a 3d game. The player might decide to walk up to that wall with all the crazy lighting. Its pretty well accepted that sudden drops in fps have a greater visual impact than the average fps, so minimising them is priority.

Since we are dealing with averages, I prefer to think about it in these approximate terms.

 

[MrPoletski]

someone can compare the gpu of the pandora with a pc video card in term of performance. is it similar to a voodoo1, savage 4, ati rage pro, surely not a geforce, i ask that because i have no idea of the performance of the gpu) i read the specs of the gpu but cant conclure anything

This is something I am also very interested in. given this thing can run quake a direct FPS comparison should be possible

anyway, for reference:

I seem to recall it has 8 shader units also, but bear in mind those shaders are both for pixel shading and vertex shading (vertex shading being done by a different unit in the dreamcast).

I mention the dreamcast because it used a 100Mhz (vs 125Mhz) variant of the PowerVR graphics chip found in the neon250 that had a few extra features used to give it about the same speed as the 125Mhz part.

This 100Mhz part was directx 7 compliant and had no integrated hardware acceleration for transformation calculations which has long since become part of every GPU.

So you have the dreamcast running at 100Mhz using an old style DX7 architecture that had *one single* rendering pipeline. You also have the Neon250 PC card. I owned the neon250, it ran quake 3 quite well in 1024x768.

The SGX530 in the pandora has eight shader cores. If only half of them are actually used for shading pixels rather than doing polygon calculations, it's 200Mhz speed would give it 8x the raw power (eight times) of the dreamcasts 3D core.

Personally, I think the performance of this 3D chip is going to suprise even those who know it's fast.

At a guess, I'd say it will compete performance wise with many of the budget 30-40 quid cards you see today for sale and I expect it will embarrass anyone who makes, produces or 'chose to settle with' integrated chipset graphics on the PC. I could be wrong though

...as for your guess, yep i am an insider, in fact i'm one of the designers of SGX however i have to be careful not to release any information which could land me in hot water with my employers! I can however report that the SGX core inside OMAP will happily do ~10MTri/sec, although this is based on a whole host of factors ie vertex sharing / complexity of vertices (number of layers etc).



Cool. Nice to see guys like you here in our Forums.
Everything onto the Pandora seems so mysterious and NDA and DNP, pretty much for a Open-Source Console. Well, if at least the (Homebrew) Coders have acess to the Hardware-Features at the end to use all the Power the Pandora can give us, I'm fine.

And Q3 is a perfect example to show the Power of the Console. I don't know if Q3 also runs onto the PSP but I'm sure, the Pandora will be the fastest Handheld on the Market. I hope Unreal Tournament will also find the Way onto the Pandora some day (I know it is not Full open-surce yet ). I think the PowerVR SGX could also handle the good old S3TC Textures from the UT Bonus Disc. ^_^



Personally, I think that a newer, better looking game could be used to show it off than Quake 3. It can esily handle quake 3, hell the powerVR mbx (previous gen) could handle quake 3.

What about half life 2? or Doom3/prey?

 

[lulzfish]

What about half life 2? or Doom3/prey?

They're closed-source.
But I'll give you 20 bucks if you can get us the code to any one of those unobfuscated

 

[Trip]

someone can compare the gpu of the pandora with a pc video card in term of performance. is it similar to a voodoo1, savage 4, ati rage pro, surely not a geforce, i ask that because i have no idea of the performance of the gpu) i read the specs of the gpu but cant conclure anything

At a guess, I'd say it will compete performance wise with many of the budget 30-40 quid cards you see today for sale and I expect it will embarrass anyone who makes, produces or 'chose to settle with' integrated chipset graphics on the PC. I could be wrong though

From what I can remember Craig and co. guessed that it would be about as powerful as a Geforce 3 but with the programmability of a Geforce 7. I can't find the original post at the moment though.