皮皮网

1.着色器编译是源码什么
2.Flutter 新一代图形渲染器 Impeller
3.OpenGL 着色器详解
4.KyttenShader: 现代的跨平台 Shader 系统
5.OpenGL自学笔记(四)(着色器)
6.OpenGL - 教程 -调试图形学

着色器编译是什么

       着色器编译是将着色器源代码转换为机器码的过程，以便图形处理器能够理解和执行。源码着色器是源码一种专为图形渲染设计的程序代码，通常用类C语言编写，源码如GLSL或HLSL。源码

       在详细解释之前，源码河流图 源码需要了解着色器在3D图形渲染中的源码作用。着色器负责计算场景中的源码光线、颜色和阴影等视觉效果，源码从而生成逼真的源码图像。它们通常在GPU上运行，源码因为GPU擅长处理并行计算任务，源码这对于图形渲染至关重要。源码

       着色器编译的源码过程涉及几个关键步骤。首先，源码开发者会编写着色器源代码，定义如何计算颜色、光照和其他视觉效果。接着，这些源代码需要经过编译，转换成GPU能够执行的机器码。由于不同的GPU架构可能存在差异，因此着色器编译通常需要针对特定的硬件进行优化。

       在编译过程中，编译器会检查源代码的语法和语义，确保其正确性，并将其转换为一系列指令，这些指令将直接由GPU执行。编译后的着色器被加载到GPU内存中，并在渲染过程中被调用。

       举个例子，在OpenGL环境中，着色器编译通常涉及创建着色器对象、将源代码编译为对象、链接多个着色器对象到一个着色器程序中，并最终使用这个程序来处理图形渲染任务。如果编译过程中发现错误，开发者需要调试并修正源代码，然后重新进行编译。

       总的来说，着色器编译是3D图形渲染中不可或缺的一环，它确保了着色器代码能够在不同的GPU上高效运行，从而呈现出精美的视觉效果。通过优化编译过程，开发者可以进一步提升游戏的性能和画质。

Flutter 新一代图形渲染器 Impeller

       Flutter在年的Roadmap中提出需重新考虑着色器使用方式，计划重写图像渲染后端。此计划的初步成果是名为Impeller的渲染后端，本文将探讨Impeller解决的问题、目标、架构和渲染细节。

       背景部分， Flutter过去一年解决了不少Jank问题，但着色器编译导致的Jank问题一直没有解决。着色器编译Jank问题源于Flutter底层使用skia做2D图形渲染库，内部定义了SkSL（Skia shading language）。在光栅化阶段，skia生成SkSL着色器，再将其转换为特定后端（GLSL、etcd通信源码GLSL ES 或 Metal SL）着色器，并在设备上编译，此过程可能耗时数百毫秒，导致数十帧丢失。通过在Flutter 1.版本中为GL后端实现SkSL预热机制，离线收集并保存应用程序中使用的SkSL着色器，进而提升性能。

       Impeller架构部分，Impeller是专为Flutter设计的渲染器，目前处于早期原型阶段，仅支持iOS和Mac系统，依赖flutter fml和display list，并实现了display list dispatcher接口，便于替换skia。其核心目标是解决着色器编译Jank问题。

       Impeller着色器离线编译部分，Impeller compiler模块是关键。在编译阶段，将compiler相关源码编译为host工具impellerc binary，利用impellerc compiler将所有着色器源码（包括顶点和片段着色器）编译为SPIR-V中间语言，再转换为特定后端的高级着色器语言（如Metal SL），并编译为shader library，同时生成C++ shader binding用于快速创建pipeline state objects。这样所有着色器在离线时被编译，运行时不需执行任何编译操作，提升首帧渲染性能。

       Impeller渲染流程部分，通过继承IOSContext、IOSSurface和flow Surface实现IOSContextMetalImpeller、IOSSurfaceMetalImpeller和GPUSurfaceMetalImpeller结构，对接flutter flow子系统。光栅化阶段，通过DisplayListCanvasRecorder合成Layer Tree，将所有layer中的绘图命令转换为DLOps，并存储到DisplayList结构。随后，使用DisplayListDispatcher执行所有Ops，将信息转换为EntityPass结构。接着，使用RenderPass从Root EntityPass开始遍历，将每个Entity转换为Command结构，生成GPU Pipeline，设置顶点和片段着色器的数据，将顶点数据和颜色或纹理数据转换为GPU buffer。最后，开始渲染指令编码阶段，根据MTLCommandBuffer生成MTLRenderCommandEncoder，遍历所有Commands，设置PipelineState、Vertext Buffer和Fragment Buffer，提交command buffer。

       总结部分，Impeller通过离线编译着色器、优化渲染流程等手段解决着色器编译Jank问题，显著提升渲染性能。Flutter重写图像渲染后端的决心可见一斑，期待Impeller能进一步提升Flutter的渲染性能。

