梅花落_个人页

GPU与GPGPU泛淡

GPU与GPGPU泛淡 GPU(Graphics Processing Unit)，也即显卡，是一种专门在个人电脑、工作站、游戏机和一些移动设备（如平板电脑、智能手机等）上作图像运算工作的微处理器。它已经是个人PC和移动设备上不可或缺的芯片，有界面有显示的地方，一般就离不开它。高清电视、智能手机、个人电脑。 GPU的产生是为了解决图形渲染效率的问题，但随着技术进步，GPU

从软件工程的角度写机器学习3——主要监督学习算法的工程性分析

图像算法的工程优化技术

图像算法的工程优化技术 当一个很酷的图像算法实现之后，我们希望集成到软件中去，这时将会遇到最大的拦路虎：性能。 可以想像一下，如果美图秀秀做一个美颜效果要转圈圈转个30秒，还会有多少人用呢。 学术界喜欢推出复杂度更低的算法，去解决性能问题，而在实际工程应用中，对代码的优化和硬件的良好运用效果来得更快更显著，这里就对不改动算法，纯工程方面做性能优化的技术作一个简介。

从软件工程的角度写机器学习2——流行的机器学习应用模式与算法

流行的机器学习应用模式与算法 本文将围绕

Renascence使用方法

Renascence使用方法 下层库的适配 类型 下层库所有向Renascence架构提供的函数，其输入输出都必须给一个对应的继承于IStatusType的类，用于读取、保存、映射、释放该类型。 /*Basic API*/ class IStatusType { public: IStatusType(const std::string name)

Renascence架构原理——最优化算法

最优化算法 背景 通过公式生成ADF之后，根据下层函数库的配置，在结构不变的情形下，ADF是可以通过一系列值在0-1之间的参数进行调节的。也即ADF可表示为固定维数n的实数集，因此需要解决的问题就是在给定的目标下，求一组使目标值最大的参数。 max(f(x0,x1,x2,x3,...,xn)),xi∈[0,1] max(f(x_0, x_1, x_2, x_3, .

Renascence架构原理——遗传规划算法

遗传规划算法 遗传规划算法 请先看一下遗传算法： http://blog.csdn.net/v_JULY_v/article/details/6132775 遗传规划/遗传编程(Genetic Programming)是遗传算法的一个分支，与遗传算法中每个个体是一段染色体编码不同，它的个体是一个计算机程序。 维基上说它在70年代就已经有人实践，不过正式提出应该还是

适用于OpenGL离屏渲染上下文的初始化代码

说明 最近做图像算法，需要用到shader对图像进行处理，用glut会有窗口，不适合写成UT测试用例，需要创建一个无窗口的OpenGL上下文。 代码 这部分代码其实是参考 Android的Skia 模块相关代码写的，适用于 Mac、EGL（Android）、X11（Ubuntu等Linux系统）平台。 h文件 class GLContext { publ

Android图形显示系统——一张图片的显示流程

Android设备上一张图片的显示过程 应用示例 假如我们现在有一张这样的风景照 想在Android设备（比如一个小米pad）上显示出来。首先想到的是写一个应用，用一个ImageView，把这张照片附到ImageView上显示，如下面的demo。 MainActivity.java package com.example.pictureshow; imp

双三次插值算法的OpenGL实现

双三次插值算法的OpenGL实现 说明 最近写一个图像缩放的接口，考虑到自己有现成的OpenGL图像处理引擎，还是直接写shader用GPU实现方便。为了效果好一些，采用了双三次插值算法。 算法相关公式可参考这篇文章： http://blog.csdn.net/lichengyu/article/details/8526629 代码 详细实现代码见： htt

图像转置的Neon优化代码

图像转置的Neon优化代码 原理 图像转置 图像转置和矩阵转置是一样的，其公式为： dst.getPixels(y, x) = src.getPixels(x, y) dst.w = src.h dst.h = src.w 效果如下： 原图： 结果图： 先做图像转置后，再实现90度/270度的旋转相对容易， 如图像旋转90度，就只需要再水平翻

Android图形显示系统——概述

序 Android的图形显示系统，虽然感觉自己基本了解了，有问题基本都能解决，但要写时，一是觉得千头万绪无从下笔，一是发现还有很多并没有真正搞懂。开工写这套体系，也顺便查漏补缺下。 Android图形显示系统的剖分 图形显示系统就像一个报社，它派出记者去采访，记者写成文稿后，将记者们交上来的文稿审核、排版、印刷，最终形成一期又一期报纸。 如上是Android图形

Renascence架构简介

Renascence架构 Renascence架构是 A-GP-B 式的桥梁架构，它要求下层库不直接对外提供接口，而是往GP库注册函数，上层库用GP公式间接调用下层库的代码。 GP库位于应用与lib库之间，作为应用调用lib库的桥梁而存在，它本身不依赖任何基础库。 上层调用 通过引入训练这一过程，应用跨平台的问题有了最好的解决方案，即在安装过程中，应用提供一个模板

Renascence架构介绍——目录

这一系列文章是为个人项目作一个介绍，有兴趣的朋友可以关注一下。 https://github.com/jxt1234/Renascence 先写个目录，以后按目录更新 1、自动编程体系设想 2、Renascence架构 3、使用方法——下层适配 4、使用方法——上层接口与GP公式 5、原理——遗传规划算法介绍 6、原理——最优化算法介绍

基于Renascence架构的SQL查询引擎设计

基于Renascence架构的sqlite查询优化 sqlite查询优化方案是一开始是在Hw时设计的，但当时只实现一些简单case，并未完成sql的普遍支持。后面考虑到这可以做为 Renascence 架构的一个实验场景，因此将其方案做了一番修改，代码也重写了一遍，现在做成一个能支持普通sql查询的demo。 sqlite架构 参考：http://wiki.dzsc.c

ETC1压缩纹理格式详解

本来以为，ETC1作为Android 设备的OpenGL标准，开源且最常用的的一种压缩纹理格式，总会有人去翻译一下khronos的文档，读一下代码，给大家作个普及的，不料就是搜不到。没办法，尽管英文不好，还是硬啃了下文档，把 ETC1压缩纹理的实现原理弄清楚了。 https://www.khronos.org/registry/gles/extensions/OES/OES_

Android图形显示系统——上层显示2：硬件加速实现

Android界面绘制的硬件加速实现 Android的界面绘制的硬件加速采取上下整合的一套流程实现 一、代码结构 （一）Java HardwareRenderer->ThreadedRenderer：组织硬件加速渲染的类，下发创建显示列表和回放的指令。 GLES20RecordngCanvas GLES20Canvas HardWareCanvas：与

Android图形显示系统——上层显示1：界面绘制大纲

Android显示之应用界面绘制 越到上层，跟业务关联越直接，代码就越繁杂，Android上层显示的代码正是如此。此外，java语言本身繁复的特点（比C语言多了满屏的try-catch，比C++少了析构处理的优雅简洁，和更高级的语言scala、python等就别比了），更加剧了这一现象。 直接去看代码，往往会看得一头雾水，知其然而不知其所以然。在这时候，就要把代码扔掉，仔

Android中读图片Exif信息的方法

Exif读取类 Android提供了读取写入Exif的API，但很可惜，这个API只能由指定文件名读取、写入Exif，效率低得可怜。 不得已，把Android系统代码里图库的一段摘了过来。 有Android源码的看源码中 packages/apps/Gallery2/ 部分， 没有或者图方便的直接看这里： https://github.com/jxt1234/Thir

YUV转RGB（NV21-ARGB）的Neon优化代码

说明 此代码仅限于 NV21 格式转 ARGB 格式。 NV21 格式中，Y 单独存储，UV分量交错存储。 使用如下公式： R = Y + 1.402*(V-128); G = Y - 0.34414*(U-128) - 0.71414*(V-128); B = Y + 1.772*(U-12

Android图形显示系统——下层显示4：图层合成下（硬件合成器）

硬件合成器-HwComposer 使用3D合成，需要大面积的像素混合计算和大量的内存传输（GPU读写GraphicBuffer所需），对GPU和DDR来说是一个巨大的负担。在GPU/DDR重度使用的场景（比如玩游戏），会造成发热、卡顿等。 为了提升性能，减少功耗，可以将合成这个过程交由另一个芯片完成，减轻GPU负担。进一步，直接让这个芯片连LCD，在LCD需要显示某一行时

Android图形显示系统——下层显示4：图层合成上（合成原理与3D合成）

Android显示之图层合成 要点 1.图层合成指综合各个窗口的绘制内容，送往LCD显示的过程。从原理上可分为在线合成与离线合成两种方式。 2.在Android的SurfaceFlinger代码流程中，图层合成方式分3D合成(OpenGL)和硬件合成两大类。 3.图形系统采用垂直同步Vsync机制，由LCD上报vsync，触发图层合成。 图层合成的原理

自动编程体系设想

自动编程体系设想 编程的演化 编程语言的发展 随着语言的发展，编写的代码将越来越精简，而且领域化（不同领域用不同的编程语言，以达到开发效率和程序性能的最优化）。 自动编程的需求 在各种设计框架、基础库日益完善的情况下，上层应用中的编程基本上就是找API，构建一个调用逻辑，然后反复的开发自测试。下层框架/函数库开发一般都基于开源代码不断优化，同样反复地自测试

Jpeg 库的解码OpenCL优化

libJpeg库解码OpenCL优化 这两周在闲暇时基于通用的libjpeg库重新做了一个opencl解码实现。重新熟悉下算法。 代码路径 https://github.com/jxt1234/platform_external_jpeg OpenCL文件夹目录下面的就是所有的修改。 用Xcode开发的，没兴趣去整Makefile了，代码独立，移植集成也很方便。

Android图形显示系统——下层显示3：窗口系统

Android之窗口系统 要点 1.Android窗口系统通过C-S架构和一套Buffer循环机制实现，在保证安全稳定的前提下基本上做到了极致性能（无大块内存拷贝，IPC通信内容最少）。 2.SurfaceFlinger创建Layer，将其中的BufferQueueProducer作为IGraphicBufferProducer传给应用侧的Surface，因而构成窗

Android图形显示系统——下层显示2：图形内存的申请与显示

图形内存的申请与显示 这一篇回答序言中的第一个问题： 如何申请可以用来送显的内存，如何将其送往LCD？ 要点 图形内存是进程共享内存，且根据其标志支持不同硬件设备的读与写。 buffer_handle_t 是 *private_handle_t，gralloc模块自定义private_handle_t类型，并实现图形内存的实际申请。 GraphicBuffer跨

Android图形显示系统——下层显示1：基础知识与相关文件

基础知识和相关文件 基础知识 Android下层显示相关的代码相对而言并不是很多，核心部分在三件厂商或SOC厂商提供/集成的驱动之中。尽管如此，这部分代码涉及到一系列基础类库，不了解的话也很难读懂。 这些基础知识这里只做简单介绍，详细了解看链接或可自行百度或Google binder/Service Android中用于进程间通信的基本方法，需要了解它是怎么使用

Skia深入分析10——Skia库的性能与优化潜力

Skia库性能与优化潜力 图形/渲染 算法/架构 作为图形渲染引擎，性能上是非常重要的，按通常Android手机60帧的刷新率，绘制一帧的总时间只有16ms，可谓是毫厘必争。提升性能到最后，就必然跟不同CPU的特性打交道，毕竟一个SIMD下去，好做的提升5、6倍，不那么好做的也达到2、3倍，收益极其可观。 SIMD，在intel上是SSE，在arm上是neon，在

Skia深入分析9——延迟渲染和显示列表

概念 Android的硬件加速，是先将绘制命令存储起来，然后回放，作为软件绘制的引擎Skia中同样有这样的机制。在Android 4.4的版本中又加入了延迟渲染的Canvas，它相当于默认使用显示列表的Canvas。 先得到显示列表，再进行渲染，便有机会基于绘制API的整体情况做优化调度。比如使用GPU加速，裁剪过度绘制等。从原理上看，很可能在这一层级做比较大的效率提升，

Skia深入分析8——Skia的GPU绘图

Skia的GPU绘图 一、Skia-GPU概述 在Android4.2到Android5.0的过程中，skia中开发较频繁的部分莫过于GPU加速部分和延迟渲染机制，尽管目前来看几乎没有用到，但后续很可能会在Frameworks层引入。 在Android上面，只可能使用OpenGL，因此作为使用OpenGL的绘图引擎，关注如下要点即可： 1、OpenGL上下文如何建

Skia深入分析7——区域解码

Skia深入分析7——区域解码 1、概述 -当图片很大时，解码速度缓慢，占用内存很高，并且，当图片超过一定尺寸时，无法做纹理上传和显示（这跟GPU能力有关，一般的GPU是8192*8192）。这时只好做下采样，但会牺牲图片显示的质量。 -对于图库等需要清晰浏览图片的应用，不可能设置一个下采样率去解决这一问题，因此，Google加入了区域解码这个功能，使我们可以从原始的图

Skia深入分析6——skia中图像编解码代码概述

1、API和自注册机制 Skia中编码解码图片都只需要一行代码： SkBitmap bitmap; SkImageDecoder::DecodeFile("test.xxx", &bitmap);//由文件名解码，自动推断图片类型 //或者由流解码 SkFILEStream stream("test.xxx"); SkImageDecoder::DecodeStream(s

Skia深入分析5——skia文字绘制的实现

文字绘制主要包括编码转换（主要是中文）、字形解析（点线或image）和实际渲染三个步骤。在这个过程中，字形解析和实际渲染均是耗时步骤。Skia对文字解析的结果做了一套缓存机制。在中文字较多，使用多种字体，绘制的样式（粗/斜体）有变化时，这个缓存会变得很大，因此Skia文字缓存做了内存上的限制。 1、SkPaint 文字绘制与SkPaint的属性相关很大，先回头看下SkPaint相关

Skia深入分析4——skia路径绘制的实现

Skia路径绘制代码分析 路径绘制尽管使用频率相对于图像绘制、文本绘制低，但却是非常重要的一个基本特性。所有不规则图形（椭圆、圆角矩形、三角形、简单的文字），最后都避不开路径绘制。 而且，若自己实现一个2D引擎，这块内容是很具有参考意义的，用OpenGL的话，图像采样等都很少关注了，对对坐标就好。但菱角、圆弧、曲线等如何绘制仍然是一个难题，这时就可以参考Skia中drawPath的实现

Skia深入分析3——skia图片绘制的实现(2)

此篇讲图像采样一、采样流程在上一节里的流程图有写到，图像绘制的实际渲染发生在某个blitter的blitRect函数中，我们先看一个具体的blitRect实现。 void SkARGB32_Shader_Blitter::blitRect(int x, int y, int width, int height) { SkASSERT(x >= 0 && y

Skia深入分析3——skia图片绘制的实现(1)

此篇讲Skia绘制图片的流程，在下一篇讲图像采样原理、混合和抖动技术1、API用法（1）drawBitmapvoid drawBitmap(const SkBitmap& bitmap, SkScalar left, SkScalar top, const SkPaint* paint = NULL);将bitmap画到x,y的位置（这本身是一个平移，需要和SkCanvas中的矩阵

Skia深入分析2——skia渲染架构

一、渲染层级从渲染流程上分，Skia可分为如下三个层级： 1、指令层：SkPicture、SkDeferredCanvas->SkCanvas 这一层决定需要执行哪些绘图操作，绘图操作的预变换矩阵，当前裁剪区域，绘图操作产生在哪些layer上，Layer的生成与合并。 2、解析层：SkBitmapDevice->SkDraw->SkScan、SkDraw1Glyph

Skia深入分析1——skia上下文

前言：         断断续续跟Android的skia库打了两年交道，如今交接掉了，便写写关于skia的一些知识，也算了结一段职业生涯。 找了找网上关于skia的文章，基本上都过时了，讲得也不怎么深入。虽然Skia只是一个2D引擎，但其深度优化的算法、完善的渲染体系和精炼的代码框架，还是很值得借鉴的。         PS：文章所依据的代码为目前最新的Android 5.0.2。