Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pixel Visual Core: Google’s first custom-designed co-processor

blog.google

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#71

Post by joshuamorton »

sandGorgon wrote: post #66
trishume wrote: post #51

Earlier quoted context omitted.

Halide is much more flexible. OpenCV is a fixed high level toolbox, combining things requires lots of intermediate buffers. Halide allows compiling arbitrary kernels in a fused way with extremely good performance. Sure you could implement OpenCV functions using Halide, but better to expose the lower level more flexible API. Source: I’ve rewritten parts of an OpenCV app in Halide for performance. Also your argument th…

That bet is the problem. Tensorflow on mobile already targets GPU and is going to be even more so with XLA. This debate is going to be hearsay unless we have an apples to apples comparison of the base tensorflow code running on the halide ir targeted to the tpu vs a vanilla ARM GPU... Even using opencv. I find it telling that they compared cpu vs tpu... Not GPU vs tpu.

I'm really confused why you keep bringing up opencv. What does opencv have to do with the (presumably) TF ML model running on the IPU that you want to benchmark against the TF ML model running on a GPU?

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#72

Post by wmf »

simonh wrote: post #57

It seems odd to me that Samsung isn't doing things like this. After all they have both the chip design talent in house, they design their own Eynos chips, and even have the fabs in house as well. They're not as well regarded for software, but they do at least have some in house dev capability. A Samsung Galaxy with that sort of differentiation would, like this phone, make even a die hard iPhone user like me take seri…

Since half of Samsung phones use Snapdragon and half use Exynos, I've heard that Exynos is gimped to not exceed the features/performance of Snapdragon too much.

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#73

Post by bradleyjg »

bitL wrote: post #53

I wish my Nikon pro camera had a similar chip inside. Now we have two worlds - awesome pro cameras with incapable post-processing chips (I mean beyond RAW and initial processing) and horrible mobile cameras with outstanding post-processing chips.

If you have burst mode and can get the raw frames, then shouldn't you be able to recreate the effect in post-processing? With the severe power constraints of a mobile phone a co-processor makes sense, but I'd think a general purpose desktop processor could easily handle this algorithm.

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#74

Post by TheAdamist »

ggambetta wrote: post #47

> HDR+ addresses this problem by taking a burst of shots with short exposure times, aligning them algorithmically, and replacing each pixel with the average color at that position across all the shots. This is almost exactly how you'd make super-resolution pictures (adding a nearest-point scaling up step at some point! Yet their super-resolution app (Photoscan) has some sort of artificial upper resolution limit. If t…

Super resolution would want to utilize the OIS to artificially shift the lens around instead of cancelling movements. I dont think they are exposing anything like that.

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#75

Post by MBCook »

jrs95 wrote: post #67

Maybe Google should start designing it's own CPUs/SoCs as well, since Qualcomm doesn't really seem capable of keeping up with what Apple is doing. Snapdragon 835 came out 6 months after the A10, and scored about 2/3 as well at single core, and less than 10% on Geekbench 4. A11 scored twice what the 835 did on single core, and over 50% more on multi core, and the 835 is going to be the best chip available in the U.S.…

I don’t think google has enough volume to make that worthwhile. Wouldn’t you need to sell tens of millions of chips for that to pay off?

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#76

Post by ksk »

ggus wrote: post #59
bitL wrote: post #53

I wish my Nikon pro camera had a similar chip inside. Now we have two worlds - awesome pro cameras with incapable post-processing chips (I mean beyond RAW and initial processing) and horrible mobile cameras with outstanding post-processing chips.

Also the double lens, one for wide angle, one for tele, snapping at the same time and combining the images into one. It will be a looooong time until we see that on a pro camera with interchangeable lenses, if ever.

We already have zoom lenses that can do wide angle and take portrait shots. Having multiple full frame sensors with multiple lenses doesn't make much sense to me TBH. What is the problem you're trying to solve here?

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#77

Post by ksk »