OpenGL 着色器详解

       GLSL语言

       GLSL（OpenGL Shading Language）专用于编写着色器，挂机游戏源码unity通过定义main函数的程序片段，指导渲染引擎渲染内容。

       GLSL语法类似C语言，增加特定关键字修饰变量。基本结构如下：声明GLSL版本、模式、变量，主函数main处理输入输出。

       输入变量in

       GLSL允许有限输入变量，硬件决定数量，可通过GL_MAX_VERTEX_ATTRIBS查询上限。

       输出变量out

       片段着色器直接输出色值，无需与后续阶段关联。可通过一致数据类型和名称建立顶点着色器到片段着色器间联系。

       全局变量

       全局变量作用于整个着色器程序，可在多个着色器间共享，通过GL编码获取。

       示例：片段着色器中使用全局变量。

       顶点着色器与片段着色器

       顶点着色器声明位置与颜色变量，片段着色器声明一致输入变量接收颜色，实现数据传递。

       数据类型

       向量类型定义、重组用于复杂数据结构。

       glVertexAttribPointer

       设置顶点变量属性，定义步长、偏移与位置，用于配置顶点数据。

       顶点数据、着色器配置

       顶点着色器声明输入变量，片段着色器接收传递颜色，完成数据流。

       着色器程序

       着色器程序作为最小绘制单元，由两个着色器决定结果。面向对象封装着色器程序。

       加载着色器代码梳理

       流程包括：创建着色器对象、附加源码编译、创建程序、绑定与链接。

       着色器程序类封装

KyttenShader: 现代的跨平台 Shader 系统

       KyttenShader 是 Kytten Engine 中的现代跨平台 Shader 系统，正在开发中。此系统通过 Shader 反射机制收集 Shader 代码中定义的信息，如输入、输出、布局、缓冲区等，这些信息能应用于材质系统中。

       Slang 是 KyttenShader 使用的现代 Shader 语言，扩展了 HLSL 语法，提供更人性化的特性，兼容 HLSL，并支持参数块、接口、泛型、模块系统、Compute Shader、Rasterization Shader 和 Ray-Tracing Shader 等，能编译为 DXBC、DXIL、分位数matlab源码SPIR-V、HLSL、GLSL（支持有限的 OpenGL）等主流代码。

       为了实现跨平台兼容性，SPIR-V Cross 被引入，它能将 SPIR-V 格式的二进制文件编译为 GLSL、HLSL、MSL，支持反射，使得 Shader 代码能转换为 OpenGL、OpenGL ES、Vulkan、DirectX 以及 Metal 等平台的版本。

       HJSON 作为 JSON 的扩展，支持注释、行尾省略、省略双引号、多行字符串块等特性，更易读，用于 KyttenShader 的文件格式。

       在 KyttenShader 中，通过 HJSON 格式描述 Shader 的各个部分，如 Stage、RenderSetup、Tags、Pass 和 Shader。Stage 包含 Slang 源码，RenderSetup 定义渲染状态设置，Tags 配置与渲染引擎相关的选项，Pass 描述渲染过程，Shader 整合所有 Pass。

       编译流程根据目标平台生成最终代码，对于 DirectX /、Vulkan 和 MetalSL 直接生成可使用的代码，OpenGL 则通过 SPIR-V Cross 生成 GLSL 代码。KyttenEngine 支持模块化复用，内置 Slang 模块可被手动导入，Stage 和 Pass 可被其他 Shader 引用。

       KyttenMaterial 引用 KyttenShader，收集反射信息，提供 UI 控件，方便开发者设置参数，支持序列化为预设。

       对比 Unity ShaderLab，KyttenShader 采用现代实现方案，利用 Slang 和 SPIR-V Cross 的强大生态，编写 Shader 更加方便、高效、高质量。

       KyttenShaderGraph 是 KyttenEngine 的可视化编辑系统，通过实时 DAG 和代码生成，生成最终的 .kshader 文件。预计在 0.2.0 版本中加入。

       相关文献包括《Cross-Platform Shader Handling》、Slang API 用户指南、Shader Playground 等。

