Hacker News Reader

Comment by mrpippy | Hacker News Reader

Anand stated in a previous article that Chinese customers were basically demanding 64-bit 4 or 8-core SoCs, just to tick checkboxes on a spec sheet.

Of course it's pretty well established that 2 fast/wide cores (like Apple and Qualcomm's in-house designs) are better for current mobile software than 4 or 8 slower ones. And Android doesn't take any advantage of ARMv8 right now.

Another sad example of marketing trumping engineering reality.

View on HN

There's real value in having ARMv8 chips as soon as possible. First off, the architecture is significantly improved over ARMv7. It's not just the 64-bit support. Second, the transition to 64-bit is going to take 3-4 years after it begins anyway, which just means developers are going to have to support both 32-bit and 64-bit (and ARMv7 and ARMv8) for 3-4 more years, instead of just dumping ARMv7 as soon as possible, and supporting only ARMv8. The sooner everyone is moving to ARMv8, the better.

The 8-core thing is indeed mainly a gimmick, and I don't know if Anand has real data on "Asians wanting 64-bit", or he just lumped it together with the "Asians want 8-cores" (where there is some data to support that). But I think almost everyone wants 64-bit as soon as possible, because 32-bit chips are on their last legs, and especially if you only upgrade every 2-3 years, it wouldn't be wise to buy a 32-bit one right now, or you'll see some (not all) apps start dropping support for ARMv7 mid-life of your phone.

I think games that use take advantage of high parallelism would do better on the 8 core devices. We just don't see much of that kind of game in the mobile market.

We don't see that on the _desktop_ market.

We also don't see many 8 core chips on the desktop market. Chicken and egg problem.

Very few people have the incentive or funds to get either the hyperthreaded i7s (which don't really have 4 cores), the 8 core Xeons or the 8 core AMD high end parts.

Very few games can even use two threads to full capacity.

Aren't games of all stripes typically GPU bound rather than CPU bound these days, if they're complicated enough to be limited by the hardware at all? If so, dedicating more area to GPU cores would be better for them.

Depends on the game really; but generally yeah, the GPU will be the bottleneck. Games with a large number of calculations will be CPU bound though; StarCraft 2 is a good example of that.

Because both CPU and GPU are generally on the same bus in mobile devices, maybe you could use those extra CPU cores as fragment/pixel shaders, if memory and cache architecture doesn't prevent it.

On PCs that is not feasible, because of bandwidth and latency issues over PCIe. On mobile SoCs, who knows, maybe it'd work.

Just like in current PS3 titles, that offload shading from GPU to SPUs.

PS3 games don't offload fragment shading to the SPUs, that would be too slow and leave the pixel shading hardware on the GPU idle. Remember that the PS3 has separate vertex and pixel shaders. What they usually offload is post-processing, mostly for anti-aliasing.

I was talking about a technique where deferred rendering, GPU is used in modern PS3 games to render surface normals, material index, Z-buffer, texture color, etc. in a buffer. Typically 128 bits per pixel.

This buffer is then DMA transferred to SPUs, where final lighting and fragment shading is performed.

Final step is to transfer 32-bit RGB data back to GPU's frame buffer for displaying.

Here's a link about one implementation: http://www.slideshare.net/DICEStudio/spubased-deferred-shadi...

Do you have any sources for that? Not the Chinese part, but the processor benchmarks.

I'd be very interested in reading them!

Reply on news.ycombinator.com