Thanks for the info. Too bad. So it's just a marketing mock-up.
This is a (slightly fuzzy) shot, which I believe was part of apple's marketing stuff for the A4; The number you can make out are identical to the ones in the A5 chip; You'll probably have to wait for a production A5 to appear to work out if there are informative numbers present.
The thing is iOS is such a lame OS in terms of multitasking that the amount of RAM is less important than on more robust OSes like Android or webOS. I'm not trying to slam iOS here, just pointing out that, by design, it uses minimal RAM as it doesn't really multitask much. This is the same situation as the days of PalmOS vs. Windows Mobile 6.x where Palm didn't multitask and Windows did...as a results Palm's OS was fast and functional while Windows Mobile was just glacially slow.
analyst claims 512Mb of ram
I really don't see why apple just can't announce it... it's going to be a source of hundreds of conversations and free publicity for a week.
/sigh
I couldn't agree more. Here is my take on the leading tables (IMHO):
#1 for potential: HP TouchPad
- webOS simply kicks the shit out of iOS and Android for polish and speed. Spec's look good other than no SD slot (WTF?). HP quality a big issue. No cellular option (probably okay for me). They claim (behind closed doors, unofficially) that they will have Skype with video chat.
#1 for flexibility: Moto Xoom
- Android can range from great to really sucky and Xoom shows this nicely. Hopefully a large fragment of Android will coalesce on the Xoom flavor of Honeycomb. No word on when there will be skype...SD slot!!! though it still doesn't work. 4G upgradeability if your rich enough to afford a data plan.
#1 for predictable experience: ipad2
- "Facetime" is what Fring + Skype was two years ago on my Nokia phone with webcam. Skype dropped the ball big time and now "Apple has brought video calling to the masses." Point being it will work and work well and Skype will have a video app for the ipad2 before Android. It also has iWork which is as close as I've seen to polished MS Office compatibility on a tablet.
My ideal would be an unlocked GSM/GPRS Xoom running webOS with a huge SD card.
I left the BB playbook out simply because I haven't been following it...
Corrected for you.
Why would they change that?
Did someone figure out what the serial numbers on the A5 stand for? IIRC with the A4 it was possible to determine the amount of RAM based on these numbers. Or is this just a mock-up with bogus numbers?
You do realize that this is entirely by design, and that the OS has used the 1960s mainframe style multitasking you seem to like from the very start of iOS?The thing is iOS is such a lame OS in terms of multitasking that the amount of RAM is less important than on more robust OSes like Android or webOS. I'm not trying to slam iOS here, just pointing out that, by design, it uses minimal RAM as it doesn't really multitask much.
Playbook is a nice webOS look-alike, but 7" is just going to work for me. I'm old with bad eyes!
Is there a 10" playbook in the future?
TBDR (or even TBR for that matter) has no R/W cost on translucency, this is significant, so yes this is most definitely an major advantage of TBDR.I think after a z-pass, using EarlyZ, you have the same amount of texture fetching.
You're right about the transparent objects, but although you safe FB read/write, you have still high cost for those fragments, as the only thing you safe are FB Read/Writes, you execute the whole fragment program and fetch all the textures. I'd say, if you want to use that really for the advantage, you will be less slow with TBDR
The Z pass still consume a lot of read/modify write BW, every subsequent pass still consumes a lot of read BW, it becomes one of the most significant consumers in bandwidth terms.the zpass is usually very very cheap, you're right, you're either input limited or vertexshader limited, but if that's the limit, you're extremely fast.
It isn't, the IMR reads all data on each pass including all that that is frustum, back face or sub pixel culled, this is typically around 3x more data than post culling, TBDRs only read post culled data during the rasterisation pass.in TBDR it's probably more costly to output the interpolator data, than the vertex data reading during a zpass on an IMR.
Yes both architectures end up processing the same number of pixels, although IMR still suffers from very heavy BW, you've just moved it somewhere else (albeit possibly somewhat reduced).with zpass, I'd assume you could just increase your z-reject load, the amount of visible pixels will stay the same, and both architectures should react the same to that.
Yes there's a better solution, and no I'm not going to tell you what it isyou either spill out tesselated geometry, which would result in a huge amount of data or you execute the tesselation a lot of times (for every tile), which would lead in worst case to executing the domain shader hundret of times per vertex.
Do I miss a smarter (3rd) solution for that?
I didn't claim it has an disadvantage atm. but if the vertex amount rises as the compute-power rises (as it did on PC), you'll rather reach bandwidth issues with TBDR than with EZ-IMR.
The only TBDR advantage I see, that will probably always exist, is with massive alphablend drawing, but that's not real world (except maybe for some PS2 games).
To be fair, most Android apps don't do anything in the background either, and Android kills them just as readily as iOS does when a more important app needs more memory. The reality is that the vast majority of mobile apps use very little memory (compared to PC standards). The biggest memory consumer is probably tabbed browsing, and you don't even need multitasking for that.The thing is iOS is such a lame OS in terms of multitasking that the amount of RAM is less important than on more robust OSes like Android or webOS. I'm not trying to slam iOS here, just pointing out that, by design, it uses minimal RAM as it doesn't really multitask much. This is the same situation as the days of PalmOS vs. Windows Mobile 6.x where Palm didn't multitask and Windows did...as a results Palm's OS was fast and functional while Windows Mobile was just glacially slow.
They can't hide the amount of memory or the actual available bandwidth from developers. And people like iFixIt have made it quite clear that they will take the package apart and put the dies under a microscope, where they will inevitably find the manufacturer's markings.Because they have made it fairly clear that the information is privileged and they don't want people to know.
To be fair, most Android apps don't do anything in the background either, and Android kills them just as readily as iOS does when a more important app needs more memory. The reality is that the vast majority of mobile apps use very little memory (compared to PC standards). The biggest memory consumer is probably tabbed browsing, and you don't even need multitasking for that.
They can't hide the amount of memory or the actual available bandwidth from developers. And people like iFixIt have made it quite clear that they will take the package apart and put the dies under a microscope, where they will inevitably find the manufacturer's markings.
As far as I can tell Mobile Safari will continue loading a webpage when you switch to another app, too (though it won't instantly render it, so when you switch back you still see the contents where you left off for a moment).Actually, that's one of the cases where I find multitasking to be most important. IE on WP7 does this the best out of all the OS's I know. You can load multiple webpages from multiple tabs (and even leave the browser) and they'll load in the background.
As far as I can tell Mobile Safari will continue loading a webpage when you switch to another app, too (though it won't instantly render it, so when you switch back you still see the contents where you left off for a moment).
But that's not what I meant. What I was saying is that a tabbed browser, on its own, can consume a lot of memory. I don't think it's true that the amount of memory is less important on iOS because it doesn't do "real multitasking". However, I do think that with today's applications Android shouldn't have any problems with 512 MiB either.