3d Real Performance


Electric Dreams

Still Fresh
Joined
Sep 11, 2008
Messages
2
Hi. I wonder what's the real performance in 3D applications of OMAP.

The OMAP has Shared Memory Access for CPU/GPU and a narrow 133Mhz DDR memory bus (266 Mhz).

SMA is a handicap even for wider buses and impacts severely in general performance of graphics applications. What do you think about this?
 
I do think that this is a real and potentially rather serious problem, however it is somewhat mitigated by:

a] CPU's L2 cache (most other embedded devices are lacking this) which minimizes main memory stress somewhat.
b] Caches on the SGX's side... although we don't know how large they are.
c] Deferred tile rendering which minimizes texture accesses and framebuffer writes compared to other archs.
d] Texture compression.

I think the Wiz is going to be doing much worse because it doesn't have any of a or c and I don't know if it even has d (and texture caches are probably much smaller), AND it has half the memory bandwidth (16bit bus)

Also I think that the frequency will be fine so long as the SGX clock doesn't exceed it (such that it can't provide one 32bit transfer per cycle, which it should be able to do hopefully, if latency is hidden), and it won't.
 
Yeah, memory speed is almost always one of the biggest most annoying bottlenecks in any system, and with the CPU and GPU fighting over it, organizing data for the caches will probably be a big part of pushing the limits at high CPU clock rates. But hopefully people will keep the CPU clock as low as possible to save battery life anyway, and then the memory speed might not be a problem.

And for a multi-purpose system like Pandora, I think the added flexibility of shared memory is worth a bit of slowdown. Games can have lots of high-res textures, apps won't murder your SD card by constantly writing to a swap file, and it doesn't cost a fortune.
 
What I'd *really* like is some way to directly address the framebuffer and (especially) textures in hardware-accelerated mode :)
 
icurafu said:
not to mention that sound and video can be offloaded from the main CPU. The SGX can be overclocked.
MMhhh, you have lost my point. It's not about CPU or GPU power. No matter how much overclock, the memory bus still the same.

QUOTE
Yeah, memory speed is almost always one of the biggest most annoying bottlenecks in any system, and with the CPU and GPU fighting over it, organizing data for the caches will probably be a big part of pushing the limits at high CPU clock rates. But hopefully people will keep the CPU clock as low as possible to save battery life anyway, and then the memory speed might not be a problem.

And for a multi-purpose system like Pandora, I think the added flexibility of shared memory is worth a bit of slowdown. Games can have lots of high-res textures, apps won't murder your SD card by constantly writing to a swap file, and it doesn't cost a fortune.


I don't understand you, seriously...

Lower CPU clock don't save memory bandwidth.

If you use high-res textures, you are saturating the memory bus.

And... what is the relationship between Shared Memory and SD card life cicle??? :blink:
 
Last edited by a moderator:
May I suggest changing your topic to match your question? or even the starting line.

"Concerned about limited memory bus - effect on 3D performance" is a suggestion. Exophase already responded soundly to the specific bandwidth part.

Although being a good responce, you would rather respond back to those who don't answser your specific issue, despite starting your topic about generic 3D performance on OMAP.
 
Electric Dreams said:
I don't understand you, seriously...

Lower CPU clock don't save memory bandwidth.

If you use high-res textures, you are saturating the memory bus.

And... what is the relationship between Shared Memory and SD card life cicle??? :blink:
Hmm, I was assuming you could set lower waitstates on memory when running the CPU at a lower frequency, but I'm not sure actually. In any case the memory wouldn't go faster, it would just be less wasted cycles if the CPU is going slower and the memory is the same speed.

And the SD card thing, I meant you'd either have to add extra VRAM which would increase the cost, or reduce the main RAM to give some to the video hardware, so you'd run out of actual RAM sooner and need a swap file. Or maybe it wont use swap files, in which case you'd just be able to have less stuff open at once.
 
Last edited by a moderator:
The Pandora won't use swap files, supposedly. The SD card is way too slow to be done efficiently.
 
dekutree64 said:
Hmm, I was assuming you could set lower waitstates on memory when running the CPU at a lower frequency, but I'm not sure actually. In any case the memory wouldn't go faster, it would just be less wasted cycles if the CPU is going slower and the memory is the same speed.
There is some of that possible. However, I will offer as an example of this thinking taken to extremes- it doesn't work QUITE the way one would think it would. Ever heard of the Cyrix MediaGX or the National Semiconductor Geode GX or GX1 (The GX2 is the current AMD offering under the Geode LX branding...)? If you have, you'll know that it stank on ice. If you haven't, trust me, it was mostly a boondoggle that the industry took back ages ago. Cyrix had this brilliant idea- a full-on PC on only 2 chips, sans RAM. This would be the MediaGX. They accomplished this in spades, but unfortunately with one bad design decision that got propagated to the Geode GX/GX1 designs and to a lesser extent to the GX2 (now LX...) design. They lowered the FSB so that they could have timings and access latency against PC66 RAM so that you "didn't need L2 cache" to run with the system. Nice idea, but it crippled the FSB to 33MHz with the predictable result of making the thing next to worthless to anyone using it in it's day. It was a debacle that the set-top box crowd kept repeating over and over again because it was "cheap". Nowadays VIA, AMD, and Intel all offer real answers to the low-end and embedded x86 space that don't make these stupid mistakes.

Lowering the clock may change the latency profile, yes. Lowering it enough to lose the wait states is typically sufficient to lose any gains in that because you lose more speed to the lowered clock than to the losses due to latency.

