<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[IT先森]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/tkwxty</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; tkwxty]]></copyright><item><title><![CDATA[Android下HWC以及drm_hwcomposer普法(下)]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139332845</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139332845</guid><author>tkwxty</author><pubDate>Thu, 30 May 2024 19:42:24 +0800</pubDate><description><![CDATA[Android下HWC以及drm_hwcomposer普法(下)引言不容易啊，写到这里。经过前面的普法(上)，我相信童鞋们对HWC和drm_hwcomposer已经有了一定的认知了。谷歌出品，必须精品。我们前面的篇章见分析到啥来了，对了分析到了HwcDisplay::init，然后设置Backend后端来着！]]></description><category></category></item><item><title><![CDATA[Android下HWC以及drm_hwcomposer普法(上)]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139296682</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139296682</guid><author>tkwxty</author><pubDate>Wed, 29 May 2024 15:25:30 +0800</pubDate><description><![CDATA[当VSync信号到来时，SurfaceFlinger被唤醒，处理Layer的新建，销毁和更新，并且为相应Layer设置期望的合成方式。所有Layer更新后，SurfaceFlinger调用validateDisplay，让HWC决定每个Layer的合成方式。]]></description><category></category></item><item><title><![CDATA[Mesa软件框架以及重要数据结构分析]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139275348</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139275348</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 19:11:26 +0800</pubDate><description><![CDATA[MESA的核心数据结构很多很复杂，上图列举了一些核心数据结构主要强调了它们的层次关系，即上层使用下层的抽象结构（比如 函数指针调用），下层为上次做具体的实现（比如具体的函数实现），虽然是C代码但设计理念基本上与C++的继承类似(这个也是C语言实现大型代码框架的核心)。Mesa的实现比较复杂，其中还有许多的数据结构之间的关系逻辑还不是很清楚。这里的核心主要是Mesa软件EGL/GL层级的递进调用。1.1 Mesa下EGL/GL核心数据结构和层级关系。1.2 Mesa下核心文件和核心结构体。]]></description><category></category></item><item><title><![CDATA[Android环境下Mesa初始化流程重学习之eglCreateContext]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139273226</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139273226</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 17:33:44 +0800</pubDate><description><![CDATA[总得找点事情干不是!2.1  smapi->screen->context_create的实现。这块我们在前面分析时，已经提到过了。我们接着继续分析_mesa_initialize_context。这里的核心是_glapi_table，它在前面已经被初始化了！我们接着继续分析st_create_context_priv。Mesa初始化流程重学习之eglCreateContext。Mesa初始化流程重学习之eglCreateContext。2.2  st_create_context的实现。]]></description><category></category></item><item><title><![CDATA[Android环境下Mesa初始化流程重学习之eglInitialize]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139272714</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139272714</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 17:30:06 +0800</pubDate><description><![CDATA[那么这里的xxx_driver_descriptor是怎么实现的，刚开始我通过grep搜索发现只有定义，没有怎么实现。这里的__driDriverGetExtensions_xxx_gpu函数符号表是怎么拼凑成的了，如果我们通过grep在mesa搜索，怎么搜索也搜不到了。分析完了pipe_loader_drm_probe_fd流程，我们接着咔咔一顿接着继续分析，pipe_loader_create_screen它会构建pipe_screen的结构体类型！真可以说的上是你中有我，我中有你的典范啊。]]></description><category></category></item><item><title><![CDATA[Mesa GL Dispatch分发分析与理解]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139272231</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139272231</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 17:14:39 +0800</pubDate><description><![CDATA[gl_打头的函数是OpenGL API，首先这些函数都是函数指针，这些函数挂载的函数就是mesa里以_mesa_打头的对应函数。在正式分析相关分发流程之前，我们必须明确的一点就是现在的Mesa采用的是最新的gallium架构，下图的左侧调用栈是在gallium 架构之前采用的模式，右侧是gallium架构下的模式。通过我们前面的st_create_context_priv分析可知，获取到table表以后，然后通过id会找到对应的函数，即指向了_mesa_Flush。]]></description><category></category></item><item><title><![CDATA[Mesa Gallium框架入门初探]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139271809</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139271809</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 17:03:30 +0800</pubDate><description><![CDATA[它负责把上层库的state（blend modes、texture statte等）和draw command（glDrawArrays、glDrawPixels）等转换成MESA内部的pipe对象和操作。state tracker也可以直接通过p_winsys和Winsys通信,一般GPU厂商也要实现一个自己的winsys，可以参考纯软的 kms_dri_sw_winsys.c。: 把Gallium的state、shader和primitive概念转换成硬件能懂的语言。这个系列博客，确实写得蛮好的。]]></description><category></category></item><item><title><![CDATA[Android 13 VSYNC重学习]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139266712</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139266712</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 14:50:49 +0800</pubDate><description><![CDATA[在VSyncDispatchTimerQueueEntry的callback方法中，会调用类型为CallbackRepeater::callbackk，然后在该方法中接着调用mCallback(vsyncTime, wakeupTime, readyTime)方法，而这里的mCallback(指向DispSyncSource::onVsyncCallback，最后回调EventThread的onVSyncEvent方法。由于偏移量不同VSync-sf信号和VSync-app信号的回调时机也不同。]]></description><category></category></item><item><title><![CDATA[Android Graphics图形栈SurfaceFlinger之间各种Layer以及对应Buffer之间的关系]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139266568</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139266568</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 14:42:08 +0800</pubDate><description><![CDATA[Android Graphics图形栈SurfaceFlinger之间各种Layer以及对应Buffer之间的关系。Android Graphics图形栈SurfaceFlinger之间各种Layer以及对应Buffer之间的关系。]]></description><category></category></item><item><title><![CDATA[SurfaceFinger layer创建过程]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139266378</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139266378</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 14:39:04 +0800</pubDate><description><![CDATA[SurfaceFlinger::setTransactionState中比较复杂容易忽略将TransactionState state放入mTransactionQueue的过程，mTransactionQueue在后面创建hwc layer的时候会用到。mClient->createSurface会调用到android12\frameworks\native\services\surfaceflinger\Client.cpp 中Client::createSurface。app端创建Surface。]]></description><category></category></item><item><title><![CDATA[Android Surface对应的Buffer怎么传递给HWC]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139266120</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139266120</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 14:33:15 +0800</pubDate><description><![CDATA[因为要预研Android Video overlay，需要将SurfaceView对应的GraphicBuffer从drm_hwcomposer中剥离出来，这就需要们了解SurfaceView对应的GraphicBuffer的前世今生，以及它的数据流向以及在各个模块之间的对应关系。这里我们对该函数单独站看来分析下，ensureOutputLayer将创建Output layer，不是所有layer都会创建对应的hwc layer，创建出来的这些layer最后是要显示到屏幕上的。我先分析下，再告诉你！]]></description><category></category></item><item><title><![CDATA[Android Graphics模块中的各种State和重要类普法]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139265946</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139265946</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 14:28:39 +0800</pubDate><description><![CDATA[这个我的理解它主要是Layer的一个前端,主要用来处理Layer合成相关的,!表示一个"前端"Layer，跟Layer相对应，用于处理Layer在合成阶段的工作。机会是每年一个版本，前进的胶布不能停啊，继续干。Display: 表示所有输出层最终对应的显示设备，可以有硬件合成器支持的显示设备，也可以对应虚拟显示设备。这里的Layer.State主要存储了该Layer相关的数据，例如长宽，各种矩阵，阴影等。这里需要注意CompositionState对应的域空间，不要和Layer里面的搞混淆了！]]></description><category></category></item><item><title><![CDATA[BLASTBufferQueue端的GraphicBuffer怎么和SurfaceFlinger端的BufferStateLayer关联上]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/139265823</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/139265823</guid><author>tkwxty</author><pubDate>Tue, 28 May 2024 14:23:44 +0800</pubDate><description><![CDATA[在跟进hwc_layer是如何产生的，并如何被填充上GraphicBuffer的，怎么也找不到被填充的GraphicBuffer的来源，最终找到了，它的来源是客户端的BLASTBufferQueue传递过来的，我们这里跟进下这个流程。一. BLASTBufferQueue是如何传递GraphicBuffer到SurfaceFlinger端的BufferStateLayer的。我们接着继续往下看，layer->setBuffer会调用子类的setBuffer，子类是BufferStateLayer。]]></description><category></category></item><item><title><![CDATA[OpenHarmony下musl编译工具链普法]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/136496333</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/136496333</guid><author>tkwxty</author><pubDate>Wed, 06 Mar 2024 09:32:45 +0800</pubDate><description><![CDATA[LLVM 成长之后已成为众多编译工具及低级工具技术的统称，使得这个名字变得更不贴切，所以开发者决定放弃这个缩写的涵义，现在 LLVM 已独立成为一个品牌，适用于 LLVM 下的所有项目，包括 LLVM 中介码、LLVM 除错工具、LLVM cpp 标准库等。对于一个比较大的第三方库，其头文件和库文件的数量是比较多的，如果我们一个个手动地写，那将是相当的麻烦的。事实上，pkg-config只是一个工具，所以不是你安装了一个第三方库，pkg-config就能知道第三方库的头文件和库文件的位置的。]]></description><category></category></item><item><title><![CDATA[Android minigbm框架普法]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/136400213</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/136400213</guid><author>tkwxty</author><pubDate>Fri, 01 Mar 2024 16:40:28 +0800</pubDate><description><![CDATA[因为前端就是gralloc hal的接口定义，都是一致的，然后后端backend抽象出来，然后根据实际的情况，调用具体的gpu用户层接口实现！这里我们可以看到这里抽象出来了几种典型的GPU的backend，然后再根据前面获取到的drm的驱动名称进行匹配，匹配到了则返回合适的backend，没有则返回NULL。这里我们以evdi为例子来进行相关的分析。minig的核心主要是提供gralloc的HAL实现，但是我看它也提供了私有的HIDL service实现，关于HIDL的实现这个暂时不在我们考虑的范围之内。]]></description><category></category></item><item><title><![CDATA[OpenHarmony下GN语法普法]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/136194226</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/136194226</guid><author>tkwxty</author><pubDate>Tue, 20 Feb 2024 16:58:06 +0800</pubDate><description><![CDATA[鉴于无法测试列表项的添加引入，可以这样使用：设置一个文件或标志的主列表，然后根据各种条件删除不适用于当前版本的文件或标志。构建应该做的大多数事情通常都可以在不这样做的情况下来完成，如果你觉得有必要，这可能表明你在元构建中做了太多的工作。一个值可以是一个域。当最终在命令中使用源路径时，它们会转换为对应于操作系统的（OS-appropriate）路径，这些路径是绝对的或相对于构建目录（运行命令的位置）的路径。这意味着，例如，当您定义target目标时，您在块内执行的任何操作都不会“泄漏”到文件的其余部分。]]></description><category></category></item><item><title><![CDATA[OpenHarmony下gn相关使用]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/136194006</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/136194006</guid><author>tkwxty</author><pubDate>Tue, 20 Feb 2024 16:52:18 +0800</pubDate><description><![CDATA[为了提高OpenHarmony下移植vivante gpu的成功率，先得把准备工作做足了，这样后续就好搞了。所以本文档的核心工作介绍GN构建工具在OpenHarmony中的常见使用方法，指导三方库由cmake或者其它的脚本构建到GN构建的转换！好了今天的博客OpenHarmony下gn相关使用就到这里了。当使用GN进行相关的构建时，需要了解如何指定动态库、静态库和可执行文件的构建规则。在GN中，可以使用executable模板来指定可执行文件的构建规则。3.4 GN在OpenHarmony上的扩展。]]></description><category></category></item><item><title><![CDATA[关于Android下gralloc，hwcompoer以及surface模块的重新认识]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/136176495</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/136176495</guid><author>tkwxty</author><pubDate>Mon, 19 Feb 2024 19:06:57 +0800</pubDate><description><![CDATA[native_handle/native_handle_t只是定义了一个描述buffer的结构体原型,这个原型是和平台无关的,方便buffer在各个进程之间传递,注意成员data是一个大小为0的数组,这意味着data指向紧挨着numInts后面的一个地址.我们可以把native_handle_t看成是一个纯虚的基类.对于native_handle和native_handle_t，以及private_handle_t这三个类型可以看作是同一个东西,而buffer_handle_t则是指向他们的指针.]]></description><category></category></item><item><title><![CDATA[Android下SF合成流程重学习之GPU合成]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/136154204</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/136154204</guid><author>tkwxty</author><pubDate>Sun, 18 Feb 2024 16:30:12 +0800</pubDate><description><![CDATA[通过上述的代码我们可以看到在启动之初就搭建好了EGL环境，并将当前线程与context绑定，为后面使用gl命令做好准备，然后创建了ImageManager 线程，这个线程是管理输入Buffer的EGLImage，然后创建了GLFrameBuffer，用来操作输出的buffer。当需要GPU合成时，会通过生产者RenderSurface::dequeueBuffer请求一块图形缓存，然后GPU就合成/绘图，把数据保存到这块图形缓存中，通过RenderSurface::queueBuffer提交这块缓存。]]></description><category></category></item><item><title><![CDATA[Android下SF合成流程重学习之Refresh流程]]></title><link>https://blog.youkuaiyun.com/tkwxty/article/details/136153549</link><guid>https://blog.youkuaiyun.com/tkwxty/article/details/136153549</guid><author>tkwxty</author><pubDate>Sun, 18 Feb 2024 16:14:56 +0800</pubDate><description><![CDATA[至此，SurfaceFlinger刷新的主体函数分析完了，可以看出来，如果是走device合成，SurfaceFlinger是直接把layer信息提交给hwc，由hwc去合成.prepareFrame 的作用是根据hwc的能力选择合成方式，如果是device合成则直接走hwc present上屏，如果是GPU合成后面则走hwc validate，然后根据hwc过来的变化改变layer的合成方式。composeSurface的主要核心逻辑是针对GPU合成，对于device合成，则直接return了。]]></description><category></category></item></channel></rss>