在上一篇文章中,我们简单地了解到PC端常用的渲染架构Immediately Mode Rendering(IMR)。
在一些常见的复杂渲染算法中,IMR往往需要处理大量的数据,而这些数据通常是无法完全塞入GPU的Cache的,因此经常会需要与系统内存进行交互读写(如深度buffer,color buffer,stencil等等),这对带宽有着比较高的要求,同时还会产生较高的能耗。
移动端上采用SOC的架构,GPU与CPU是共享一块内存,带宽及功耗严重受限,并不适合IMR。
在上一篇文章中,我们简单地了解到PC端常用的渲染架构Immediately Mode Rendering(IMR)。
在一些常见的复杂渲染算法中,IMR往往需要处理大量的数据,而这些数据通常是无法完全塞入GPU的Cache的,因此经常会需要与系统内存进行交互读写(如深度buffer,color buffer,stencil等等),这对带宽有着比较高的要求,同时还会产生较高的能耗。
移动端上采用SOC的架构,GPU与CPU是共享一块内存,带宽及功耗严重受限,并不适合IMR。
在上一篇文章中,我们谈到可以从硬件的角度入手性能优化。然而由于移动端的硬件和PC端是不同的,某些在PC和主机平台上运行良好的编程技术可能无法很好地移植到移动设备上。因此我们要简单了解PC与移动端的硬件差异。
在上一篇文章中,我们简单地了解到了PC端与移动端硬件的差别。在这篇文章中,我们了解PC端常用的渲染架构Immediately Mode Rendering(IMR)。
首先要明确优化的目的,优化到底是在优化什么?
更少的:
更多的:
优化不能无的放矢,需要有总体的规划和方法论。一般而言,从物理维度切入,优化可以从这三个物理硬件入手:
进而可以更有针对性地进行性能优化:
在AWS Serverless搭建Tensorflow/TFlite推理服务一文中,我们成功创建了一个基于tensorflow的推理服务。为了能把服务真正地用起来,我们还需提供对外访问的http api接口,以及访问数据库的能力。这就轮到API Gateway以及DynamoDB出场了。
SAM(AWS 无服务器应用程序模型)是一个用于构建Serverless应用的开源框架。SAM CLI 是SAM的命令行工具。关于它们更详细的介绍及安装方式在实战1-利用sam-cli在aws-lambda上部署tensorflow一文中已经提到过了,这里不过多介绍。
无服务器架构(Serverless architecture)有一些众所周知的优点:
人力成本:使用无服务器架构可以节省服务器硬件和维护成本。开发人员毋需担心服务器管理和扩展问题。
硬件成本:无服务器架构允许应用程序在不使用时自动停止运行,这可以帮助减少资源浪费。若请求时间是离散的,它比24小时不停运行的服务要便宜得多。
自动扩容:无服务器架构允许应用程序随着流量的增加而扩展。
先看最终效果:
产品希望给首页的水面背景添加特效,使水面更加生动。
背景图类似下面这张:
一般来说,前端提到特效可能会想到使用视频、序列帧动画,Lottie等方案。
然而针对水面特效,以上方案会引入额外的资源加载,这对首页并不友好。并且由于资源大小限制,最终的效果不一定能很好。
在谈及高斯模糊之前,先了解图像处理中的一个基础操作——卷积。《Unity Shader入门精要》一书中对卷积操作有如下描述:
在图像处理中,卷积操作指的就是使用一个卷积核(kernel)对一张图像中的每个像素进行一系列操作。卷积核通常是一个四方形网格结构。(例如3X3的方形区域),该区域内每个方格都有一个权重值。当对图像中的某个像素进行卷积时,我们会把卷积核的中心放置于该图像上,依次计算核中每个元素和其覆盖的图像像素值的乘积并求和,得到的结果就是该位置的新像素值[1]。