Learning Render Graph

2023-08-13

什么是 Render Graph？

Render Graph 或者说 Frame graph 是对复杂渲染管线的一个高度抽象，以图（Graph）的形式呈现渲染过程中的各个步骤，不同的渲染任务之间的依赖关系，以及它们对资源（如纹理、缓冲区等）的使用。

Frame graphs are a design pattern for handling complex rendering pipelines, which are currently used in industry. Their usage is motivated by handling barriers, queue synchronization and memory aliasing in the background by abstracting the rendering pipeline of a frame on a higher level.
—— https://github.com/gfx-rs/gfx/wiki/Frame-graphs

解决什么问题？

在传统的渲染管线中，渲染过程通常被划分为多个阶段，如下图所示：

这些阶段之间存在着输入和输出的依赖关系，其中一个阶段的输出作为下一个阶段的输入。

Render Graph 的主要思想是将渲染过程表示为一个有向无环图（DAG），其中节点表示渲染通道（Render pass），边表示依赖关系。每个渲染通道执行特定的渲染操作，可具有输入和输出资源，例如Texture、Frame Buffer和执行的 Shader/Program。例如，假设节点 A 的输出Texture是节点 B 的输入Texture，那么节点 B 就依赖于节点 A。

通过概括渲染流程中的依赖关系，确保渲染阶段按正确的顺序执行，并且在需要时可基于一定的同步机制（Fence、Semaphore、Resource barriers）尽可能地并行执行渲染通道。

Render Graph 的目标是为了解决大型渲染引擎里复杂渲染管线中的一些问题。如资源生命周期管理、渲染效率、渲染过程的可视化调试等等。

Render Graph 不仅在游戏引擎中广泛应用：

它的理念也在现代图形 API 中可窥一斑，如Vulkan 的 Render Pass、DirectX 12 的 Command List、Metal 的 Render Pass等。

从Android 原生库 (.so) 中里挖掘一些有用的信息

2023-07-25 Android

当一个 Android APP 需要集成别的地方来的原生库（.so）时，你可能也会跟我一样会有那么几点疑惑：

这个 so 用的什么 NDK 版本编译的？会不会跟项目里其它的so 冲突，尤其项目里使用共享 C++ STL的情况下 ANDROID_STL=c++_shared，一个应用不能使用多个 C++ 运行时
这个 so 目标 Android API 等级是多少？会不会大于项目的minSdkVersion？
这个 so 依赖（链接）其它哪些 so？这些 so 有没有都放进项目里？
这个 so 有没有除了用文件哈希之外唯一编号，用来标识崩溃堆栈等？

ps. 本文假定读者有一定 Android Native 开发经验，且理解一些基本的概念。

查看 so 的 NDK 版本信息

通过 readelf 工具查看 Android NDK 编译出来的 so 的 Section headers 里有什么 Android 特有的玩意。

ps. 可以用 ndk-which 找到 NDK 中预编译好的 readelf：

1 2	$ $ANDROID_NDK_HOME/ndk-which --abi arm64-v8a readelf /~/ndk/21.4.7075529/prebuilt/darwin-x86_64/bin/../../../toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-readelf

定义一个名为 readelf 的 alias 方便在 Terminal 中调用 aarch64-linux-android-readelf

$ alias readelf=`$ANDROID_NDK_HOME/ndk-which --abi arm64-v8a readelf`
$ readelf -v
GNU readelf (GNU Binutils) 2.27.0.20170315
Copyright (C) 2016 Free Software Foundation, Inc.
...

以 NDK 中带的 libc++_shared.so 为例，在我本机上路径是$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so：

1	$ readelf -WS $ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so

How to run Java standalone app (with JNI) on Android without creating an apk

2023-07-07 Android

In this week, I found a great POC to run a pure Java standalone app (command line tool, no apk) on Android. But what about running a standalone application using JNI (with .so files) on Android like this?

Java app with JNI

