测过诸多老机型后,我们发现了高通成功的奥秘

2022-10-8 10:55| 发布者: uklw29lwgwtgeh| 查看: 2051| 评论: 0

这里是默认签名
如果最近这段时间有持续关注我们三易生活,你可能知道我们着实带领大家“考古”了不少曾经在业内赫赫有名、甚至是引领一时风骚,但如今却早已不见踪影的“古董”手机SoC、AP方案,以及他们背后的相关厂商。



老实说,我们之所以要去收集这些老机型,并对它们所搭载的移动平台重新进行测试,一方面是出于想要挖掘那些已经被大家遗忘的、历史上曾经闪光过的设计思路。但从另一方面来说,也是因为我们确实想要弄懂,为什么这些曾经有过奇思妙想、曾经能够引领行业风潮的芯片厂商,如今却都一个个都黯然退场了?



不得不说,在测试了足够多的老机型、老移动平台、老应用处理器后,我们确实有了越来越明确的答案。并且更加有趣的是,这些答案不仅能够回答这一众厂商黯然退场的原因,同时也解答了为何在如今的智能手机SoC领域,高通最终能够脱颖而出的理由。


首先:产品生态的差异,促使了开发者与厂商“站队”



众所周知,现在许多消费电子厂商都喜欢讲“生态”这个概念,并且大家也都明白,只有完整的产品生态才能更好地留住消费者。


但在智能手机行业上游的芯片领域,过去绝大多数的知名品牌所推出的移动平台也好、应用处理器也罢,生态建设都可以说是一团糟。



比如说,我们日前提及的Intel PXA系列ARM架构移动处理器,当初刚发布时并未集成GPU,还需要依靠第三方额外为其适配独立外挂的GPU芯片。但外挂GPU的驱动Intel方面自己又不去适配,结果就导致一些产品虽然用了(当时来说很)强劲的GPU,结果GPU却只能用来做视频解码、压根就无法运行游戏,活脱脱成了半个“摆设”。



又比如说,不久前我们测过的三星Galaxy S2 Plus搭载的博通双核SoC,以及Marvell的末代移动平台PXA1928,就都出现了“理论图形性能不弱,但实际上连3D测试都跑不了”的现象。为什么会这样?往浅了说,这是相关厂商只管造芯片、不管软件适配所造成的必然结果。往深了讲,这其实就是这些厂商压根就没有考虑过软件开发者的感受,根本就不在乎产品的软件生态。而他们的下场,自然也就是被主流软件、游戏所遗忘,并最终被消费者弃之敝履。



纵观业界,如今的主流芯片厂商大抵都不会如此轻视生态的建设了。但有的时候,能不能真正给开发者、给手机厂商以方便,确实并不是一件容易的事情。



搭载骁龙845平台的LG Velvet LTE,前不久刚得到了Android 13更新



接下来,我们就来看看高通是怎样在生态建设上发力的。首先在最基础的驱动、功能适配方面,高通可能是整个Android阵营中,唯一有能力为旗下所有产品适配全部功能模组驱动的厂商。毕竟他们的GPU、NPU、DSP、ISP这些模组,现在都是完全自研的架构,不需要采购第三方IP。


以结果而言,这不仅使得高通旗下的SoC驱动更新更快、更频繁,而且也使得采用了这些方案的机型可以得到更长时间的系统维护周期。纵观市面上各大品牌的机型就会发现,往往只有那些采用了骁龙移动平台的型号,才会是每次系统更新最优先的机型。而其背后的原因,就在这里。



其次,高通不只是能够实现硬件与驱动的闭环自研,同时他们也很注重与业界其他厂商的联合调校。比如在影像方面,高通和徕卡、索尼都有进行深度技术合作,这就使得理论上所有的手机厂商,只要选用了骁龙移动平台,就会在使用索尼最新CMOS方案时得到更深度的技术支持,或是能够在相机里集成来自Leitz的独家算法。很显然,站在手机厂商的角度上来说,这实际上也就意味着潜在的巨大成本和用户体验优势。所以该怎么选,大家自然心中有数。


其次:可持续的技术路线,让所有产品都能受益



除了重视生态建设、积极与合作伙伴一同推进功能适配,将硬件设计“落到实处”外,高通还有一个不同于其他厂商的优势,那就是他们拥有完整、可持续的技术路线。


这是什么概念呢?我们回过头来看看此前测试过的那些老机型就会发现,技术路线不连贯、功能研发“想一出是一出”,在过去的SoC领域其实非常常见。



比如说在GPU方案上,有的品牌上一代产品集成的是PowerVR的GPU,下一代就换成了ARM的公版Mali方案,再往后一代又变成了半自研的设计。不仅如此,每一代产品还总会整出一些看起来让人眼前一亮的“突破性技术”。


又比如说在ISP、NPU的设计上,有些品牌将高中低端产品大搞“区别对待”,只有高端平台才有独立NPU,中低端或入门级产品压根就不配备相关功能。或者只在旗舰产品上用最新的ISP,而非旗舰就通通是此前的老架构。


乍看之下这似乎挺“合理”,因为不同定位的产品成本差异很大。再加上前文中曾提及,目前Android阵营除了高通,其他厂商也没有能力做到全栈自研,所以受制于供应商、动不动改方案也是情理之中。


