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.
