iPhone/Zune/iPod & More Prediction Thread

We will Zii Egg you. I wonder if it's the Zii or still fixed function hardware handling "HD Camera" video capture (hopefully they meant HD video, because HD photo capability is obvious laughingstock)

http://www.engadget.com/2009/07/07/creative-zii-and-zii-egg-touchscreen-handhelds-served-up-by-fcc/
i didn't see that coming. and that ziilabs' zms05 is quite an interesting AP. it's the first piece of hw i've seen to conbine ARMv5TE-class (dual) cpu with a shader-based GPU. it's like as if nintendo ds was running with an gl es2 hw. or my cell phone, for that matter.

all of a sudden i'm very curious of that AP. fillrate is in the pre-3GS iphone range, but as we know that sufficed for quite a while with apple's devices.

any idea how one can get a ziiegg?
 
You can pre-order it on their website for $400.

Two ARM 926 CPU's may be too slow. They also don't indicate clock speeds and nobody knows what this StemCell processors really do.

thanks for the heads-up.

from this datasheet here
http://www.ziilabs.com/products/ziilabs_zms05_datasheet_28JAN09.pdf

it appears the dual ARMv5 can go as high as 666MHz (that's the max rate of the AP's PLL) and the media engine is a flexible SIMD array with single and half fp support, multi-threaded and cache -backed. one can think of it as a unified shader engine, i guess.

zms05 datasheet said:
o Media Processing Array - Architecture
. High compute density SIMD architecture
. 24 Processing Elements (PE) in 3 clusters
. Each cluster runs the same or independent code
. Multiple High bandwidth memory paths
. Advanced hierarchical cache structure
. Random access to memory per PE
. Shared access to ARM memory
. Independent DMA controller per cluster
. Integer, IEEE 32-bit and 16-bit floating point
. Pre-emptive task switching
. Independent frequency scaling
. Independent voltage domain
 
it appears the dual ARMv5 can go as high as 666MHz (that's the max rate of the AP's PLL) ...
Ah, I never stumbled into that data sheet.

They're pretty specific about the clocks of a number of blocks, but don't really say anything for the CPU's. According to ARM, a 926 goes up to 470MHz in 90nm, but they don't say anything about smaller processes.

The two 666MHz PLL's could also be the ones for MC or the processing array. Two is pretty low for such a device, I assume there's a couple more PLLs for specific interfaces.
 
Built upon 3DLabs' DMS chips. Counted as inhouse Creative.
if somebody told me 4 years ago we'd be getting a 3dlabs-tech-powered ipod i'd have looked at them with, well, some disbelief ; ) but look where we are now.

it seems we're finally finding the ballance spot in the cpu/gpu battles. autonomous 'shader' engines that can work on a bunch of tasks, morphing to adapt various API forms, have been obsoleting the classic gpu, and now even in the most watt-sensitive segment. that indicates the concept is working, and is fairly mature.

i think i might order a ziiegg just on principle ; )
 
...

it seems we're finally finding the ballance spot in the cpu/gpu battles. autonomous 'shader' engines that can work on a bunch of tasks, morphing to adapt various API forms, have been obsoleting the classic gpu, and now even in the most watt-sensitive segment. that indicates the concept is working, and is fairly mature.

I'd say you're jumping the gun somewhat here as there is insufficient information on performance and power consumption to really draw any concluesions. I would say that it remains a reasonable assumption that this type of architecture will not be as power efficient as dedicated HW when it comes to things like encode/decode, and, as far as 3D is concerned the quoted fill rate should be enough to raise a flag on how well it handles that type of workload.

John.
 
I'd say you're jumping the gun somewhat here as there is insufficient information on performance and power consumption to really draw any conclusions. I would say that it remains a reasonable assumption that this type of architecture will not be as power efficient as dedicated HW when it comes to things like encode/decode, and, as far as 3D is concerned the quoted fill rate should be enough to raise a flag on how well it handles that type of workload.
well, i'm clealy being enthusiastic here. and i too think power efficiency has been the main question mark in designs like this one (i.e. larabee's and such). but at the same time, i don't think we need to think in absolute terms - a 'GP' shader architecture needs be in the same ballpark wth the GPUs in terms of power efficiency to already present a viable opportunity. i'm willing to trade in ultimate power efficiency for some versatiliy and programmability. after all, we've been paying the price of programmability in CPUs for generations now - how are the 'media' processing (i.e. vector stream crunching) tasks different in this regard?

as re the fillrate - the first gen iphone/ipod were doing fine with very similar fillrates (given, with HSR in addition) on the same output res. i don't see why the ziiegg should do much worse.
 
I just found out my wife ordered the Zii Egg SDK for me as an anniversary present. I'm personally more interested in general purpose app/Android development than the raw 3D power, but the whole package is very exciting to me. They're supposedly shipping by the end of August.
 