Imagine there is a Java program that loads the JNI shared native library to run and use some Android APIs :

HelloWorld.java

package com.example;
import android.os.Build;
import android.util.Log;
public class Helloworld {

    static { System.loadLibrary("hello"); }
    public static native String stringFromJNI();

    public static void main(String[] args) {
        Log.i("@@", "Hello world, " + Build.MANUFACTURER + " "+ Build.MODEL + "!");
        Log.i("@@", stringFromJNI());
        System.out.println(stringFromJNI());
        System.out.println("DONE.");
    }

    public static String getBuildVersion() {
        return Build.VERSION.RELEASE;
    }
}

…the JNI source would be like:

hello-jni.c

// ... emit codes

JNIEXPORT jstring JNICALL
Java_com_example_Helloworld_stringFromJNI(JNIEnv *env,
                                          jobject thiz)
{
  // ... emit codes
  jmethodID versionFunc = (*env)->GetStaticMethodID(env, clz, "getBuildVersion", "()Ljava/lang/String;");

  jstring buildVersion = (*env)->CallStaticObjectMethod(env, clz, versionFunc);
  const char *version = (*env)->GetStringUTFChars(env, buildVersion, NULL);

  if (!version)
  {
    LOGE("Unable to get version string");
  }
  else
  {
    LOGI("Build Version - %s\n", version);
    (*env)->ReleaseStringUTFChars(env, buildVersion, version);
  }
  (*env)->DeleteLocalRef(env, buildVersion);

  return (*env)->NewStringUTF(env,
                              "Hello from JNI !  Compiled with ABI " ABI ".");
}
// ...

The working directory structure

1
2
3

.
├── Helloworld.java
└── hello-jni.c

Compile and deploy

Now we need to compile both the Java and C sources for Android.

Using javac and dx to compile for a jar file which Android can read:

export BUILD_DIR=$PWD/build
export JARFILE=helloworld.jar
export JAVAC_OPTS=-source 1.8 -target 1.8 -cp .:$ANDROID_HOME/platforms/android-30/android.jar
# Compile .java to .class
javac $JAVAC_OPTS -d $BUILD_DIR/classes Helloworld.java
# Convert .class file into a dex file and embedded in a jar file
$ANDROID_HOME/build-tools/30.0.2/dx --output=$BUILD_DIR/$JARFILE --dex ./$BUILD_DIR/classes

Cross-compile the C to Android shared native library via NDK:

# Using the prebuilt toolchain diretly
# See https://developer.android.com/ndk/guides/other_build_systems
export ANDROID_NDK_STANDALONE=$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64
$ANDROID_NDK_STANDALONE/bin/clang \
    --target=aarch64-none-linux-android21 \
    --gcc-toolchain=$ANDROID_NDK_STANDALONE \
    --sysroot $ANDROID_NDK_STANDALONE/sysroot \
    -L${ANDROID_NDK_STANDALONE}/sysroot/usr/lib \
    -shared -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables \
    -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -fPIC \
    -Wl,-llog \
    -Wl,-soname,libhello.so \
    -o $BUILD_DIR/libhello.so hello-jni.c

The build directory looks like:

build
├── classes
│   └── com
│       └── example
│           └── Helloworld.class
├── helloworld.jar
└── libhello.so

Using the adb tool to deploy the helloworld.jar and libhello.so to Android device:

1 2	adb shell mkdir /data/local/tmp/helloworld adb push $BUILD_DIR/helloworld.jar $BUILD_DIR/libhello.so /data/local/tmp/helloworld/

Run appliation on Android

Run helloworld.jar via app_process on Android:

adb shell CLASSPATH="/data/local/tmp/helloworld/helloworld.jar" \
    LD_LIBRARY_PATH=/data/local/tmp/helloworld \
    app_process \
    /data/local/tmp/helloworld \
    com.example.Helloworld
# output
Hello from JNI !  Compiled with ABI arm64-v8a.
DONE.