bitL wrote: post #53

I wish my Nikon pro camera had a similar chip inside. Now we have two worlds - awesome pro cameras with incapable post-processing chips (I mean beyond RAW and initial processing) and horrible mobile cameras with outstanding post-processing chips.

Sony tried to do it with their alpha series of cameras. You could install apps from sony, and do post-processing. The cameras were under-powered for this sort of stuff, and the experience of installing those apps isn't very seamless.

https://www.playmemoriescameraapps.com/portal/

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#78

Post by sandGorgon »

joshuamorton wrote: post #71
sandGorgon wrote: post #66

Earlier quoted context omitted.

That bet is the problem. Tensorflow on mobile already targets GPU and is going to be even more so with XLA. This debate is going to be hearsay unless we have an apples to apples comparison of the base tensorflow code running on the halide ir targeted to the tpu vs a vanilla ARM GPU... Even using opencv. I find it telling that they compared cpu vs tpu... Not GPU vs tpu.

I'm really confused why you keep bringing up opencv. What does opencv have to do with the (presumably) TF ML model running on the IPU that you want to benchmark against the TF ML model running on a GPU?

Because halide is positioned as a high performance improvement over opencv. While I believe it is just an architectural decision to enable a non-portable ML model.

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#79

Post by [deleted] »

windexh8er wrote: post #44
jacobolus wrote: post #26

Earlier quoted context omitted.

Their results are quite bad compared to a passably competent Photoshop user willing to spend 2 minutes per picture. But if you need the computer to do all the color adjustment for you, so you can post your snapshot on facebook or print it at the local drug store with no manual intervention, this might be a good enough result.

I think you are missing the point with improvements of this nature. Take for example: you have kids. You're at an event with said kids. While I still own a mirror-less micro 4/3rds, I often time don't have it with me. It's easy to snap hundreds of photos in random life events with a good smart phone camera. I personally have almost 2TB of family photo and video and I've got a long way to go. Can you imagine me spendi…

[deleted]

Re: Pixel Visual Core: Google’s first custom-designed co-processor

#80

Post by simonh »

jrs95 wrote: post #67

Maybe Google should start designing it's own CPUs/SoCs as well, since Qualcomm doesn't really seem capable of keeping up with what Apple is doing. Snapdragon 835 came out 6 months after the A10, and scored about 2/3 as well at single core, and less than 10% on Geekbench 4. A11 scored twice what the 835 did on single core, and over 50% more on multi core, and the 835 is going to be the best chip available in the U.S.…

The problem is there is no magic wand the Android SOC manufacturers can wave to match Apple on chip performance. It's a multi-front war.

Firstly yes Apple is well ahead in CPU core design and has been since 2013 when they brought out the first 64-bit ARM chip. And yes I know 64 bit by itself doesn't account for the performance increase, but the 64-bit ARM core architecture is much more streamlined and efficient than 32-bit which had accumulated all sorts of cruft over the years. The A7 wasn't just 64-bit, it was step change up in performance creating a gap that the other ARM vendors have never caught up with.

That's not the whole story though, core design alone isn't the only reason Apple chips are faster, another is they have dramatically more cache memory on chip that other designs. The A10 had a total of 7MB of L2 and L3 cache, more than double the maximum configuration for the 835. Apple SOCs are massive, which makes them expensive.

Finally, they can build in customised capabilities in hardware to support specific high level features, such as the secure enclave and the neural engine in A11 Bionic to support image post-processing effects and face recognition. This is clearly what Google is trying to do, but in an add-on chip because they're not (yet?) up to designing their own SOC.

So it's not just the the Apple SOCs are faster, the reasons why they are faster are on several different axes. Some SOC vendors apparently say their profit margin lies in shaving off just one or two square millimetres of die size. Market forces like that would never produce a chip like the A11. So really this approach by Google of designing their own custom co-processor, and maybe eventually their own SOCs, could be the only way to close this gap.

Post reply on HN