well, i'm clealy being enthusiastic here. and i too think power efficiency has been the main question mark in designs like this one (i.e. larabee's and such). but at the same time, i don't think we need to think in absolute terms - a 'GP' shader architecture needs be in the same ballpark wth the GPUs in terms of power efficiency to already present a viable opportunity.
My view on this is that you need to hit a base level of peformance before you can go fully programmable, that level of performance is probably two to three orders of magnitude higher than where we are in the handheld space right now. Incedentally I'm not convinced larabee has proven anything here yet either.

i'm willing to trade in ultimate power efficiency for some versatiliy and programmability.
But how much battery life are you willing to trade? You happy with only being able to watch 60 minutes of video vs 10 hours plus? Are happy having to recharge your phone every few hours vs every day or two?

after all, we've been paying the price of programmability in CPUs for generations now - how are the 'media' processing (i.e. vector stream crunching) tasks different in this regard?
It depends on the specific task you're looking at, if you look at video encode/decode you typically see up to an order of magnitude difference in the power envelope for fixed function vs programmable. This is primrily due to the standardisation of algorithms used which makes programmabiliy of these functions largely superfluous.

as re the fillrate - the first gen iphone/ipod were doing fine with very similar fillrates (given, with HSR in addition) on the same output res. i don't see why the ziiegg should do much worse.
Apple did a great job with the original iPhone, however the 3GS is a much more snappy user experience, given the choice I doubt people would accept the lower performance version. Basically why accept a step backwards?

To be honest, I think the bigger question is why do you think you need this level of programmability i.e. what accessible benifits do you think you're gaining from it?

Cheers,
John.
 
To be honest, I think the bigger question is why do you think you need this level of programmability i.e. what accessible benifits do you think you're gaining from it?
my rationale is simple, John. i want 'decent' programmability from my pocketables for the same reason the industry seeks OpenCL from the desktops.

i don't view a pocketable as a 'video player', a 'music player' or any other type of appliance. i think of them as mobile computers. as such, i expect them to be useful (not necesserily stellar) in the broad range of tasks (or a sufficient subset of) i generally expect a personal computer to handle. so i'd rather have a pocketable device that is usable in a variety of situations rather than one which is the ultimate video player.

see, you can think of this as a sort of transistor metrics: usefulness of the transistors i have to carry in my pocket. by that, the best video-codec mobile ASIC in the world still does not fare as well as something less good at video codecs, but more widely used in my daily routine.

as regarding power efficiency - the moment a pocketable can last me a day on a recharge, that moment it has met my a-ok. yes, ideally i'd like my devices to be insanely power-efficient, but at the same time i am realistic enough to work with what's available. for the record, my home desktop machines are all selected on the principle 'just enough power to meet my routine' - my linuxbox is an efika machine, and my 'fancy desktop' box is a ppc mac mini. so as you see i'm not some powermonger (neither do i play games on my desktops - this is what game consoles are for).
 
Last edited by a moderator:
Industry? Isn't OpenCL mostly an Apple thing?

Remains to be seen if the implementation lives up to the hype.
 
Industry? Isn't OpenCL mostly an Apple thing?
how is it an apple thing? it's an (open) standartization of something that has existed before in one form or another, and whose mainstream adoption (or need thereof) has led to said standard. the fact that some os vendors would rather adopt an open standard than try to impose a proprietary one does not make it 'an apple thing'.

Remains to be seen if the implementation lives up to the hype.
it's a tool of the trade. those who need it and know how to use it may find it useful, or even indispensable. for the end user it has no significance whatsoever.

and whether particular implementations will be successful or not does not void the need for the tool. unless you want to argue that CUDA, dx compute, etc. are all artificial, unnecessary developments.
 
my rationale is simple, John. i want 'decent' programmability from my pocketables for the same reason the industry seeks OpenCL from the desktops.

i don't view a pocketable as a 'video player', a 'music player' or any other type of appliance. i think of them as mobile computers. as such, i expect them to be useful (not necesserily stellar) in the broad range of tasks (or a sufficient subset of) i generally expect a personal computer to handle. so i'd rather have a pocketable device that is usable in a variety of situations rather than one which is the ultimate video player.

see, you can think of this as a sort of transistor metrics: usefulness of the transistors i have to carry in my pocket. by that, the best video-codec mobile ASIC in the world still does not fare as well as something less good at video codecs, but more widely used in my daily routine.

as regarding power efficiency - the moment a pocketable can last me a day on a recharge, that moment it has met my a-ok. yes, ideally i'd like my devices to be insanely power-efficient, but at the same time i am realistic enough to work with what's available

I think you're missing my point here. If the power consumption is so high that when you are watching a video the battery runs down after an hour of use the device then becomes useless for the other task you want to use it for.

OpenCL is an interresting development, however it is also designed to run on GPUs so there is no inherent advantage to having a "sea of CPUs" vs a GPU with a sea of shaders, in fact the GPU has the advantage that it will also run graphics work loads (a lot) faster with less power consumption.