How to detect memory leaks in C++ programs on macOS

2023-07-03 Cxx

一段很典型的内存泄漏C++ 代码如下：

int main(int argc, const char **argv)
{
    auto *p = new int(10);
    // other codes ...
    p = nullptr; // leaked
    // ...
    return 0;
}

如何在庞大的 C++ 项目代码中找出类似的问题呢？

libgmalloc

苹果提供了内存调试功能：Guard Malloc，用于debug 内存问题。 man libgmalloc 可以查看更多使用信息。

开启libgmalloc的记录 malloc 调用日志的功能，在执行程序前设置环境变量MallocStackLogging=1，如：

1	MallocStackLogging=1 ./my_tool

日志会写到一个临时文件中：

my_tool(38364) MallocStackLogging: stack logs being written to /private/tmp/stack-logs.38364.103f3a000.my_tool.19n2JH.index
my_tool(38364) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder

需要注意的是，在程序退出时，这个调用日志文件会被自动删除：

my_tool(38364) MallocStackLogging: stack logs deleted from /private/tmp/stack-logs.38364.103f3a000.my_tool.19n2JH.index

所以需要将程序在结束时最好 block 住，以便分析日志文件：

#include <iostream>
static void wait_for_input()
{
    std::cout << "Press Enter to exit." << std::endl;
    char b[1];
    std::cin.read(b, 1);
}
int main(int argc, const char **argv)
{
    auto *p = new int(10);
    // other codes ...
    p = nullptr; // leaked
    // ...

    // blocking program for analyzing malloc stack history
    wait_for_input();
    return 0;
}

The leaks Tools

另外，可以直接用 macOS 检测内存泄漏：/usr/bin/leaks （详见：the leaks Tool ）

终端中执行 man leaks 查看使用手册。

leaks 使用方式很简单，指定 pid 即可 attach 到执行中的程序：

# pid=38364
leaks $pid --outputGraph=$pid.memgraph
# open memory graph file with Xcode
open $pid.memgraph

Xcode Memory Graph Debugger

结合起来就是：

修改 C++ 程序 main 函数，使其在结束时 block，重编程序
设置环境变量MallocStackLogging=1，执行程序。
在程序执行结束时，亦即 block 时，执行 leaks，保存 memory graph文件
⌃+C 结束程序
使用 Xcode Memory Graph Debugger 打开 memory graph文件，分析内存泄漏

Debug iOS app in Visual Studio Code

2023-04-22 Debug

使用 LLDB 远程调试程序

调试分为本地调试和远程调试，iOS app 不管安装在模拟器还是真机，均属于远程调试。

这里简述一下大概的原理。

远程启动 lldb-server ，或者叫 debugserver，比如使用 ios-deploy 工具开启真机的 debugserver 并将远程端口的 socket 数据转发（或者叫代理）到本机：

1	ios-deploy --id <device_id> --nolldb --json

输出如下：

{
  "Event" : "PasswordProtectedStatus",
  "Status" : 0
}{
  "Event" : "MountDeveloperImage",
  "SymbolsPath" : "\/~/Library\/Developer\/Xcode\/iOS DeviceSupport\/15.3.1 (19D52)\/Symbols"
}{
  "Event" : "DebugServerLaunched",
  "Port" : 61115
}

DebugServerLaunched 代表真机上的 debugserver 已启动成功，本地转发端口为 61115

ps. <device_id>是你的真机的id，用命令 ios-deploy --detect 可找到真机的id。

本地启动 lldb，先通过 platform select 对应平台（用于加载系统库和符号），之后通过process connect connect://127.0.0.1:<Port> ，通过本地转发的 socket 连接到远端 debugserver 。

之后通过 lldb 设定目标执行文件及其依赖的模块，及其远端文件路径映射，即可实现远程调试

命令行启动lldb，并输入如下：

(lldb) platform select remote-ios
(lldb) file myapp.app
(lldb) process connect connect://127.0.0.1:61115
(lldb) run