OpenGL自学笔记(四)(着色器)

       这一章节没有太多新内容，主要是云豹源码生成app对之前内容的复述。如果你熟悉shadertoy，那么这一部分可能不需要过多解释。更建议阅读资深人士的教程。

       着色器（Shader）是一种运行在GPU上的小程序，为图形渲染管道的特定部分提供支持。从基本意义上讲，着色器是一种将输入转换为输出的程序。着色器非常独立，它们之间不能相互通信，唯一的沟通方式是通过输入和输出。

       着色器使用GLSL（类似C语言）编写。除了GLSL，还有HLSL、CG等其他语言。GLSL是为图形计算专门设计的，包含针对向量和矩阵的有用特性。

       以下是着色器的基础结构。

       在顶点着色器中，每个输入变量被称为顶点属性。可声明的顶点属性数量有限，通常由硬件决定。一般至少有个（包含4个分量）的顶点属性可用。

       GLSL包含C等其他语言的大部分默认基础类型：int、float、double、unit和bool。同时还有两种容器类型：向量（Vector）和矩阵（Matrix）。

       GLSL中的向量是一个可以包含最高4个分量的容器，分量类型是基础类型之一。大多数情况下，使用vecn就足够了。一个拥有4个分量的向量可以通过点访问符号进行访问，分别使用.x、.y、.z和.w来获取第1~4个分量。对于颜色，则使用rgba进行访问，同理对纹理坐标则使用stpq访问相同的分量。

       重组是向量分量的一种灵活用法，允许使用原来向量的分量任意组合形成一个新的向量。但是不允许从vec2中获取.z元素，即2维向量不能获取第四个分量。也可以把一个向量作为一个参数传给不同的向量构造函数。

       着色器是独立的小程序，但也是整体的一部分。因此，每个着色器都有输入和输出，以便进行数据交流和传递。GLSL定义了in和out关键字专门来实现这个目的。每个着色器使用这两个关键字设定输入和输出，只要一个输出变量与下一个着色器阶段的输入匹配，它就会传递下去。但在顶点和片段着色器中会有所不同。

       顶点着色器应该接收特殊形式的输入，否则会效率低下。顶点着色器的输入特殊在于它直接从顶点数据中接收输入。为了定义顶点数据该如何管理，使用location这一元数据指定输入变量，这样我们才可以在CPU上配置顶点属性。我们已经在前面的教程中看过这个了，layout (location = 0)。顶点着色器需要为它的输入提供一个额外的layout标识，以便将其链接到顶点数据。也可以通过在OpenGL代码中使用glGetAttribLocation查询属性位置值（Location）。

       另一个例外是片段着色器，它需要一个vec4颜色输出变量，因为片段着色器需要生成一个最终输出的颜色。如果你在片段着色器中没有定义输出颜色，OpenGL会把你的物体渲染为黑色（或白色）。

       因此，如果我们打算从一个着色器向另一个着色器发送数据，我们必须在发送方着色器中声明一个输出，在接收方着色器中声明一个类似的输入。当类型和名字都一样的时候，OpenGL就会把两个变量链接到一起，它们之间就能发送数据了（这是在链接程序对象时完成的）。

       uniform是一种从CPU中的应用向GPU中的着色器发送数据的方式，但uniform和顶点属性有些不同。首先，uniform是全局的（Global）。全局意味着uniform变量必须在每个着色器程序对象中都是独一无二的，而且它可以被着色器程序的任意着色器在任意阶段访问。其次，无论你把uniform值设置成什么，uniform会一直保存它们的数据，直到它们被重置或更新。

       我们可以在一个着色器中添加uniform关键字至类型和变量名前来声明一个GLSL的uniform。从此处开始我们就可以在着色器中使用新声明的uniform了。通过uniform设置三角形的颜色：

       这里在片段着色器中声明了一个uniform的四维向量作为最终颜色输出。因为uniform是全局变量，可以在任何着色器中定义它们，而无需通过顶点着色器作为中介，所以不用在顶点着色器中定义这个uniform。

       如果声明了一个uniform却在GLSL代码中没用过，编译器会静默移除这个变量，导致最后编译出的版本中并不会包含它，这可能导致几个非常麻烦的错误！

       这个uniform现在还是空的；我们还没有给它添加任何数据，所以下面我们就做这件事。我们首先需要找到着色器中uniform属性的索引/位置值。当我们得到uniform的索引/位置值后，我们就可以更新它的值了。这次我们不去给像素传递单独一个颜色，而是让它随着时间改变颜色：

       glfwGetTime()获取程序运行秒数，使用sin得到[-1,1]区间的值，最后做一个[0-1]区间的规范化，储存为一个变量。用glGetUniformLocation查询uniform变量的位置值。参数就是着色器程序对象和uniform变量名。如果返回-1，意味着没有找到。最后是通过glUniform4f函数设置uniform变量的值（根据位置值设置变量）第一个参数是位置值，后面就是设置的值了。

       查询uniform地址不要求你之前使用过着色器程序，但是更新一个uniform之前你必须先激活程序，因为它是在当前激活的着色器程序中设置uniform的。

       现在写一个着色器类用来读取硬盘中的着色器文件，编译并链接它们。

       这里把所有的着色器类都放在头文件中。第一行的包含是用来防止链接冲突的，once意思是该头文件只被包含一次。着色器类储存了着色器程序的ID。它的构造函数需要顶点和片段着色器源代码的文件路径，这样可以把着色器源码的文本文件储存在硬盘上。use用来激活着色器程序。所有的set…函数能够查询一个uniform的位置值并设置它的值。

       这里我创建了一个新的CPP文件用来定义着色器头文件中的声明内容。

       构造函数中是处理着色器文件的读取并编译和链接着色器。而检查编译和链接的函数如下。除此之外还有激活程序，自己额外加了个删除的程序。

       uniform的setter函数：

       创建一个着色器对象，读取文件路径即可。

       有可能这一步会出一点问题，不知道具体包含路径。我这里的../表示上级目录，这里是返回到解决方案文件夹了。

       其实可以在构造函数中的catch中打印当前输入的路径，就可以知道路径与资源文件夹中路径是否一致。

       最后在渲染循环中渲染：

