Tegra 3 officially announced; in tablets by August, smartphones by Christmas

But none of her bandwidth works out for GPU composition when the GPU is a tiler. And that applies to PowerVR, Qualcomm, and ARM GPUs which along with nVidia should be taking a majority of shares. This is giving credence to her further claim that most 2D compositing is translucent and therefore bandwidth isn't saved by deferred rendering..
Is Tegra tile based too?

I thought not.
 
Either way, 16bpp output shouldn't give you much of a bandwidth benefit over 32bpp.
Well something about 16bpp gives a noticeable speed boost. It particularly improves scrolling speed of the stock web browser for example. CM7 is Gingerbread btw and it doesn't use the GPU hardware as much as Android 3/4. Seeing a speed boost with 16bpp brings me back to the '90s because old PC 2D cards also were faster at 16bpp than 24/32bpp.
 
Ailuros said:
Under that reasoning they won't be needing a Tegra3 either.
I agree.

They need something faster eventually, but they don't need to participate in the meaningless performance rat race of other Android vendors who have only tech specs to differentiate themselves.

It's nice to be Apple or Amazon and be able to set your own rules.
 
Is Tegra tile based too?

I thought not.

No, it isn't. My post might have been unclear on that point. But in terms of tablet and phone sales overall Tegra is hardly a majority holder.

swaaye said:
Well something about 16bpp gives a noticeable speed boost. It particularly improves scrolling speed of the stock web browser for example. CM7 is Gingerbread btw and it doesn't use the GPU hardware as much as Android 3/4. Seeing a speed boost with 16bpp brings me back to the '90s because old PC 2D cards also were faster at 16bpp than 24/32bpp.

Sure, it gives a measurable benefit because it relates to things that aren't being done with the GPU. Blending in particular can be a lot slower in software if it's done in 32bpp instead of 16bpp (especially if NEON is used), although I'm not sure if the output format impacts the internal precision. But that's contrary to the point the blogger was making.
 
Saw this on another forum about possible reason the Android UI isn't smooth:


Android UI will never be completely smooth because of the design constraints I discussed at the beginning:

- UI rendering occurs on the main thread of an app
- UI rendering has normal priority

So why did the Android team design the rendering framework like this?

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.
 
One interesting point is that it's Qualcomm who engineered the new 'tiled rendering' mechanism for the ICS Browser and it is already available in some Qualcomm-based Android 2.3 devices. I had a very good conversation with Sayeed Choudhury at MWC11 and they've actually got a pretty large team (iirc nearly 50 engineers) dedicated just to web optimisation - and everything they do, they eventually open source and allow everyone to use free of charge.

