PC上DPU是嵌入在显卡上,不管是独立显卡还是集成显卡都是如此。由于GPU能力越来越强,DPU目前基本是附赠的功能,但从历史来看,GPU才是后有的新鲜之物,最早的只有DPU,从最早的Framebuffer机制就能看出,DRM框架中最早版本中也是不存在GPU的代码。 DPU最简单的功能便是将Frambuffer数据输出到显示设备上去,而Framebuffer的来源也都是来自于CPU的软件绘制,而非GPU绘制。 上图没有给我们很大启发,因为这离我们现代的DPU设计差别太远。 1. DPU与GPU的耦合是历史产物,完全可以独立出来【DPU用于控制端,GPU用于内容端】 通过Linux的dri显示框架,也能看出KMS的相对独立性,对应于系统侧的composer,而drm则在于内容相关的应用侧。对于Android系统也是一样的,GPU对应于drm(不过高通与mali并没有遵循这个开源drm框架)是用来绘制的,属于应用端的进程;而DPU对应于KMS,运行于服务端,可以认为在SurfaceFlinger(composer)中,开机就会初始化,然后保持不变,两者的分离更加彻底。 PC上Linux与移动端Android的不同 PC上耦合还是非常强的,DPU与GPU共享显存,代码也放在一个文件里,Buffer管理(GEM/TTM)自然是互通的,linux中默认代码是合并一块的,这是历史遗留问题——Andriod则不同,天生就是分离的,而ION是Android分配buffer的标准。 Linux平台:我们拿高通adreno的Linux开源代码来看,系统将DPU与GPU合并在一个文件夹下: drivers/gpu/drm/msm,功能基本也大体是分开的,比如GPU相关的为:adreno、msm_gpu.c,msm_ringbuffer.c,比如DPU相关的为disp,edp,hdmi等。但仍然有一部分代码是耦合在一起的,比如msm_gem.c, mem_drv.c。GPU命令还是使用drm标准的或定制的命令。 对于GPU来说,UMD使用的是mesa(高通并没有官方linux的支持) Android平台:高通官方代码则在两个完全不同的仓库,不存在任何代码的共享,GPU放在drivers/gpu/msm,配置的是KGSL,DPU则是不开源的私有库(OEM厂商可以拿到)。这也说明两者逻辑上并不存在那么紧密的联系,也就是传个framebuffer。 对于GPU来说,UMD是libGLES_xx.so(包含GL和EGL),并没有GEM和DRM那套东西,完全闭源,OEM也拿不到源码。 GPU与DPU完全可以采用不同的厂商,但通常也是一家的,原因何在呢? Buffer共享更高效:虽然buffer共享是通过ion,但是为了节省DDR带宽,通常会将共享的buffer压缩,比如Arm的AFBC,高通的UBWC。 如果使用不同的厂家,其实也能做到这一点,比如对于ARM,如今mali gpu还是广泛被使用,但mali dpu已经少有人用了,那就附赠一个AFBC Decode模块,如下图。(高通并没有放开这个限制) DPU的基本功能应该有哪些呢? DPU的设计相比GPU来说还是简单的,在于其功能的固定性,不可编程,其基本功能大约有2个。
最早的linux代码还能看出痕迹,一开始2D加速功能都是使用CPU;后面2D加速开始使用GPU来实现。到Android系统后,则由GPU专门的2D模块来实现(甚至会配置为双GPU,其中一个GPU只做2D加速),然后专门的DPU出现代替了GPU的2D模块(后面GPU再没有专门的2D模块,因为2D本来就是3D的子集,虽然专门设计的2D模块效率会高一点,但也没有DPU效果高,所以逐渐淘汰)。
下面给出DPU的一个基本设计原型,这包含4个部分。 2. DPU的原型设计2.1【DPU的四大组成部分】这是2013年的DPU设计图,当年Android发布了升级最大的4.4(也许是最成功的一代)。从下图可以看出DPU的设计大体分为四部分: 1)Source Surface Pipes(Pipe也称overlay,后面不再区分): 支持4个overlay通道(V1-V4),支持RGBX,YUV等多个格式,缩放比例(1/4 - 4),且每一个layer都支持alpha通道,
2)Blender: 支持2个Blender,对应于2个Path(除了LCD外,对应于DP或HDMI投屏); 3)Destination surface post-processor:支持dither,gamma调整;目前的趋势是这部分越来越重要。 4)Display Interface:支持最多2路同时的输出设备(物理显示设备,虚拟显示设备不需要实际的输出设备);支持LVDS,DSI,CVBS,HDMI等显示设备; DPU更细节的图如下: 如果放在Android系统中,我们来看一个HDR视频的播放流程的话,则能更好的看出这4个部分。 2.2【KSM与DPU】其实这张图也和我们常见的DRM的KSM框架图非常契合,也就是说KSM与DPU功能几乎等同:
-----------------------------------------------------------------------------------------------------------------------------------------------
3. DPU的最新设计3.1【Source Suface Pipes or Overlays】1)Pipes(也有叫overlays)一般分为两种:(这也不能叫趋势,高通从一开始就有这两种)
2)支持输入的分辨率更大,比如支持4K的输入,这需要更高的DPU频率; 3)随着XR(AR、VR)设备的出现,目前单眼4k已经出现(DPU就要支持8K的输入),这样带宽压力太大,所以目前的做法通常并不是直接4K的输入,而是切分成2个2k(当然这样可用的layer就会减小一半),这就是Split功能;(这也不是新功能,因为很多年前4k视频就出现了)。 4)支持旋转,主要用于视频播放,其他场景基本用不上,GPU会预旋转。(mali dp 650支持这个就不好,主要带宽影响太大,从kernel开源代码看,dp650后,mali似乎便没有更新) 5)pipe越来愈多,比如8个,16个(基本也不会比这更多了)
6)支持压缩格式(UBWC或AFBC);减小内存带宽,特别是与GPU的交互带宽。
3.2【Blender】1)合成layer越来愈多,比如支持10个layer的合成(大部分layer其实不会互相叠加); 2)合成path越来愈多,比如支持4个(同时使用3个的场景已经非常罕见)
3)支持3D功能;(可以区分左右眼,因为3D功能是很多年前便普及的了,所以不是新技术) 4)Dim layer:Android上的常用场景,作为渐变色,只有灰度值的变化,其他不变;
5)Background color:对于单色图片,也有一些优化方案。
3.3【Destination surface post-processor】最开始后处理还只是dither、gamma校正、还有亮度、对比度、饱和度调整这些功能,在四个模块中并不重要,但却是近几年发展最快的一个模块了。现在旗舰手机很多用上了独立显示芯片PixelWorks(后面简称PW),宣传的功能便是:MEMC、HDR、阳光屏(CABL)、护眼模式、Demura、超分;这些功能高通都有,全放在自己的后处理中。 1) 超分与锐化 这里的超分指的是Destination Scaler,是对整个屏幕数据做的,与前面的Source pipe的针对layer的超分是不同的,虽然算法是一样的。 目前平台几乎都不再使用简单的双线性插值,而是自己的算法,但目前仍是基于单帧的技术,虽然MTK宣称已经支持AI超分,但效果并没有让大家觉得特别亮眼。 PC上的有英伟达的AI超分DLSS、AMD的传统超分FSR,在网上反映都还比较不错,但放在手机上要么功耗高,要么在手机上这种高PPI的应用场景,超分的优势就没那么大了。(在PC上表现良好的FSR超分算法在手机上效果真的是不好) 随着XR对于分辨率越来越高,所以这个需求还会继续发展,也是未来的一个发展方向。 2)支持HDR,SDR to HDR,都是基本操作。 3)亮度调整:区别于Android根据环境光调整,主要是基于内容的背光调整算法。可以区分为indoor和outdoor。Indoor光线不强,主要由CABL和FOSS,其中分别针对LCD和OLED屏幕;outdoor则使用ARM的阳光屏技术,当然高通在后面采用了自己的Local Tone Mapper策略(既可以用于indoor,也可以用于outdoor)替换了ARM的阳光屏技术,主要拉升图像暗处细节,也不能让高亮的地方出现过饱和。 4)MEMC:电视上的标配,目前手机上也都是放在视频上,是PW最开始引入手机上最重要的原因,通过插帧实现30帧都60帧视频的流畅。 5)demura:oled上的必备流程
3.4【Display Interface】东西很多,不再一一列举(后面专门讲下mipi),可见未来的发展还在于XR。 4. 总结DPU分为4部分,功能已经比较稳定:其中显示后处理是以后升级的重点(其中超分与锐化又是优化的重点),同样的功能,相比独立显示芯片PW或DDIC去做有更好的功耗; XR会极大左右DPU的发展:无论是分辨率带来的带宽压力,还是最新的注视点传输这样的技术,都需要DPU做出较大改变。 |
|
来自: mynotebook > 《待分类》