这时候你可能会发现报错了： error: No such file or directory (myapp.app)。

因为，对于iOS app 你需要先通过ios-deploy安装到真机上之后，才能走通这个流程：

1 2	# 安装app ios-deploy --id <device_id> --bundle my.app --json

How to explicitly control exported symbols of dynamic shared libraries

2023-04-19 Cxx

Benefits of exporting symbols on demand

Reduce the amount of time of loading the library.
Reduce the size of library.
Optimize the code generation.
Improve library maintainability and make the library easier to use.
Reduce the potential for symbol collision.

List the symbols of shared library

1. nm

https://llvm.org/docs/CommandGuide/llvm-nm.html

nm -gD libxxx.so

2. objdump

https://llvm.org/docs/CommandGuide/llvm-objdump.html

objdump -T libxxx.so

3. readelf

https://man7.org/linux/man-pages/man1/readelf.1.html

readelf -Ws libxxx.so

Option 1. the visibility attribute

#if HAVE_VISIBILITY && BUILDING_LIBFOO
#define LIBFOO_EXPORTED __attribute__((__visibility__("default")))
#elif (defined _WIN32 && !defined __CYGWIN__) && BUILDING_SHARED && BUILDING_LIBFOO
#define LIBFOO_EXPORTED __declspec(dllexport)
#elif (defined _WIN32 && !defined __CYGWIN__) && BUILDING_SHARED
#define LIBFOO_EXPORTED __declspec(dllimport)
#else
#define LIBFOO_EXPORTED
#endif

Compile the code with -fvisibility=hidden flag. This option forces the default visibility of all symbols to be hidden.

1	c++ -I. -fvisibility=hidden -o a.o -c a.cpp

On Windows, using the keyword __declspec(dllexport) to export symbols . See https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport?view=msvc-170

See more details: https://gcc.gnu.org/wiki/Visibility

Android CMake 项目集成 Ccache

2023-04-10 Cxx

Ccache is a compiler cache. 能极大的提升 clean build 编译效率。

github 上有一个为 CMake 提供 Ccache 集成的项目：https://github.com/TheLartians/Ccache.cmake，可以拿过来直接用。

在 cpp 库根目录的 CMakeLists.txt 中添加Ccache.cmake，如：

src/main/cpp/CMakeLists.txt


cmake_minimum_required(VERSION 3.11.0)

project(myapp)

include(FetchContent)
FetchContent_Declare(Ccache.cmake
    GIT_REPOSITORY    https://github.com/TheLartians/Ccache.cmake.git
    GIT_TAG           origin/master
)
FetchContent_MakeAvailable(Ccache.cmake)

注意：FetchContent 最低要求 CMake 3.11

下载安装 Ccache： https://ccache.dev/download.html ，或者使用 Homebrew 安装：brew install ccache

安装完毕后，在 Android 项目的 build.gradle 中记得加上参数开启次模块功能：-DUSE_CCACHE=ON，并给Ccache 加上选项-DCCACHE_OPTIONS=CCACHE_CPP2=true;CCACHE_SLOPPINESS=time_macros,locale,file_stat_matches：

build.gradle


plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
}

android {
    namespace 'com.example.myapplication'
    compileSdk 33

    defaultConfig {
        applicationId "com.example.myapplication"
        minSdk 21
        targetSdk 33
        versionCode 1
        versionName "1.0"

        externalNativeBuild {
            cmake {
                arguments "-DUSE_CCACHE=ON", "-DCCACHE_OPTIONS=CCACHE_CPP2=true;CCACHE_SLOPPINESS=time_macros,locale,file_stat_matches"
            }
        }
    }

    externalNativeBuild {
        cmake {
            path file('src/main/cpp/CMakeLists.txt')
            version '3.22.1'

        }
    }

}

开启 ccache stats log，clean build，日志如下表示命中缓存：

