Google Pixel 6 to Be Powered by In-House “Whitechapel” Processor

Tsing

The FPS Review
Staff member
Joined
May 6, 2019
Messages
12,577
Points
113
google-pixel-4a-pair-black-1024x576.jpg
Image: Google



Google’s upcoming lineup of Pixel smartphones will not be powered by Qualcomm’s popular family of Snapdragon processors. This is according to an exclusive report shared by 9 to 5 Google, which revealed that this year’s model, the Pixel 6, will leverage an in-house processor code named “Whitechapel.” Specifications of this chip are unknown, but it is believed to have been co-developed with Samsung.



First rumored in early 2020, Whitechapel is an effort on Google’s part to create their own systems on a chip (SoCs) to be used in Pixel phones and Chromebooks alike, similar in to how Apple uses their own chips in the iPhone and Mac. Google was said to be co-developing Whitechapel with Samsung, whose Exynos chips rival Snapdragon processors in the Android space.



Source: 9 to 5 Google
Click to expand...

Continue reading...


 
Great this is JUST what we need... software developers are just going to LOVE this...

Ok so I can write code native for Intel CPU's.. OR... AMD CPU's, OR Apple CPU's, OR Google CPU's, or Snapdragon CPU's.. Or RISC CPU's (for DB vendors mostly)... and so on... but more...

This is like back in the day when you could buy a Mac with a Motorola chip, OR... a Power PC chip, and on Windows you could get Cyrix, Intel, or AMD with I think motorola having an entry or two there as well.

I think it's going to be interesting to see what happens but I think for people doing the ecosystem dance this is a move away from more hardware agnostic software, to more locked in ecosystems.

I really hope I'm wrong, I was kind of thinking about going macbook for my next work system but now... nope not with Apple Going with their own CPU's and me needing assurance my software will work for business.
 
Grimlakin said:
Great this is JUST what we need... software developers are just going to LOVE this...

Ok so I can write code native for Intel CPU's.. OR... AMD CPU's, OR Apple CPU's, OR Google CPU's, or Snapdragon CPU's.. Or RISC CPU's (for DB vendors mostly)... and so on... but more...

This is like back in the day when you could buy a Mac with a Motorola chip, OR... a Power PC chip, and on Windows you could get Cyrix, Intel, or AMD with I think motorola having an entry or two there as well.

I think it's going to be interesting to see what happens but I think for people doing the ecosystem dance this is a move away from more hardware agnostic software, to more locked in ecosystems.

I really hope I'm wrong, I was kind of thinking about going macbook for my next work system but now... nope not with Apple Going with their own CPU's and me needing assurance my software will work for business.
Click to expand...
I don't think you are wrong. I think the concept of hardware dictating software is going bye bye. Between off loading things to a network connection, and software being more and more centralized, i think they will be considering the hardware in your hand more of like an accelerator of sorts.
 
I'm sticking with the odd versions. I did 1, 3, and I'll do 5 maybe. 3 is still holding on strong.
 
Grimlakin said:
Great this is JUST what we need... software developers are just going to LOVE this...

Ok so I can write code native for Intel CPU's.. OR... AMD CPU's, OR Apple CPU's, OR Google CPU's, or Snapdragon CPU's.. Or RISC CPU's (for DB vendors mostly)... and so on... but more...

This is like back in the day when you could buy a Mac with a Motorola chip, OR... a Power PC chip, and on Windows you could get Cyrix, Intel, or AMD with I think motorola having an entry or two there as well.
Click to expand...

Except the M1, Power PC chip, the Motorola chip (68000), x86s, etc... are all different architectures.

But you simultaneously used an example of different manufacturers having software compatibility (Cyrix, Intel, AMD via x86) while also overlooking that different manufacturers had software compatibility... Qualcomm's Snapdragon, Apple's M1, Google's Whitechapel, Tegra, Mediatek, Allwinner, OMAP, etc... are all ARM based.

As in-house Apple's M1 CPU is, it's still entirely based on the ARM instruction set.

Compilers are getting pretty good at making universal binaries across groups of CPUs that adopt the same instruction sets. Source still will be available for Android.

Since Google releases source trees for every device (within reason) they've sold, kernel compatibility should essentially be the same as it is now, if not better. I'd actually expect software updates and support to improve once Google switches to their own SOC and other manufacturers potentially license it for their own devices. It's Qualcomm holding up updates due to proprietary blobs that don't get updated between kernel versions.

x86 is less encumbered by the hardware support situation as Qualcomm's SOCs are... and Chromebooks, regardless of who manufactures them, now get 8 years of updates from Google. All of Google's phones sold directly are bootloader unlockable. Chromebooks often use UBoot or CoreBoot, both open options.

I don't think there's much to worry about here. Ironically, the problem with fragmentation in Android is due to one single supplier's (Qualcomm) refusal to support hardware after 2 years.
 
Uvilla said:
I think the concept of hardware dictating software is going bye bye. Between off loading things to a network connection, and software being more and more centralized, i think they will be considering the hardware in your hand more of like an accelerator of sorts.
Click to expand...
While this is a big part of it, software generalization is another. APIs are a big part of this; you see Windows games running on Linux with similar performance, and even x86 performance on the M1 with an ARM ISA is pretty stellar. It seems to boil down to an understanding of what software does, at being able to at nearly any level have translations that can be applied to nearly any hardware.

And the 'accelerator' part is the real kicker. There've been plenty of segues but this is the road that computing has been going down all along. Think of it in terms of games where having a software render path was actually a viable option, and compare that to high-resolution video editing as a modern example.

Yeah, you could break out the Epyc cluster to chew through a video render... or you could just use a M1 Mac Mini, and do it in hardware. From the software's perspective, either works- and from the user's perspective, it's hardware availability, TCO, and time.

As the need for general compute for consumer workloads diminishes versus the performance potential, think the need for 5950-grade 16-core CPUs for office work, we should expect those silicon die resources to be put toward more effective uses, as Apple has done with their new SoC.
 
Looks like the chip will have tensor cores.

In other word, we can expect pixel phones to have more of that Assistant/AI/Machine Learning nonsense I hate and don't want any part of.

Things I would like in my next phone which I know I won't get:
- No Assistant
- No Algorithmic features
- No Machine Learning / AI
- No Cloud integration of any kind
- Analog audio out port
- Removable battery
- Expandable storage

I just want my smartphone to be a pocket sized PC with a touch screen interface. I don't want it to do anything my desktop PC didn't do in 2005.

Sigh.
 
Last edited:
Zarathustra said:
I just want my smartophone to be a pocket sized PC with a touch screen interface. I don't want it to do anything my desktop PC didn't do in 2005.
Click to expand...

Even a flip phone could do things your desktop couldn't do in 2005...

In any case, your best bet is to just get a Motorola device and throw a custom ROM on it.
 
You must log in or register to reply here.
Become a Patron!
Back
Top