OpenGL - 教程 -调试图形学

       图形编程的确能带来乐趣，但错误的渲染或完全未渲染都会让人沮丧。在与像素打交道时，找到问题源头往往困难重重。与CPU调试不同，OpenGL调试没有控制台输出，不能在GLSL代码中设置断点，也无法检查GPU运行状态。下面介绍一些调试OpenGL程序的技巧，这些技巧将大大帮助你解决问题。

       首先，了解OpenGL中的用户错误标记。当你使用OpenGL不当（例如在绑定之前配置缓冲）时，它会检测到错误，并在幕后生成用户错误标记。通过调用glGetError()函数，可以查询这些错误标记并返回错误值。例如，glBindTexture()函数的文档中列出了所有可能生成的用户错误代码。

       值得注意的是，glGetError()在每次调用后会清除所有错误标记，因此在循环中调用该函数以检查每帧可能的错误更为合适。在分布式系统（如X）中，glGetError()只会清除一个错误代码标记，这意味着在多次调用之间可能有多个错误发生。

       利用glGetError()定位错误来源非常有效，通过在代码中各处调用它，可以快速确定OpenGL错误的源头。此外，可以编写辅助函数将错误代码与错误发生的位置（使用预处理器指令__FILE__和__LINE__）结合打印出来，便于追踪错误。

       对于OpenGL 4.3及以上版本，可以使用调试输出拓展，它直接将更详细的信息发送给用户，有助于使用调试器捕捉错误源头。在GLFW中请求调试输出非常简单，只需要在创建窗口之前设置提醒。调试输出上下文启用后，每次不正确的OpenGL指令都会提供大量有用的错误信息。

       利用调试输出，可以很容易地找到错误发生的准确行号或调用。通过在特定错误类型或函数顶部设置断点，调试器在抛出错误时捕捉信息，帮助快速定位问题。此外，可以使用glDebugMessageInsert()函数自定义错误输出，方便与使用调试输出的程序或OpenGL代码协同开发。

       对于GLSL着色器，虽然无法直接使用如glGetError()的函数，但可以利用输出变量到帧缓冲的颜色通道来快速检查着色器代码的正确性。通过观察视觉结果，可以快速识别变量是否显示了正确的值。这种方法适用于检查法向量、纹理等变量是否正确传递。

       确保你的着色器代码符合GLSL规范，可以使用OpenGL GLSL参考编译器进行检查。下载可执行版本或完整源码，将着色器文件作为参数传递，编译器会报告任何规范不符合的情况。

       显示帧缓冲的内容是调试的一个好方法，特别是当帧缓冲在幕后运行时。通过简单的着色器编写一个助手函数，可以在屏幕右上角快速显示任何纹理，以便检查帧缓冲输出。这种方法能让你对帧缓冲内容保持持续反馈。

       在遇到上述方法无法解决问题时，可以使用第三方调试软件。这些工具通常可以注入OpenGL驱动，拦截各种OpenGL调用，提供大量有用的数据，如性能测试、缓冲内存检查、纹理和帧缓冲附件显示等。适合大规模产品代码开发。

       推荐的调试工具包括gDebugger、RenderDoc、CodeXL、NVIDIA Nsight等，它们在不同方面提供强大支持。每款工具都有其优点和适用场景，选择最适合你需求的工具。

