Next Generation Pandora

[berichandcreamy]

ohhhhh...

Well yeah, form factor wise I'm 100% Pandora. Definitely buying a Pandora and not an Egg. Just throwing this out there because depending on how many units you need to get volume pricing $75 sounds kinda cheap for a board? I'm not an expert or anything and a Pandora 2 would be years away but if there's a cheap way to get higher specs like keeping everything but just switching out the board I'd be all over it.


http://www.zii.com/Developer/SDKProducts.aspx#ZiiEGGFeatures

ZMS-05 Media Rich Application Processor
• Dual ARM processor cores
• High resolution - decode to 1080p/720p encode
• 1080p HDMI output
• Supports wide range of codecs e.g H.264, MPEG 1/2/4, WMV/VC-1
• Analog HD TV encoder
• Three independent 12/24-bit video units
• Three SDIO/MMC/CE-ATA controllers
• Mobile SDR, DDR and DDR2
• 64/32-bit data bus
• 1Gbyte address space

 

[darkblu]

richandcreamy, the zms pricing you're quoting is for the the zms 'system module' board - it's an SODIMM board for integration purposes, and not the one in the EGG. that one hosts 32GB of flash (vs 16GB on the SM board) and a wolfson audio chip (not found on the SM board) - it cannot cost $75 at this stage.

otherwise, yes, the zms is a very interesting chip - extremely capable in some aspects, and rather spartan in others. hopefully i'll be able to tell you more about it later.

edit:
correction: i was wrong - the system module board has the wolfson, but it doesn't have the wifi/BT chip, nor the GPS module.

 

[Vorporeal]

IIRC, the Zii is Creative's own SoC. The Zii EGG is dev hardware being produced with the Zii SoC in it.

 

[craigix]

I would be somewhat astonished if it had an OMAP4 seeing as these only exist as huge test boards in a tiny number of locations in the world.

I'd also like to say I'm thoroughly enjoying Exophase and Laurents conversation on re-compilers.

 

[ldesnogu]

Well I tried to convince Exophase to work with me, but he doesn't have the time to do so, now I'll harass ari64

 

[elwing]

OMAP4 uses dual-core Cortex-A9, this thing uses two ARM9 processors...

to add precision ARM926 core is the generation before the Cortex A8.
the Zii looks good, but i think it is worst than a pandora in raw power and it certainly is really far from an OMAP4 in term of power

 

[berichandcreamy]

Thanks for musing on my ponderings folks.

I have no idea what to do with myself till the pandora comes out. Gadget lust is set to maximum at the moment T_T.

 

[darkblu]

OMAP4 uses dual-core Cortex-A9, this thing uses two ARM9 processors...

to add precision ARM926 core is the generation before the Cortex A8.
the Zii looks good, but i think it is worst than a pandora in raw power and it certainly is really far from an OMAP4 in term of power

the generation before Cortex is ARM11* - that's ARMv6 (Cortex is ARMv7). ARM926 is ARMv5 (ARMv5TEJ, to be precise). that's what the DS (and DSi) and my cell phone have as their cpu's.

as re 'raw power' - the zms-05 has certain 'performance aspects' no other AP currently in a handheld device has. it's an entirely different phylosophy than the omap.

 

[Exophase]

Well I tried to convince Exophase to work with me, but he doesn't have the time to do so, now I'll harass ari64

Haha, that's an excellent target you've picked there. He's probably better at recompilers than me anyway.

as re 'raw power' - the zms-05 has certain 'performance aspects' no other AP currently in a handheld device has. it's an entirely different phylosophy than the omap.

If you know something about this thing's hardware I'd love to hear more.

 

[darkblu]

If you know something about this thing's hardware I'd love to hear more.

so far i know little more than what the whitepapers state.

http://www.ziilabs.com/products/processors/zms05.aspx
http://www.ziilabs.com/downloads/datasheet/