QUOTE

And the SD card thing, I meant you'd either have to add extra VRAM which would increase the cost, or reduce the main RAM to give some to the video hardware, so you'd run out of actual RAM sooner and need a swap file. Or maybe it wont use swap files, in which case you'd just be able to have less stuff open at once.


What will happen is that you'll allocate a bit of the 128Mb to the GPU for framebuffer and textures when you do 3D. The more textures you field, the more you vampire from the rest of the system. To offset this, you're going to want to set up swap on the SD or do simpler stuff. Now, having said this, the SD will be "just fine" for doing swap to. The reality of things as they are these days, with a Class6 card (you will NOT want less than this...trust me...) you should expect to see upwards of 20-50 years of lifespan out of it with wear-leveling evening out up to 10 Gb worth of writes. Perhaps more data written than that- but you get the idea here. The Class6 SDHC guarantees that you at least see 6MiB/sec write speed out of the card. The swap will slow some things down, but with premium Class6 (which ought to give you 10-20MiB/sec write speeds), you shouldn't notice it all that much.


Electric Dreams said:
Hi. I wonder what's the real performance in 3D applications of OMAP.

The OMAP has Shared Memory Access for CPU/GPU and a narrow 133Mhz DDR memory bus (266 Mhz).

SMA is a handicap even for wider buses and impacts severely in general performance of graphics applications. What do you think about this?
For the resolutions we're talking about it's going to be not so much of an issue. It will impact performance; but most people's thinking about UMA type GPUs is that people insist on running past WVGA resolutions on their gaming machines and past about 800x600, the machines just can't keep up with most of the UMA type designs, mostly because they don't have vertex shading, etc. It's going to bog things down a bit, but most of the UMA stuff's been slow, more because the UMA parts have been crippled than UMA severely impacts performance.

My biggest concern overall is going to be how big of a game that I can place on there with the OS, the game, and the GPU all vying for that 128MiB in the SOC.
 
Last edited by a moderator:
Sphinxter said:
Swapping is unpleasant at any speed and should be avoided at the design stage if at all possible .
Won't have me arguing. However, you may encounter swapping at the entry/exit edges of a game if it's a bit on the largish side. Some of these titles are going to want a huge honkin' chunk of the system memory on load and you either swap out or have to do a warm reboot to get the OS back.
 
Last edited by a moderator:
Svartalf said:
Sphinxter said:
Swapping is unpleasant at any speed and should be avoided at the design stage if at all possible .
Won't have me arguing. However, you may encounter swapping at the entry/exit edges of a game if it's a bit on the largish side. Some of these titles are going to want a huge honkin' chunk of the system memory on load and you either swap out or have to do a warm reboot to get the OS back.

Huh?? Why the hell would the system let you swap in the first place? Why would there be any swapping? It doesn't make sense that anyone should let any app swap to the SD (utter nonsense) so if you try to use more than you can your allocations should just fail. I don't see why it should be any different.
 
Last edited by a moderator:
sindbad said:
Swapping unused memory would sometimes help.
Memory swapping works well when you are seriously running more than one app at once.
If your game needs to mem swap, this simply means that you're using more memory than is available, leading to low efficiency memory usage. If you find you need to use more memory than you have, you're probably not doing it right.
 
Last edited by a moderator:
sindbad said:
Swapping unused memory would sometimes help.
No. Not on a console, and mainly not on a SD card.
 
Last edited by a moderator:
Remember this is not a console in the usual sense of the word... it will be able to do multitasking just like Desktop PCs and such, and there will be times when programs will just need more memory. Not because they are using too much, but because something else is also running and it has no way to know it! And then what, you just crash them? Imagine you're writing your e-mail or something and the OS tells you "sorry, out of memory. I'm closing now".

I mean, at least have a popup or somethingto tell the user "hey we are swapping, this is not good, close something" but simply denying memory requests is plain stupid.

Moreover, flash wearing aside, swapping to SD cards would also be a lot faster than to HDs.
 
Tinnus said:
Moreover, flash wearing aside, swapping to SD cards would also be a lot faster than to HDs.
http://www.tomshardware.com/charts/2-5-har...rmance,676.html
The slowest hard drive on that list is 22MB/s, though most run much higher
A class 6 SDHC card only guarantees 6MB/s, though many cards seem to boast "up to 20 MB/s"
20 < 22; hard drives are faster than SDHC cards.
 
Last edited by a moderator:
WizardStan said:
Tinnus said:
Moreover, flash wearing aside, swapping to SD cards would also be a lot faster than to HDs.
http://www.tomshardware.com/charts/2-5-har...rmance,676.html
The slowest hard drive on that list is 22MB/s, though most run much higher
A class 6 SDHC card only guarantees 6MB/s, though many cards seem to boast "up to 20 MB/s"
20 < 22; hard drives are faster than SDHC cards.


However, this only takes into account sustained throughput. It neglects access time, which is very important for disk swapping because small enough blocks have to be used in order to mitigate the amount swapped (so you don't suddenly take a ton of CPU time away to service every random memory miss). For instance, if a 4KB block is used then at 20 mb/sec it will only take 0.2ms to transfer it, but average seek time for a hard drive is a good 5ms on top of that. The SD card, on the other hand, will have latency in the microseconds range. Of course, this is amortized if the swapping happens with a good degree of locality.
 
Last edited by a moderator:
Back
Top