什么是编译着色器？

       编译着色器通常由硬件厂商或供应商提供的图形库或驱动程序提供。在编写着色器的时候，开发人员通过编写高级语言的着色器代码来描述图形对象的渲染与计算过程。但是，纯文本并不能被GPU直接理解和执行，所以需要先经过编译器的编译处理才能被GPU识别。

       不同的硬件和图形库有着不同的着色器编译器，默认提供的编译器可以处理基本的编译问题，但对于一些特殊的编译需求（比如高级的优化和调试功能），编译着色器会需要额外的支持。

编译着色器的特点

       编译着色器可以将多种着色器语言编译为GPU可以执行的指令，例如GLSL、HLSL等。编译着色器可以支持多种GPU，以便能够在不同的硬件平台上进行优化。编译着色器可以支持多种优化技术，例如常量池化、代码合并、指令级并行等，以提高着色器的执行性能。

       一些编译着色器支持在线编译，可以实现即时编译和调试，方便开发者进行调试和优化。编译着色器可以支持多种着色器应用，例如游戏、图形处理、虚拟现实等，以满足不同领域的需求。

       以上内容参考：百度百科-着色器

OpenCV中几种卷积的实现方式

       自从opencv引入dnn模块后，卷积实现方式不断扩展，以适应PC、手机、边缘计算设备的部署需求。目前，可调用CUDA、OpenCL、Tengine、Vulkan实现卷积。Tengine、Vulkan特别适用于移动设备和边缘计算，它们内部是如何实现的？

       Vulkan是一个渲染库，与OpenGL、DirectX等GPU渲染库相比，移动设备上使用较多，而深度学习模型又需要在移动设备上部署。因此，探索是否可以使用Vulkan实现卷积等深度学习操作。

       接下来，让我们看看OpenCV是如何使用Vulkan实现深度神经网络中的卷积。

       打开OpenCV源码库的modules/dnn/src目录，可以看到最后一个文件夹是vkcom。"vkcom"这个名字由"Vulkan"库本身与"comp"（glsl语言的源代码后缀）组成。glsl语言可以通过以下命令编译：“vkcom”。GLSL是OpenGL着色语言，用于编写OpenGL着色器的编程语言，通常与并行处理功能强大的GPU结合使用。深度学习操作如卷积、池化都是对图像颜色的处理，因此可以将这些操作实现为着色器，用GLSL编写，然后使用Vulkan调用GPU。

       Vulkan实现的卷积代码示例如下：

       代码中指定了输入输出变量（第3、6、9、行）。在第行计算了输出变量convolved_image_data的值。第行开始的for循环遍历卷积核的c、w、h，计算单个像素位置的卷积结果。显然，这个卷积仅计算一个像素位置的卷积结果，卷积核的滑动过程由Vulkan管理GPU，多个GPU计算单元并行完成。

       在OpenCV中，文件conv.comp首先被编译为二进制，然后将此二进制作为字符串放入conv_spv.cpp中。cpp文件定义了conv_spv数组，其中包含编译后的卷积着色器执行代码。由OpBase::createShaderModule函数将此二进制送入vkCreateShaderModule，从而调度GPU。

       通过分析代码，可以看到Vulkan实现的算子被调用的方式，这同样适用于CUDA、OpenCL、Ngraph、Inference Engine等实现的算子。

       Vulkan渲染库在OpenCV中的调用逻辑已经阐述完毕。Tengine是如何使用的？在convolution_layer.cpp的forward函数的行，调用了tengine_forward(tengine_graph)。

       Tengine_forward来自teng_run_graph函数，我们只需调用库即可得到结果。传入的graph是卷积图，由create_conv_graph在第行创建。create_conv_graph使用create_conv_node、create_input_node生成卷积算子所需的图。

       使用Tengine相对使用Vulkan、CUDA等库完成算子，要简单许多。调用库内的函数生成节点，使用节点构建图即可，无需自己实现算子内的计算。

       本文概述了OpenCV中卷积实现方式的多样性，以下为总结：

       本文详细分析了使用Vulkan用着色器实现卷积计算的方法及其调用路径，这个路径在分析其他类型实现时也很有用。本文还探讨了不同库算子的兼容性。当然，不同算子兼容还涉及更多细节，本文仅关注卷积forward函数的传递。

       本文后半部分简要介绍了Tengine在OpenCV中的集成。发现集成过程相对简单，在convolution_layer.cpp中直接运行Tengine库构建的卷积计算图。这也表明，如果存在更好的边缘计算库，很容易集成到OpenCV中。

       通过几天的分析，我们已经了解了OpenCL、Vulkan、Tengine的实现方式。可以预计，CUDA、Halide、Inference Engine nn、Inference Engine NGraph等实现也会类似。