
Pixel 2 is hiding a custom Google SoC for image processing - kartD
https://arstechnica.com/gadgets/2017/10/the-pixel-2-contains-a-custom-google-soc-the-pixel-visual-core/
======
fenwick67
Can somebody explain to me why they wouldn't just do this on the GPU? Isn't
the GPU already designed to perform "hardware-accelerated image processing"?

~~~
mtgx
For the same reason Google's TPU was an order of magnitude more efficient than
Nvidia's previous "pure" GPUs, or why video codec accelerators are also faster
and more efficient than GPUs for video decoding. The GPU is still pretty
"general purpose" compared to a chip that only does image processing and not
much else.

I hope Google will eventually reveal if the IPU shares any DNA with the TPU at
all.

~~~
sacheendra
These developments are quite funny. At one point GPUs were just fixed function
hardware. As more flexibility was needed for novel applications,
programmability was added.

Now we are going to back to fixed function units as the calculus has changed
in favour of power savings and against flexibility.

I'm interesting in seeing what advance in tech will change it again in favour
of flexibility.

~~~
photojosh
> the calculus has changed in favour of power savings and against flexibility

This has _always_ been a trade-off. For instance even with desktops, once
video handling became common we first had video decode/encode being handled by
GPU acceleration. But now most CPUs include dedicated h264 (and more recently
hevc) decode/encode support, eg [0].

Although it's much lower computation, hardware acceleration is also offered
for audio, and I'd take a guess the reason the Apple APIs for checking which
hardware supports hardware-based audio encode/decode [1] has been deprecated
is now because all supported devices provide all possible capabilities.

[0]:
[https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video](https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video)
[1]:
[https://developer.apple.com/documentation/audiotoolbox/16204...](https://developer.apple.com/documentation/audiotoolbox/1620452-hardware_codec_capabilities?language=objc)

~~~
TD-Linux
In the case with audio, it might be the opposite - even with a modern audio
codec like Opus, an Apple CPU can decode an entire song into RAM in a fraction
of a second. At that point, the CPU has to wake up anyway to download another
song from Spotify or read one from disk.

------
blakesterz
I was kinda feeling dumb reading this... SoC is "System On A Chip"... "A
system on a chip or system on chip (SoC or SOC) is an integrated circuit (also
known as an "IC" or "chip") that integrates all components of a computer or
other electronic systems. It may contain digital, analog, mixed-signal, and
often radio-frequency functions—all on a single substrate."

~~~
sn9
Thanks for that. When I see the string "Google SoC", I interpret that to
expand to "Google Summer of Code" so I was rather confused.

------
bri3d
Its own CPU, and a PCIe endpoint? Sounds like a good persistent exploit
vector. I wonder what tasks it will be used to accelerate.

~~~
bdonlan
It's only useful as a persistent exploit vector if it has persistence. If I
was designing this, it'd be simpler to have it boot off an image downloaded
from the main SoC rather than giving it its own flash.

~~~
bri3d
Good point - if it's just got firmware uploaded from the SoC, it's more of an
escalation / memory protection bypass vector versus a persistence vector. I
also wonder what gets sent across to it - for example, if a malicious video
from the web could land on the coprocessor.

Mostly it's just fun seeing more and more co-processing devices arrive in
phones as they get broken :)

------
Symmetry
When people started talking about Dark Silicon they didn't mean silicon that
was never turned on.

[https://en.wikipedia.org/wiki/Dark_silicon](https://en.wikipedia.org/wiki/Dark_silicon)

------
sathomasga
So maybe Google wants to build a device that needs image processing, but the
(initial) volume can't justify a full-on custom ASIC. (And for some other
reason -- power, space, ... -- this hypothetical device can't use an FPGA.)

Maybe find a device that does have a custom ASIC (e.g. Pixel 2) and add the
image processing functionality to that ASIC. Then perhaps use same custom ASIC
for both devices. As long as the extra functionality doesn't increase the cost
of the original ASIC, problem solved.

------
fulafel
Its own DDR4 RAM? Anyone know the bandwidth or capacity?

------
fulafel
The submission URL should be changed to:
[https://blog.google/products/pixel/pixel-visual-core-
image-p...](https://blog.google/products/pixel/pixel-visual-core-image-
processing-and-machine-learning-pixel-2)

------
samfisher83
>If Google ever set out to compete with Qualcomm's Snapdragon line, an IPU is
something it could build directly into its own designs. For now, though, it
has this self-contained solution.

If Google wanted to do this they would probably have to buy out QCOM and their
patents.

~~~
Kelbit
Or at the very least pay a boatload of money in licensing fees. Qualcomm owns
a huge chunk of IP in the mobile network space - they were responsible for the
initial push behind CDMA back in the early 90s.

~~~
pcl
I wonder when the key patents expire... as old as it makes me feel to write
this, the early 90s were over 20 years ago now.

~~~
nikanj
Even the late-ish 90s were 20 years ago. Oh god