但如果将骁龙移动平台拿来比较,大家就会发现可持续的、连贯的技术路线有多么重要了。



骁龙游戏合作伙伴阵容中的一部分



许多朋友想必都知道,高通方面在骁龙845上首次提出了名为“Snapdragon Elite Gaming”的一系列底层游戏优化技术。它们大多数都是驱动、甚至硬件层面的功能,能够起到降低游戏延迟、防止游戏卡顿、改善游戏过程中的网络表现等作用。但是就在发布这一技术后不久,高通便通过驱动、系统的更新,将一部分“Snapdragon Elite Gaming”特性带到了当时很有人气、但已经上市了一段时间的骁龙660上。



又比如说,高通早在2015年(骁龙820)就率先加入了AI、神经网络计算技术,而到了骁龙845、骁龙855时代,其移动AI体系正式成型,且使用了不同于其他厂商的“异构计算”设计。即让CPU、GPU、DSP、ISP,甚至电源管理单元和基带单元等,都分别具备执行不同AI代码的能力,然后在实际使用中自动进行分配和协同工作。


这样的设计好处在于能够使用SoC的全部算力,因此性能与计算效率都很高,但缺点也很明显,那就是高通必须坚持在每一代产品的CPU、GPU、DSP、ISP、NPU,乃至更多功能单元上,都使用带有延续性的架构设计。因为只有这样,才能令分布式AI计算架构在每一代产品上都能生效,也才能让那些为骁龙移动平台优化的“AI应用”在每一代骁龙平台上都能正常运转。



那么,高通做到这一点了吗?很显然,他们不只是做到了,而且还成功实现了高端设计的逐级“下放”。事实上,哪怕是在如今定位相对较低、诸如骁龙680这样的4G移动平台上,依然也可以看到源自旗舰的Spectra ISP、Hexagon DSP、Adreno GPU。相比于其他厂商“朝令夕改”的架构设计,高通这种基于自研架构、全系可持续的技术路线,最终带给用户的优势自然也就不言而喻了。


最后:高通还能够听取消费者的意见



老实说,即便对于最强大的行业巨头来说,在某一款、甚至是某一代产品中出现纰漏,也绝不是不可能的事情。PC行业中典型的例子,就是当年的英特尔奔腾4系列,而手机行业的例子就比如德州仪器OMAP4470上没啥用的“异构四核”,以及三星Exynos5410上无法同时开启的“假八核”,都属于在设计上就走了弯路、犯了错误。


产品设计出了错,市场表现与用户口碑自然就会打折扣。但手机行业的一大“优势”,就在于技术、产品迭代非常快,所以只要厂商及时改正,想要挽回市场的信心其实也不是难事。



坚持“大双核设计”,使得德仪在四核时代迅速失去了性能优势与市场份额



例如三星方面在Exynos5410遭到大量批评后,很快就推出了能够“八核全开”的Exynos5420,稳住了阵脚;而德仪在OMAP4470被外界批评多核性能不足后,却没能及时反思,反而试图在下一代产品OMAP5430上继续用“大尺寸双核”去“对垒”同期的四核竞争对手,结果就是新品还没上市、自己就已经被市场所抛弃。


而在最近这几年,高通方面在听取消费者意见这一点上,同样也表现得非常积极。



比如说,第一代骁龙8能效比表现平平,而消费者普遍期待更强的能效比表现,于是下半年的骁龙8+很快就依靠新工艺制程以及大幅提升的性能与能效比实现突破,不仅在市场表现上完全压过竞争对手,也使得消费者对下一代的新平台充满了期待。



又比如说在PC计算平台产品线中,前两代骁龙8cx因为CPU架构太“靠近”手机SoC,过于注重低功耗属性,导致性能水准很难与同期的x86平台竞争。但高通很快在第三代骁龙8cx平台上大刀阔斧地进行了改动,四个X1超大核加上四个A78大核的设计使得第三代骁龙8cx的性能得以飞跃式提升,再加上大幅上涨了200%的AI性能,最终也让2022年的“骁龙本”有了许多的看点,也受到了更多主流OEM厂商的青睐。


其实类似这样,在听取了消费者意见后,对产品进行的大幅升级改动并非一件容易的事情。因为这意味着厂商往往不得不额外付出预料之外的成本,但从另一个角度来说,“肯不肯改”以及“改得效果好不好”,其实又特别能够体现出一个厂商是否真的拿消费者当回事、是否真的在认真做产品。


从这一点来说,高通能够这么些年做下来,并成为整个移动通信市场的领军厂商,背后所付出的努力,显然不是那些如今已然“作古”的竞争对手所能比拟的。
这里是默认签名
回复

使用道具 举报

上一篇:“善良”的你为什么过的不好?怎样才能算得上真正的好人?

下一篇:这次谁首发?高通旗舰芯片骁龙8Gen2曝光:架构有新变化

sitemap.txt | sitemap.xml | sitemap.html |Archiver|手机版|小黑屋|彩虹邦人脉系统 ( 皖ICP备2021012059号 )

GMT+8, 2024-11-23 07:01 , Processed in 0.269282 second(s), 62 queries .

快速回复 返回顶部 返回列表