# ~/MyApplication/app/src/main/cpp/native-lib.cpp
direct_cache_hit
local_storage_hit
local_storage_read_hit
local_storage_read_hit

ENJOY it.

沉迷 Midjourney

2023-03-26 AIGC

近些日子沉迷 Midjourney，用不同咒语来回调教 AI，也算体验了一把炼丹的乐趣 —— 投喂一堆奇奇怪怪的东西，得一个匪夷所思的玩意。

推荐一个 Notion 笔记，总结了非常多的风格、建筑、艺术家、摄影技法等等关键字，用来辅助调教：https://marigoldguide.notion.site/marigoldguide/52ac9968a8da4003a825039022561a30?v=057d3669790c4dc28bd8d3ddf35e3a37

比如：
Castle Claude Monet –seed 9875
Castle in the style of Claude Monet --seed 9875

另外还有一个可视化组织咒语的工具网站，也很好用：MidJourney Prompt Helper

下面是我用使用 Midjourney 画的图：

泉州蟳埔女，簪花围：

a pretty young woman smells flower on chair at sunset

/imagine prompt: https://s.mj.run/t3qtGrXY96c, a pretty young woman smells flower on chair at sunset, --q 2 --ar 9:16

蓝眼泪：

In the midnight, the ocean beach

/imagine prompt: https://s.mj.run/gGNA5xDRpCc In the midnight, the ocean beach, rippling light-blue waves, shining stars, weak lights, movie lights, HD, 4k, --ar 16:9 --no moon

宇航员月球种土豆：

astronaut planting potatoes on the moon

/imagine prompt: astronaut planting potatoes on the moon, nebula shines through glass dome, high detail, edge lighting, movie lighting, oc render, 8K --ar 5:3

Bazel run cc_test on Android

2023-02-04 Cxx

See https://github.com/yrom/rules_android_cc_test

如何快速定位 Flutter APP 内存泄漏

2021-12-30 Flutter

当一个 APP 随着业务发展，无用功能越堆越多，参与开发的人员队伍越发壮大，代码大爆炸式膨胀，尽管有一系列的例如人工review、代码规范、静态lint检查之类流程上的克制手段，也止不住坍缩的小宇宙往深不可测无法捉摸的黑洞演进。其中，最为令人头疼的问题莫过于“内存泄漏”。

什么是内存泄漏？很常见却也很不起眼，你我随手写段代码就能轻松让一个对象被垃圾回收器（GC）视而不见。

如下面这一段：

class WidgetA extends StatefulWidget {
  ...
  @override
  _WidgetAState createState() => _WidgetAState();
}

class _WidgetAState extends State<WidgetA> {
  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () async {
        var r = await fetchResult();
        if (mounted) {
            setState(() {
                this.result = r;
            });
        }
      },
      child: ...
    );
  }
}

你能在阅读完这段代码的同时找到那个可能被泄漏的对象吗？

没错，context 可能会短时间泄漏。
但，得益于 Dart 积极高效的 GC 策略，这种泄漏已经算是内存泄漏问题中的可以忽略不计的轻症了。（扩展阅读：Flutter: Don’t Fear the Garbage Collector ）

又如这一段代码：

class _WidgetAState extends State<WidgetA> {
  @override
  void initState() {
    super.initState();
    Provider.of<AuthStateBloc>(context).stream.listen(onAuthStateChanged);
  }
  void onAuthStateChanged(AuthState state) {
    if (mounted) {
      setState(() {
        this.state = state;
      });
    }
  }

有着丰富的 Flutter 开发经验的你，还是很轻松地就发现了，stream.listen 的返回对象StreamSubscription没有被正确地cancel，导致_WidgetAState 和它的 Element (context) 可能都泄漏了，直到祖节点的 Provider<AuthStateBloc> 被卸载才可能被 GC 回收。

那么回到标题，有没有工具可以程序化的发现内存泄漏呢？

首先要解决的问题是怎么找到内存泄漏点？