Two interesting points on the tiled implementation is they are NOT square tiles which they claim is more efficient than Apple's approach and that the software rendering for invisible tiles happens in the background so there's a very slightly higher benefit to multicore. Another example of a Qualcomm optimisation is Javascript V8 for ARM which was implemented by 4 Qualcomm engineers and 2 V8 engineers (which they benefited from by making sure the code was well tuned for long in-order pipelines like Scorpion's - and he said they did some special stuff in Krait for JITs too).

Given how much of the optimisation process is done by Google's partners (e.g. NV for Honeycomb), I'd rather not think too much about how bad it would be without their help. I tip my hat to Qualcomm and everyone else helping Google make the Android UI experience more competitive.

Also is it just me or does Andrew Munn's explanation imply that quad-core might be more beneficial than expected for UI smoothness? Not that the Transformer Prime reviews imply any miracles on that front sadly, here's hoping it's better with ICS...
 
Also is it just me or does Andrew Munn's explanation imply that quad-core might be more beneficial than expected for UI smoothness? Not that the Transformer Prime reviews imply any miracles on that front sadly, here's hoping it's better with ICS...

Please don't hurt me but IMHO to expect stronger hw to cover for sw related shortcomings is just lacklustering engineering. And that's obviously not exclusively directed at T3 or any particular other SoC. The feeling I get while reading all those links is that even dated hw could cope well if some aspects would be different. The good thing is that they obviously know what's wrong and here's to hope that the next OS revision will be a lot better.
 
One interesting point is that it's Qualcomm who engineered the new 'tiled rendering' mechanism for the ICS Browser and it is already available in some Qualcomm-based Android 2.3 devices. I had a very good conversation with Sayeed Choudhury at MWC11 and they've actually got a pretty large team (iirc nearly 50 engineers) dedicated just to web optimisation - and everything they do, they eventually open source and allow everyone to use free of charge.

Two interesting points on the tiled implementation is they are NOT square tiles which they claim is more efficient than Apple's approach and that the software rendering for invisible tiles happens in the background so there's a very slightly higher benefit to multicore. Another example of a Qualcomm optimisation is Javascript V8 for ARM which was implemented by 4 Qualcomm engineers and 2 V8 engineers (which they benefited from by making sure the code was well tuned for long in-order pipelines like Scorpion's - and he said they did some special stuff in Krait for JITs too).

Given how much of the optimisation process is done by Google's partners (e.g. NV for Honeycomb), I'd rather not think too much about how bad it would be without their help. I tip my hat to Qualcomm and everyone else helping Google make the Android UI experience more competitive.

Also is it just me or does Andrew Munn's explanation imply that quad-core might be more beneficial than expected for UI smoothness? Not that the Transformer Prime reviews imply any miracles on that front sadly, here's hoping it's better with ICS...

On a reltated note..Do you know how things went down for Windows Phone 7? It seems that Microsoft handled everything by themselves but I would guess that Qualcomm must have had a big part in the optimization process given that they are the only SoC provider for the platform. As of right now WP7 is the only thing that comes close andeven surpasse iOS in UI smoothness and fuilidity (on realtively ancient SoCs too).
 
Please don't hurt me but IMHO to expect stronger hw to cover for sw related shortcomings is just lacklustering engineering. And that's obviously not exclusively directed at T3 or any particular other SoC. The feeling I get while reading all those links is that even dated hw could cope well if some aspects would be different. The good thing is that they obviously know what's wrong and here's to hope that the next OS revision will be a lot better.

But hasn't that been the case for a long time now, what with Moore's law and expectations of greater resources (RAM), that software isn't developed for efficiency so much as features? New OSes can't run well on older hardware but they bring new features so it's suppose to be worth buying new hardware.

Maybe programming for consoles requires squeezing every last bit of performance out of limited resources which are static for 5 years -- though with multi platform ports, maybe they're not optimizing to the degree they used to.

Mobile devices have limited resources but they're turning over -- new SOCs every few months, along with new devices which have once CPU, GPU, RAM. So when iPhone 4 becomes half the installed base in about 15 months, developers can target it rather than the 3 preceding models.
 
But hasn't that been the case for a long time now, what with Moore's law and expectations of greater resources (RAM), that software isn't developed for efficiency so much as features? New OSes can't run well on older hardware but they bring new features so it's suppose to be worth buying new hardware.

Did you even read the link provided above? Occassional stutters haven't disappeared on Android, the problem is mostly getting smaller as stronger hw arrives. I'm asking about a solution to problem at hand (sw) and not a band aid (hw).

Maybe programming for consoles requires squeezing every last bit of performance out of limited resources which are static for 5 years -- though with multi platform ports, maybe they're not optimizing to the degree they used to.

Mobile devices have limited resources but they're turning over -- new SOCs every few months, along with new devices which have once CPU, GPU, RAM. So when iPhone 4 becomes half the installed base in about 15 months, developers can target it rather than the 3 preceding models.

Good hw requires good sw; any of the two lacklustering is not going to get you well rounded device. And no I'm not even thinking in a closed box as iOS vs. Android or anything related but in general terms.

Fairly simple: assume you're playing a demanding PC game which due to sluggish programming takes severe occassional framerate nosedives. Would you prefer a patch from the ISV that developed a game or would you run to the next best store and buy a twice as powerful machine? With which alternative do you get a real solution to your problem?
 
One of the few things I've noticed about the occasional lag has to do with the clock-throttling each CPU does. For things like touchscreen response, it becomes very difficult for the OS to properly schedule when it will need the CPU at a high frequency -- when the user's fingers move -- compared to not.

A better solution would be to have a small dedicated processor that could stay at or near peak clock-rate for such cases. But that would require the OS to schedule UI handling on that processor alone.
 
One of the few things I've noticed about the occasional lag has to do with the clock-throttling each CPU does. For things like touchscreen response, it becomes very difficult for the OS to properly schedule when it will need the CPU at a high frequency -- when the user's fingers move -- compared to not.

A better solution would be to have a small dedicated processor that could stay at or near peak clock-rate for such cases. But that would require the OS to schedule UI handling on that processor alone.

That.. or they assign the highest priority to the UI.. as suggested by the other programmer.
It seems the problem is that the top dogs over at the android development team simply don't think the UI responsiveness is more important than many other tasks.

iOS has had "instant" responsiveness since 3GS with a 600MHz A8 + SGX535, WP7 had it with 1st Gen snapdragons 1GHz + Adreno 200, Symbian^3/Anna/Belle has it with 680Mhz ARM11 + BCM2727..
There's no way that a dedicated CPU/microcontroller would be considered an elegant solution for the UI responsiveness problem.
 
That.. or they assign the highest priority to the UI.. as suggested by the other programmer.
That won't do. It will need rearchitecting Android big time. Apps will have to move to an async model for UI rendering where the apps create UI command buffers and submit it to the rendering thread.
It seems the problem is that the top dogs over at the android development team simply don't think the UI responsiveness is more important than many other tasks.

That's not the case. Their constraints are different.
 
That.. or they assign the highest priority to the UI.. as suggested by the other programmer.

That won't fix some of the lag issues that has to do with clock-throttling. With monster CPU's, there is some aggressive throttling going on in the background. This wasn't an issue in the 600MHz A8's but with ~1.5GHz A15's, it is.

It seems the problem is that the top dogs over at the android development team simply don't think the UI responsiveness is more important than many other tasks.

They're not wrong that high-priority for UI threads is a bad solution -- at least with next-generation CPU's.

iOS has had "instant" responsiveness since 3GS with a 600MHz A8 + SGX535, WP7 had it with 1st Gen snapdragons 1GHz + Adreno 200, Symbian^3/Anna/Belle has it with 680Mhz ARM11 + BCM2727..
There's no way that a dedicated CPU/microcontroller would be considered an elegant solution for the UI responsiveness problem.

Sure it is. For future CPU architectures, ramping up to full speed within ~1ms is going to be bad for power. It's better to have a 600MHz A7 handle that thread; with less aggressive clock-throttling.
 
Fierce competition on the horizon or not, Tegra 3 looks like it is doing well at CES right now, with stuff like the:
Asus Memo 370T ($249!)
Asus Transformer Prime 700 1920x1200
Acer Iconia Tab a510 and ZTE 7 tablet
Acer Iconia Tab a700 1920x1200
Lenovo IdeaTab K2 1920x1200, 1.7 Ghz(!)
Fujitsu Arrows phone

Supposedly there's still the HTC Quattro tablet coming, along with the Edge and some other phone, and the Toshiba Thrive tablet. Who's next?

Not being the most patient of consumers, I went to the launch event for the Transformer Prime in Singapore today and brought home a 32GB for a quite reasonable EUR420. Plugged it in and the first thing it did was download and install ICS. Sweet! :D
 
Fierce competition on the horizon or not, Tegra 3 looks like it is doing well at CES right now, with stuff like the:
Asus Memo 370T ($249!)
Asus Transformer Prime 700 1920x1200
Acer Iconia Tab a510 and ZTE 7 tablet
Acer Iconia Tab a700 1920x1200
Lenovo IdeaTab K2 1920x1200, 1.7 Ghz(!)
Fujitsu Arrows phone

Supposedly there's still the HTC Quattro tablet coming, along with the Edge and some other phone, and the Toshiba Thrive tablet. Who's next?

Not being the most patient of consumers, I went to the launch event for the Transformer Prime in Singapore today and brought home a 32GB for a quite reasonable EUR420. Plugged it in and the first thing it did was download and install ICS. Sweet! :D

Oooh, I want one for that price too :D. I can only get the 32GB prime with keyboard dock or a 64GB Prime without keyboard dock, both for just a little under €600.
 
I went out and bought a Transformer 300 last week. So far I'm loving it, it's so much better than I thought it was going to be, and being able to dump apps directly to it from eclipse is so cool.
The whole tegra 3 setup is also a much better performer than I thought it would be. It actually makes using PS touch a realistic prospect.
Gaming's not too shoddy either, Shadowgun THD with a PS3 controller is practically a console level experience.
 
Transformer Infinity 700 GLBenchmark scores are out. This one has the Tegra T33, which is an upclocked version

It's finally faster than the Mali 400MP4 in Galaxy S2, yay.

The CPU info says it can clock up to 1900MHz, now that's aggressive.
 
Back
Top