Incedentally there is no proof that this partuicular device will enable you to do any of the tasks you think you want to do with it any better than any other device (which is why I think you're jumping the gun!).

. for the record, my home desktop machines are all selected on the principle 'just enough power to meet my routine' - my linuxbox is an efika machine, and my 'fancy desktop' box is a ppc mac mini. so as you see i'm not some powermonger (neither do i play games on my desktops - this is what game consoles are for).

The correct question here is at what point do you think these machines met the bar for being "just enough for your routine" and how do you think that compares to the power of something like an iPhone or iPhone GS?

Alternatively why should we settle for things being merely adequate?

John.
 
I think you're missing my point here. If the power consumption is so high that when you are watching a video the battery runs down after an hour of use the device then becomes useless for the other task you want to use it for.
if that's indeed the case then the device will most likely not meet its 'a-ok' status with me (even though i seldom watch videos on my handhelds for hours on). as of now we don't know how it fares there, though.

OpenCL is an interresting development, however it is also designed to run on GPUs so there is no inherent advantage to having a "sea of CPUs" vs a GPU with a sea of shaders, in fact the GPU has the advantage that it will also run graphics work loads (a lot) faster with less power consumption.
well, i never said the classic GPU does not hold the speed and/or efficiency crown at graphics. all i said was that if it only does that then it'd have less value to me than something else that does graphics not so well, but which is also usable in a bunch of other task domains. as re OpenCL, while it has clear provisions for GPUs, it does not limit itself to GPUs only.

regardless, i'd be very interested in a handheld that features OpenCL. i'm not seeing one coming, though. for instance, apple, the big adopter of the API, are quite stingent when it comes to fully exposing the programmable features of their beautiful fenced garden (vertex shaders on the VGP, anybody?). i'd love to be proven wrong, though.

Incedentally there is no proof that this partuicular device will enable you to do any of the tasks you think you want to do with it any better than any other device (which is why I think you're jumping the gun!).
it may just as well seem from aside that i'm jumping the gun, but from my perspective i'm just hopeful that they (creative) may be actually taking steps in the general direction i think these devices will move on in the future. IOW, i'm giving them the benefit of the doubt. i'll also be checking that first-hand as i've pre-ordered their SDK kit.

The correct question here is at what point do you think these machines met the bar for being "just enough for your routine" and how do you think that compares to the power of something like an iPhone or iPhone GS?
i'm taking you're asking me how i see the power of devices like the iphone in the context of their daily use?

i find them fairly adequate power-wise (the GS clearly more so. when it comes to graphics, at least). it's what tasks i can (respectively, cannot) use them for that bothers me. that latter is usually a resuilt of the platform's hardware *and* software features and policies, of course. or from a dev's perspective, it's the hardware and its 'de-facto' programmable features.

as it stands, the iphone GS' fairly-power-adequate GPU currently gives me a fancy GUI (which the the old MBX does almost as well), and the odd es2-tailored game (not yet, but any time now). it also allows me to do es2.x R&D, but for that i have to be sitting at my desk, with the device hooked to my desktop - nothing mobile there - for the purpose i could just as well use an emulator. and when you think of it, its transistor budget is comparable to the device's CPU. so why am i carrying all those transitors around, when i could be carrying an equal, but more useful bunch of them?

Alternatively why should we settle for things being merely adequate?
why shouldn't we? i find the adequacy criterion quite practical. we're not talking art or sports here, we're talking use and function.
 
Unless I'm reading something wrong out of that list that multimedia SIMD thing is actually SIMD per cluster with a MIMD connection between clusters.

If manufacturers need only a GP processor they could always alternatively license just IMG META where they'd also have pure MIMD units from the get go or go for a full GPU under SGX which has MIMD units at its heart already.

Each manufacturer should know why they're integrating in device X hardware Y. As for GPGPU would something like image processing do the trick for some of you?
 
darkblu, with all due respect to the ex-3DLabs/Creative guys, the Zii architecture isn't worth a billionth of the hype it has received. It's just not that great in practice. It's a relatively big chip with power consumption that's nothing out of the ordinary for what it does, and certainly much worse than good fixed-function-centric solutions. As for 3D performance - I don't have the exact data at my disposal, but I wouldn't be surprised one iota if the iPhone 3GS was a full order of magnitude faster. That's not what I call "good enough", especially given the higher die size and power consumption.

The ZMS-05 architecture makes me think of Broadcom's VideoCore. I actually think Broadcom's die size and power consumption are better though. Interestingly, it is my understanding that both architectures were designed in the UK. It's quite amazing how nearly every innovative/exotic parallel processor is engineered in the UK (I'm including ImgTech stuff in there John, don't worry). Good ole Inmos/Transputer legacy!

Certainly for unorthodox workloads, it's nice to have an innovative parallel processor at your disposal and it's good that they're making a SDK available. I'm sure it must be interesting to program for; if I had the time (which I obviously don't, see my lack posting in recent times) I might even be tempted to try. But that doesn't mean future architectures that do move towards much greater flexibility will look like that; it's not quite the holy grail Creative would like it to be.
 
Back
Top