the chip has very little specialized silicon, it's high performance comes entirely from stream-based GP. what i know is that it performs impressively at h264 decoding, and the same silicon does OGL vertex and fragment workloads, bitblt's and accelerated compute kernels.

any day now (tm) i'll have my iphone gl code running on it, so i'll be able to share more.

 

[Exophase]

Although I knew it didn't have dedicated blocks for any of that, I'm still not totally sure if it has a bunch of processor-like units or say, FPGA blocks. I'm probably being misled by their usage of the word "reprogrammable."

If it's basically a big array of shader-like SIMD processors then I wonder what kind of special functions they have that makes them better than usual CPUs. For instance, something that makes them better at perspective correct interpolation and texture lookups than a traditional vector CPU would be, because otherwise I have to question how good they'd be at 3D (unless they do have silicon for that somewhere and are just using these cores for the typical shading jobs). In order to perform fast blits and other DMA like operations they should have very good burst read/write without interfering with cache and it'd also be preferable if they can handle unaligned accesses and possibly things like masked writes. Geez, I really want to know about this architecture now. I'm sure they could get much much better utilization of it if they'd let people actually program on it instead of just using the programs they've written..

Actually, isn't 42 million textured pixels per second on the rather pathetically low end, especially if a lot of overdraw isn't being removed? A Nintendo DS can do 30 million and its 3D resolution is only 256x192. It's also a really weak architecture. Can't SGX in Pandora alone do a good 5 times that, with TBDR no less?

2.6GB/s memory bandwidth.. that means 64bit DDR/DDR2 SDRAM at 166MHz right? I wonder if anyone is going to want to use such wide RAM on a portable..

 

[ari64]

Well I tried to convince Exophase to work with me, but he doesn't have the time to do so, now I'll harass ari64

Harass me about what, x86 emulation?

 

[darkblu]

Although I knew it didn't have dedicated blocks for any of that, I'm still not totally sure if it has a bunch of processor-like units or say, FPGA blocks. I'm probably being misled by their usage of the word "reprogrammable."

during my tinkerings with it i've stumbled across the term 'microcode' in there, so something should be re-configurable in the array processor (that's how they call the media engine, informally), but i sincerely doubt it would reach FPGA levels.

If it's basically a big array of shader-like SIMD processors then I wonder what kind of special functions they have that makes them better than usual CPUs. For instance, something that makes them better at perspective correct interpolation and texture lookups than a traditional vector CPU would be, because otherwise I have to question how good they'd be at 3D (unless they do have silicon for that somewhere and are just using these cores for the typical shading jobs).
..
Actually, isn't 42 million textured pixels per second on the rather pathetically low end, especially if a lot of overdraw isn't being removed? A Nintendo DS can do 30 million and its 3D resolution is only 256x192. It's also a really weak architecture. Can't SGX in Pandora alone do a good 5 times that, with TBDR no less?

the second bold answers the question in the firs one.

they don't seem to have dedicated TMU silicon, as, by the quoted numbers, their pipeline takes a serious hit from texturing. for reference, the predecessor to the zms-05, the dms-02, is rated at 200Mpix/s, @ 4.8GLOPS and 1.6GB/s - much lower baseline metrics than the zms. so i expect texturing to be the achilles' heel of the vector array, yielding much lower results than untextured. but again, i'm yet to perform the proper measures. apropos, 42Mpix/s is in the ballpark of the original iphone/ipod touch (~50MHz pipeline, 1 ROP), and i have no info of the 3GS' SGX measures, but i suspect it's 2 pixel/clock max rate, at whatever the thing's clock is, so it shouldn't be that much either.

2.6GB/s memory bandwidth.. that means 64bit DDR/DDR2 SDRAM at 166MHz right? I wonder if anyone is going to want to use such wide RAM on a portable..

i don't know what the zii uses, but if it's the same as the zms system module, that one _is_ 256MB 64bit mDDR. man, you should see how the thing eats through 720p videos - not even some of my desktops can do that ; )

 

[Exophase]

SGX: 2/pixel clock at 110MHz = 220 million per second. Way more than 42. If Pandora only had ie 42M fragment shader cycles per second then I think people would be panicking.

Since you mention this, it brings to question exactly what kind of texturing we're talking about. Are the coordinate interpolations perspective correct? This applies to both texturing and shading, although with the latter it'd be much less noticeable. What level of filtering? I think we can assume off the bat that mip-mapping and trilinear/anisotropic are out, but is this number even with bilinear filtering? Because it occurs to me that software texture lookup w/o filtering would be much faster than nearest lookups. This is of course only as true as it lacks specialized instructions for this. But even with modest hardware support for interpolation it'll be much slower this way, so I wonder if they'd really not give two numbers if the unfiltered result was 4x better? Or more likely, the 42M is already unfiltered.

Guess I'll have to wait for more information.

 

[ldesnogu]

Well I tried to convince Exophase to work with me, but he doesn't have the time to do so, now I'll harass ari64

Harass me about what, x86 emulation?

Yes

 

[darkblu]

while you will have to wait for the substantial portion of information, i can tell you right now that they do mipmapping. actually, they heartily recommend it, which is not surprising at all, as mipmapping = better texel coherency = better caches utilization, and the vector array does not seem to have any sizable local buffers (ala edram), aside from its caches. moreover, they support dxt compression, but that should not come as a surprise, given the vector array is a potent vector cruncher which prefers single-memory-access fetch patterns.

 

[Exophase]

While mip-mapping may improve spatial locality of reference it's also not exactly computationally free. You would have to compute shifts to adjust the texture base locations and offsets, so again, unless they have dedicated hardware for doing something like this (or I don't understand of a faster approach, maybe they have very fast parallel LUT access) then it's going to cost a few more cycles per pixel. In cases where the texturing doesn't benefit much from mip-mapping anyway I'd prefer to save those cycles.

 

[neko]

While mip-mapping may improve spatial locality of reference it's also not exactly computationally free. You would have to compute shifts to adjust the texture base locations and offsets, so again, unless they have dedicated hardware for doing something like this (or I don't understand of a faster approach, maybe they have very fast parallel LUT access) then it's going to cost a few more cycles per pixel. In cases where the texturing doesn't benefit much from mip-mapping anyway I'd prefer to save those cycles.

One algorithm I've seen as an alternative to mipmapping is to store the texture such that each pixel is stored as the sum of all the pixels above and to the left. You can then sum any rectangular area by adding/subtracting the four corners. Instead of shifting the address/offsets, you shift the data. Also, unlike mipmapping, this allows scaling textures at oblique angles.

 

[Exophase]

One algorithm I've seen as an alternative to mipmapping is to store the texture such that each pixel is stored as the sum of all the pixels above and to the left. You can then sum any rectangular area by adding/subtracting the four corners. Instead of shifting the address/offsets, you shift the data. Also, unlike mipmapping, this allows scaling textures at oblique angles.

This is for correct interpolation over pixels that span many texels, right? This would improve image quality in the same way mip-mapping would , but I don't think darkblu was saying it's recommended for image quality purpose. Rather it was suggested for improving spatial locality of reference, which this wouldn't help. Actually, things would be quite worse since you'd have to make texels much larger to store the sums of (potentially) the entire texture.

I like the idea though. I might try that for audio interpolation some time.

 

[SNESFAN]

The new x86 intel atom N450 "Pineview" looks promising looks to give ARM procs a run for their money... x86 system on a chip
http://en.wikipedia.org/wiki/Intel_atom#Future

can't find much info on NM10 "Tiger Point" chipset, I'd like to see the projected power consumption, here's what's out there now
http://en.wikipedia.org/wiki/Intel_chipsets#Mobile_Chipsets

EDIT: found more info wonder how this matches up to the current pandora power consumption
http://news.softpedia.com/news/Intel-Pineview-Processor-Family-Detailed-113874.shtml