深海游弋的鱼 – 第 81 页 – 智障儿童欢乐多

macOS Mojave(10.14.2) 编译KhronosGroup/SPIR项目的spir_12分支(llvm-3.2编译)

官方提供了一个名为 KhronosGroup/SPIR 的开源项目，支持OpenCL编译成SPIR代码的功能

注意： Vulkan使用SPIR-V也就是 spirv-1.0 分支，不使用此分支。本文实际上可以作为 llvm-3.2 在最新的 macOS Mojave(10.14.2) 上的编译指南。

这个工具使用的LLVM的版本非常古老，编译的时候问题多多。

这个工具在 macOS Mojave(10.14.2) 系统上使用 gcc 8.2.0 的编译流程如下：

$ cd ~

$ git clone http://llvm.org/git/llvm.git llvm

$ cd llvm

$ git checkout --track -b release_32 remotes/origin/release_32

$ cd llvm/tools

$ git clone https://github.com/KhronosGroup/SPIR clang

$ cd clang

# 官方要求检出 spir_12 分支，但是貌似执行完成 clone 之后，就已经在这个分支上了
# git checkout --track -b spir_12 remotes/origin/spir_12

$ cd ../..

$ mkdir build

$ cd build

# 只能使用GCC编译，不能使用自带的LLVM编译
$ brew install gcc

$ brew unlink gcc

$ brew cleanup

$ brew link gcc

# 指定路径
$ export PATH=$(brew --prefix)/bin:$PATH

# 重定向编译工具到我们安装的GCC版本，版本号从brew的命令行中查询得到，如果安装了多个版本，请手工指定这个参数
$ export GCC_VER=$(brew list --versions | grep gcc | sed 's/$[0-9]$.*/\1/g' | tr -cd "[0-9]")

$ export CC="$(brew --prefix)/bin/gcc-$GCC_VER"

$ export CXX="$(brew --prefix)/bin/g++-$GCC_VER"

# 链接库目录
$ export CMAKE_LIBRARY_PATH=$(brew --prefix)/lib

$ export CMAKE_INCLUDE_PATH=$(brew --prefix)/include

# 不能使用 GCC 引入的 ar,ranlib 这两个程序，这两个程序处理的库不能被ld正常链接，我们需要使用macOS官方提供的 ar,ranlib
# 出现这个问题的原因在于macOS上的GCC并没有提供ld，其实即使提供ld也不能正常执行，原因在于macOS与GNU格式不兼容，无法正常链接
# 因此只能使用系统自带的链接工具，链接工具只认识系统自带的 ar,ranlib 转换后文件的格式
$ mv /usr/local/bin/ranlib /usr/local/bin/ranlib2

$ ln -s /usr/bin/ranlib /usr/local/bin/ranlib

$ mv /usr/local/bin/ar /usr/local/bin/ar2

$ ln -s /usr/bin/ar /usr/local/bin/ar

# 不能编译成动态库，原因在于这个版本的代码存在循环依赖的问题，动态库无法成功编译，只能编译成静态库
$ cmake .. -DBUILD_SHARED_LIBS=OFF

# 多线程同时编译，提高编译速度
$ make -j8

$ cd ~

$ git clone http://llvm.org/git/llvm.git llvm

$ cd llvm

$ git checkout --track -b release_32 remotes/origin/release_32

$ cd llvm/tools

$ git clone https://github.com/KhronosGroup/SPIR clang

$ cd clang

# 官方要求检出 spir_12 分支，但是貌似执行完成 clone 之后，就已经在这个分支上了

# git checkout --track -b spir_12 remotes/origin/spir_12

$ cd ../..

$ mkdir build

$ cd build

# 只能使用GCC编译，不能使用自带的LLVM编译

$ brew install gcc

$ brew unlink gcc

$ brew cleanup

$ brew link gcc

# 指定路径

$ export PATH=$(brew --prefix)/bin:$PATH

# 重定向编译工具到我们安装的GCC版本，版本号从brew的命令行中查询得到，如果安装了多个版本，请手工指定这个参数

$ export GCC_VER=$(brew list --versions | grep gcc | sed 's/$[0-9]$.*/\1/g' | tr -cd "[0-9]")

$ export CC="$(brew --prefix)/bin/gcc-$GCC_VER"

$ export CXX="$(brew --prefix)/bin/g++-$GCC_VER"

# 链接库目录

$ export CMAKE_LIBRARY_PATH=$(brew --prefix)/lib

$ export CMAKE_INCLUDE_PATH=$(brew --prefix)/include

# 不能使用 GCC 引入的 ar,ranlib 这两个程序，这两个程序处理的库不能被ld正常链接，我们需要使用macOS官方提供的 ar,ranlib

# 出现这个问题的原因在于macOS上的GCC并没有提供ld，其实即使提供ld也不能正常执行，原因在于macOS与GNU格式不兼容，无法正常链接

# 因此只能使用系统自带的链接工具，链接工具只认识系统自带的 ar,ranlib 转换后文件的格式

$ mv /usr/local/bin/ranlib /usr/local/bin/ranlib2

$ ln -s /usr/bin/ranlib /usr/local/bin/ranlib

$ mv /usr/local/bin/ar /usr/local/bin/ar2

$ ln -s /usr/bin/ar /usr/local/bin/ar

# 不能编译成动态库，原因在于这个版本的代码存在循环依赖的问题，动态库无法成功编译，只能编译成静态库

$ cmake .. -DBUILD_SHARED_LIBS=OFF

# 多线程同时编译，提高编译速度

$ make -j8

如果使用 Xcode Version 10.1 (10B61) 编译会报告如下错误：

[ 14%] Building CXX object lib/Analysis/CMakeFiles/LLVMAnalysis.dir/LazyValueInfo.cpp.o
llvm/lib/Analysis/LazyValueInfo.cpp:998:14: error: no matching member function for call to
      'insert'
    worklist.insert(worklist.end(), succ_begin(ToUpdate), succ_end(ToUpdate));
    ~~~~~~~~~^~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:713:14: note: 
      candidate function not viable: no known conversion from 'llvm::succ_iterator' (aka
      'SuccIterator<llvm::TerminatorInst *, llvm::BasicBlock>') to 'std::__1::vector<llvm::BasicBlock *,
      std::__1::allocator<llvm::BasicBlock *> >::size_type' (aka 'unsigned long') for 2nd argument
    iterator insert(const_iterator __position, size_type __n, const_reference __x);
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:724:9: note: 
      candidate template ignored: requirement '!__is_forward_iterator<SuccIterator<TerminatorInst *, BasicBlock>
      >::value' was not satisfied [with _InputIterator = llvm::SuccIterator<llvm::TerminatorInst *,
      llvm::BasicBlock>]
        insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:734:9: note: 
      candidate template ignored: requirement 'is_constructible<value_type, typename
      iterator_traits<SuccIterator<TerminatorInst *, BasicBlock> >::reference>::value' was not satisfied [with
      _ForwardIterator = llvm::SuccIterator<llvm::TerminatorInst *, llvm::BasicBlock>]
        insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:705:14: note: 
      candidate function not viable: requires 2 arguments, but 3 were provided
    iterator insert(const_iterator __position, const_reference __x);
             ^
1 error generated.
make[2]: *** [lib/Analysis/CMakeFiles/LLVMAnalysis.dir/LazyValueInfo.cpp.o] Error 1
make[1]: *** [lib/Analysis/CMakeFiles/LLVMAnalysis.dir/all] Error 2
make: *** [all] Error 2

[ 14%] Building CXX object lib/Analysis/CMakeFiles/LLVMAnalysis.dir/LazyValueInfo.cpp.o

llvm/lib/Analysis/LazyValueInfo.cpp:998:14: error: no matching member function for call to

'insert'

worklist.insert(worklist.end(), succ_begin(ToUpdate), succ_end(ToUpdate));

~~~~~~~~~^~~~~~

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:713:14: note:

candidate function not viable: no known conversion from 'llvm::succ_iterator' (aka

'SuccIterator<llvm::TerminatorInst *, llvm::BasicBlock>') to 'std::__1::vector<llvm::BasicBlock *,

std::__1::allocator<llvm::BasicBlock *> >::size_type' (aka 'unsigned long') for 2nd argument

iterator insert(const_iterator __position, size_type __n, const_reference __x);

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:724:9: note:

candidate template ignored: requirement '!__is_forward_iterator<SuccIterator<TerminatorInst *, BasicBlock>

>::value' was not satisfied [with _InputIterator = llvm::SuccIterator<llvm::TerminatorInst *,

llvm::BasicBlock>]

insert(const_iterator __position, _InputIterator __first, _InputIterator __last);

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:734:9: note:

candidate template ignored: requirement 'is_constructible<value_type, typename

iterator_traits<SuccIterator<TerminatorInst *, BasicBlock> >::reference>::value' was not satisfied [with

_ForwardIterator = llvm::SuccIterator<llvm::TerminatorInst *, llvm::BasicBlock>]

insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:705:14: note:

candidate function not viable: requires 2 arguments, but 3 were provided

iterator insert(const_iterator __position, const_reference __x);

1 error generated.

make[2]: *** [lib/Analysis/CMakeFiles/LLVMAnalysis.dir/LazyValueInfo.cpp.o] Error 1

make[1]: *** [lib/Analysis/CMakeFiles/LLVMAnalysis.dir/all] Error 2

make: *** [all] Error 2

上述错误产生的原因在于 macOS 官方提供的 C++ 标准库中增加了校验 is_constructible (要求模版中的类必须明确构造函数和析构函数)这个逻辑，这个功能貌似在 C++ 14 中才加入的，显然这个校验有些操之过急了。

如果编译的时候出现如下错误信息：

ld: warning: ignoring file ../../lib/libLLVMTableGen.a, file was built for archive which is not the architecture being linked (x86_64): ../../lib/libLLVMTableGen.a

ld: warning: ignoring file ../../lib/libLLVMSupport.a, file was built for archive which is not the architecture being linked (x86_64): ../../lib/libLLVMSupport.a

...................................

ld: symbol(s) not found for architecture x86_64

...................................

则说明编译的时候，没有指定使用 macOS 官方提供的 ar , ranlib ,链接这两个程序到Xcode提供的即可。

如果编译的时候出现如下错误信息：

[ 78%] Building CXX object tools/clang/lib/Sema/CMakeFiles/clangSema.dir/AnalysisBasedWarnings.cpp.o
In file included from llvm/tools/clang/include/clang/Sema/DeclSpec.h:26,
                 from llvm/tools/clang/include/clang/Sema/Sema.h:22,
                 from llvm/tools/clang/include/clang/Sema/SemaInternal.h:18,
                 from llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:17:
llvm/tools/clang/include/clang/Sema/AttributeList.h: In constructor 'clang::VecTypeHintAttributeList::VecTypeHintAttributeList(clang::IdentifierInfo*, clang::SourceRange, clang::IdentifierInfo*, clang::SourceLocation, clang::IdentifierInfo*, clang::SourceLocation, clang::ParsedType, clang::AttributeList::Syntax)':
llvm/tools/clang/include/clang/Sema/AttributeList.h:360:75: error: use of deleted function 'clang::AttributeList::~AttributeList()'
                     argumentKindLoc, NULL, 0, syntaxUsed), VecType(vecType) {}
                                                                           ^
In file included from llvm/tools/clang/include/clang/Sema/DeclSpec.h:26,
                 from llvm/tools/clang/include/clang/Sema/Sema.h:22,
                 from llvm/tools/clang/include/clang/Sema/SemaInternal.h:18,
                 from llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:17:
llvm/tools/clang/include/clang/Sema/AttributeList.h:209:3 note: declared here
   ~AttributeList() LLVM_DELETED_FUNCTION;
   ^
make[2]: *** [tools/clang/lib/Sema/CMakeFiles/clangSema.dir/AnalysisBasedWarnings.cpp.o] Error 1
make[1]: *** [tools/clang/lib/Sema/CMakeFiles/clangSema.dir/all] Error 2
make: *** [all] Error 2

[ 78%] Building CXX object tools/clang/lib/Sema/CMakeFiles/clangSema.dir/AnalysisBasedWarnings.cpp.o

In file included from llvm/tools/clang/include/clang/Sema/DeclSpec.h:26,

from llvm/tools/clang/include/clang/Sema/Sema.h:22,

from llvm/tools/clang/include/clang/Sema/SemaInternal.h:18,

from llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:17:

llvm/tools/clang/include/clang/Sema/AttributeList.h: In constructor 'clang::VecTypeHintAttributeList::VecTypeHintAttributeList(clang::IdentifierInfo*, clang::SourceRange, clang::IdentifierInfo*, clang::SourceLocation, clang::IdentifierInfo*, clang::SourceLocation, clang::ParsedType, clang::AttributeList::Syntax)':

llvm/tools/clang/include/clang/Sema/AttributeList.h:360:75: error: use of deleted function 'clang::AttributeList::~AttributeList()'

argumentKindLoc, NULL, 0, syntaxUsed), VecType(vecType) {}

In file included from llvm/tools/clang/include/clang/Sema/DeclSpec.h:26,

from llvm/tools/clang/include/clang/Sema/Sema.h:22,

from llvm/tools/clang/include/clang/Sema/SemaInternal.h:18,

from llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:17:

llvm/tools/clang/include/clang/Sema/AttributeList.h:209:3 note: declared here

~AttributeList() LLVM_DELETED_FUNCTION;

make[2]: *** [tools/clang/lib/Sema/CMakeFiles/clangSema.dir/AnalysisBasedWarnings.cpp.o] Error 1

make[1]: *** [tools/clang/lib/Sema/CMakeFiles/clangSema.dir/all] Error 2

make: *** [all] Error 2

这是由于llvm/tools/clang/include/clang/Sema/AttributeList.h这个文件中的 ~AttributeList() LLVM_DELETED_FUNCTION; 这句话造成的，按理说这个析构函数不应该被调用到才对，但是代码中仍然有地方隐式调用了，我们需要做的就是去掉这行代码的 LLVM_DELETED_FUNCTION 属性即可。

1 2	# macOS 下面的sed相当的蛋痛 $ sed -i "" "s/^[ \t]~AttributeList()[ \t]LLVM_DELETED_FUNCTION;/~AttributeList() ;/g" llvm/tools/clang/include/clang/Sema/AttributeList.h

编译完成后的使用方式如下：

$ cd ~

# for opencl_spir.h

$ git clone https://github.com/KhronosGroup/SPIR-Tools.git

$ ~/llvm/build/bin/clang -cc1 -emit-llvm-bc -triple <triple> <OpenCL compile options> -cl-spir-compile-options "<OpenCL compile options>" -include ~/SPIR-Tools/headers/opencl_spir.h -o <output> <input>

<triple>: for 32 bit SPIR use spir-unknown-unknown, for 64 bit SPIR use spir64-unknown-unknown.
Note: <OpenCL compile options> appears twice. The command line option -cl-spir-compile-options "<OpenCL compile options>" specifies the compile options that occur in the SPIR metadata.
<opencl_spir.h>: download opencl_spir.h from https://github.com/KhronosGroup/SPIR-Tools/blob/master/headers/opencl_spir.h
-O: -O0 (default) is the only tested option value at the moment. It's assumed by design that all optimizations are executed by SPIR consumer.

参考链接

macOS Mojave(10.14.2)使用"sed -i"命令时报错'sed: 1: "xxx": extra characters at the end of l command"'

最近在 macOS Mojave(10.14.2)使用"sed -i"命令时报错,类似如下：

1 2	$ sed -i "s/^[ \t]~AttributeList()[ \t]LLVM_DELETED_FUNCTION;/~AttributeList() ;/g" llvm/tools/clang/include/clang/Sema/AttributeList.h sed: 1: "llvm/tools/clang/includ ...": extra characters at the end of l command

刚刚遇到这个问题，百思不得其解。后来搜索了一下，才找到解释。

如下：

$ man sed

..................................................

-i extension

Edit files in-place, saving backups with the specified extension. If a zero-length extension is given,

no backup will be saved. It is not recommended to give a zero-length extension when in-place editing

files, as you risk corruption or partial content in situations where disk space is exhausted, etc.

...................................................

sed -i 需要带一个字符串，用来备份源文件，这个字符串会加在源文件名后面组成备份的文件名。
如果这个字符串长度为 0，就是说是个空串，那么不备份。

1	$ sed -i "_nima" 's/xx/python/g' example.txt

这样 sed 不仅会修改文件，并且会生成一个 example.txt_nima 的备份文件。

如果不想备份修改前的内容，可以直接给个空参数，如下：

1	$ sed -i "" 's/xx/python/g' example.txt

所以，上面的命令，我们需要修改成如下方式：

1	$ sed -i "" "s/^[ \t]~AttributeList()[ \t]LLVM_DELETED_FUNCTION;/~AttributeList() ;/g" llvm/tools/clang/include/clang/Sema/AttributeList.h

蛮扯淡的。

参考链接

OpenCL代码编译成Vulkan代码(SPIR-V)的工具

最近接到个任务，就是把OpenCL的.cl代码编译成Vulkan程序。

请使用 OpenCL代码编译成Vulkan代码的工具clspv 实现这部分功能，官方提供的转换库，目前看来暂时没办法使用。

根据官方文档，Vulkan 1.0支持OpenCL 1.0/2.1的代码直接编译成Vulkan程序。

官方提供了一个名为 KhronosGroup/SPIR 的开源项目，支持OpenCL编译成SPIR-V代码的功能(Vulkan使用SPIR-V)。

这个工具在 macOS Mojave(10.14.2) 系统上使用 Xcode Version 10.1 (10B61) 编译流程如下：

$ cd ~

$ git clone -b khronos/spirv-3.6.1 https://github.com/KhronosGroup/SPIRV-LLVM.git llvm

$ cd llvm/tools

# 默认分支要求检出 spir_12 分支，但是貌似执行完成 clone 之后，就已经在这个分支上了

# git checkout --track -b spir_12 remotes/origin/spir_12

# 默认是 SPIR 的编译，Vulkan 需要 SPIR-V 两者是不同的

# Vulkan 需要编译 SPIR-V 我们需要手工切换到 spirv-1.0 分支上

$ git clone -b spirv-1.0 https://github.com/KhronosGroup/SPIR clang

$ cd ..

$ mkdir build

$ cd build

$ cmake ..

# 多线程同时编译，提高编译速度

$ make -j8

编译完成后的使用方式如下：

$ ~/llvm/build/bin/clang -cc1 -emit-spirv -triple <triple> -cl-std=<CLversion> -include opencl.h -x cl -o <output> <input>

# 反汇编查看编译结果

$ spirv-dis <output>

<triple>: for 32 bit SPIR-V use spir-unknown-unknown, for 64 bit SPIR-V use spir64-unknown-unknown.
-D: to enable support for extension. e.g. -Dcl_khr_fp16 compile option will enable half support.
-O: -O0 (default) is the only tested option value at the moment. It's assumed by design that all optimizations are executed by SPIR-V consumer.

比如：

# 编译kernel.cl 到 kernel.spir

$ ~/llvm/build/bin/clang -cc1 -emit-spirv -triple=spir-unknown-unknown -cl-std=CL2.0 -include opencl.h kernel.cl -o kernel.spir

# 反汇编查看编译结果

$ spirv-dis kernel.spir

继续阅读

null值在in/not in的陷阱

背景

在某个项目统计数据时，发现以外丢掉了部分数据，仔细查找，是null值在in/not in出现了判断问题。

问题

在统计数据时，需要去除某些值，使用了not in逻辑。

select null not in ('1', '2')

这行代码，要完成的逻辑是，null 不属于 '1' 或者 '2'。

想当然认为应该返回 true，实际上返回了null，null值映射为false。

最终统计丢失了这一部分null值。

继续测试

继续测试了各种null使用in/not in的例子

select null in ('1', '2', null);

select '3' not in ('1', '2', null);

select null not in ('1', '2');

都出现了与想当然不符合的结果

该问题的详细原理可以参考这篇文章 http://www.itpub.net/thread-1325582-1-1.html

小结

null值不应该参与in/not in逻辑判断。

macOS Mojave(10.14.2)系统上好用的Python调试器

以前在ubuntu系统上调试Python脚本，都是使用 Spyder，就是图标是一个蜘蛛网的软件。很好用！

Windows下都是使用 PyScripter 轻量，简便，好用。

但是迁移到macOS Mojave之后，没有找到比较好用的对应软件，后来发现微软开源的 Visual Studio Code 配合微软自己开发的 Python插件，是在macOS Mojave下调试Python脚本的利器。

具体的安装步骤如下图所示：
继续阅读macOS Mojave(10.14.2)系统上好用的Python调试器

基于Vulkan的GPGPU计算框架Vuh

发现一个写的比较好的基于Vulkan的GPGPU计算框架Vuh，github上的代码地址为：

1	https://github.com/Glavnokoman/vuh.git

在macOS Mojave(10.14.2) 中编译方式：

$ git clone https://github.com/Glavnokoman/vuh.git

$ cd vuh/config

$ pip install --user cget

$ export PATH=/Users/`whoami`/Library/Python/2.7/bin:$PATH

$ export CGET_PREFIX=.

# 安装Vulkan相关依赖库

$ bash install_dependencies.sh

# 指定Vulkan相关环境变量，后续的CMake文件中的FindVulkan.cmake会使用这个

$ export VULKAN_SDK=`pwd`

# 我们刚刚安装的Catch2的路径，CMake需要

$ export Catch2_DIR=`pwd`/lib/cmake/Catch2

$ export ARGS=-DCatch2_DIR=$Catch2_DIR

# 安装其他依赖

$ brew install spdlog

$ brew install doxygen

$ cd ..

$ mkdir build

$ cd build

$ cmake .. $ARGS

$ make

如果编译的时候报错

Scanning dependencies of target vuh_example_spdlog

[ 60%] Building CXX object doc/examples/spdlog/CMakeFiles/vuh_example_spdlog.dir/main.cpp.o

/Users/xxx/Source/vuh/doc/examples/spdlog/main.cpp:14:27: error: no member named

'basic_logger_mt' in namespace 'spdlog'

static auto logger = spd::basic_logger_mt("logger", "vuh.log");

~~~~~^

1 error generated.

make[2]: *** [doc/examples/spdlog/CMakeFiles/vuh_example_spdlog.dir/main.cpp.o] Error 1

make[1]: *** [doc/examples/spdlog/CMakeFiles/vuh_example_spdlog.dir/all] Error 2

make: *** [all] Error 2

这个原因是由于新版本的spdlog-1.2.1变更了basic_logger_mt这个类的头文件。

在源代码的vuh/doc/examples/spdlog/main.cpp中，包含如下头文件即可：

1	#include <spdlog/sinks/basic_file_sink.h>

如果需要编译 Android 版本，那么如下方式进行编译：

$ git clone https://github.com/Glavnokoman/vuh.git

$ cd vuh/config

$ pip install --user cget

$ export PATH=/Users/`whoami`/Library/Python/2.7/bin:$PATH

$ export CGET_PREFIX=.

# 安装Vulkan相关依赖库

$ bash install_dependencies.sh

$ export ANDROID_NDK_HOME=~/Library/Android/sdk/ndk-bundle

$ cd ..

$ mkdir build

$ cd build

$ cmake .. \

-DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake \

-DANDROID_ABI="armeabi-v7a" \

-DCMAKE_BUILD_TYPE=Release \

-DANDROID_STL=c++_static \

-DANDROID_NATIVE_API_LEVEL=android-24 \

-DANDROID_TOOLCHAIN=clang \

-DVUH_BUILD_TESTS=OFF \

-DVUH_BUILD_DOCS=OFF \

-DVUH_BUILD_EXAMPLES=OFF \

-DCMAKE_CXX_FLAGS="-DVK_USE_PLATFORM_ANDROID_KHR=1 -DVULKAN_HPP_TYPESAFE_CONVERSION=1 -I$ANDROID_NDK_HOME/sources/third_party/vulkan/src/include/"

# 最后生成 libvuh.so ，然后自己写代码调用这个库即可，简单的直接修改代码中的例子即可

$ make

注意最后几个参数，文档，测试用例，例子都不参与编译，原因在于这几个工程不适合 Android 上运行，最后需要定义几个 C++ 的编译宏，否则编译不通过。

如果上面编译的时候，提示如下错误信息：

[ 20%] Building CXX object src/CMakeFiles/vuh.dir/instance.cpp.o
vuh/src/instance.cpp:127:33: error: incompatible operand
      types ('vuh::debug_reporter_t' (aka 'unsigned int (*)(unsigned int,
      VkDebugReportObjectTypeEXT, unsigned long long, unsigned int, int, const
      char *, const char *, void *) __attribute__((pcs("aapcs-vfp")))') and
      'auto (*)(VkDebugReportFlagsEXT, VkDebugReportObjectTypeEXT, uint64_t,
      size_t, int32_t, const char *, const char *, void *) -> VkBool32' (aka
      'auto (*)(unsigned int, VkDebugReportObjectTypeEXT, unsigned long long,
      unsigned int, int, const char *, const char *, void *) -> unsigned int'))
           , _reporter(report_callback ? report_callback : debugReporter)
                                       ^ ~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~
vuh/src/instance.cpp:128:49: warning: field '_reporter' is
      uninitialized when used here [-Wuninitialized]
           , _reporter_cbk(registerReporter(_instance, _reporter))
                                                       ^
1 warning and 1 error generated.
make[2]: *** [src/CMakeFiles/vuh.dir/instance.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/vuh.dir/all] Error 2
make: *** [all] Error 2

[ 20%] Building CXX object src/CMakeFiles/vuh.dir/instance.cpp.o

vuh/src/instance.cpp:127:33: error: incompatible operand

types ('vuh::debug_reporter_t' (aka 'unsigned int (*)(unsigned int,

VkDebugReportObjectTypeEXT, unsigned long long, unsigned int, int, const

char *, const char *, void *) __attribute__((pcs("aapcs-vfp")))') and

'auto (*)(VkDebugReportFlagsEXT, VkDebugReportObjectTypeEXT, uint64_t,

size_t, int32_t, const char *, const char *, void *) -> VkBool32' (aka

'auto (*)(unsigned int, VkDebugReportObjectTypeEXT, unsigned long long,

unsigned int, int, const char *, const char *, void *) -> unsigned int'))

, _reporter(report_callback ? report_callback : debugReporter)

^ ~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

vuh/src/instance.cpp:128:49: warning: field '_reporter' is

uninitialized when used here [-Wuninitialized]

, _reporter_cbk(registerReporter(_instance, _reporter))

1 warning and 1 error generated.

make[2]: *** [src/CMakeFiles/vuh.dir/instance.cpp.o] Error 1

make[1]: *** [src/CMakeFiles/vuh.dir/all] Error 2

make: *** [all] Error 2

这个错误的原因是 vuh/src/instance.cpp 中定义

/// Default debug reporter used when user did not care to provide his own.

static auto debugReporter(

VkDebugReportFlagsEXT , VkDebugReportObjectTypeEXT, uint64_t, size_t, int32_t

, const char* pLayerPrefix

, const char* pMessage

, void* /*pUserData*/

)-> VkBool32

{

std::cerr << "[Vulkan]:" << pLayerPrefix << ": " << pMessage << "\n";

return VK_FALSE;

}

的时候，缺少 VKAPI_ATTR 这个宏。貌似只有在 Android 平台上这个宏被赋值，其他平台都是空。因此其他平台编译的时候，没有这个参数也是没问题的。

修改后的结果为：

/// Default debug reporter used when user did not care to provide his own.

static auto VKAPI_ATTR debugReporter(

VkDebugReportFlagsEXT , VkDebugReportObjectTypeEXT, uint64_t, size_t, int32_t

, const char* pLayerPrefix

, const char* pMessage

, void* /*pUserData*/

)-> VkBool32

{

std::cerr << "[Vulkan]:" << pLayerPrefix << ": " << pMessage << "\n";

return VK_FALSE;

}

VKAPI_ATTR 这个宏在 vk_platform.h这个文件中被定义，定义的具体内容如下：

/*
***************************************************************************************************
*   Platform-specific directives and type declarations
***************************************************************************************************
*/

/* Platform-specific calling convention macros.
 *
 * Platforms should define these so that Vulkan clients call Vulkan commands
 * with the same calling conventions that the Vulkan implementation expects.
 *
 * VKAPI_ATTR - Placed before the return type in function declarations.
 *              Useful for C++11 and GCC/Clang-style function attribute syntax.
 * VKAPI_CALL - Placed after the return type in function declarations.
 *              Useful for MSVC-style calling convention syntax.
 * VKAPI_PTR  - Placed between the '(' and '*' in function pointer types.
 *
 * Function declaration:  VKAPI_ATTR void VKAPI_CALL vkCommand(void);
 * Function pointer type: typedef void (VKAPI_PTR *PFN_vkCommand)(void);
 */
#if defined(_WIN32)
    // On Windows, Vulkan commands use the stdcall convention
    #define VKAPI_ATTR
    #define VKAPI_CALL __stdcall
    #define VKAPI_PTR  VKAPI_CALL
#elif defined(__ANDROID__) && defined(__ARM_ARCH) && __ARM_ARCH < 7
    #error "Vulkan isn't supported for the 'armeabi' NDK ABI"
#elif defined(__ANDROID__) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 && defined(__ARM_32BIT_STATE)
    // On Android 32-bit ARM targets, Vulkan functions use the "hardfloat"
    // calling convention, i.e. float parameters are passed in registers. This
    // is true even if the rest of the application passes floats on the stack,
    // as it does by default when compiling for the armeabi-v7a NDK ABI.
    #define VKAPI_ATTR __attribute__((pcs("aapcs-vfp")))
    #define VKAPI_CALL
    #define VKAPI_PTR  VKAPI_ATTR
#else
    // On other platforms, use the default calling convention
    #define VKAPI_ATTR
    #define VKAPI_CALL
    #define VKAPI_PTR
#endif

***************************************************************************************************

* Platform-specific directives and type declarations

***************************************************************************************************

/* Platform-specific calling convention macros.

* Platforms should define these so that Vulkan clients call Vulkan commands

* with the same calling conventions that the Vulkan implementation expects.

* VKAPI_ATTR - Placed before the return type in function declarations.

* Useful for C++11 and GCC/Clang-style function attribute syntax.

* VKAPI_CALL - Placed after the return type in function declarations.

* Useful for MSVC-style calling convention syntax.

* VKAPI_PTR - Placed between the '(' and '*' in function pointer types.

* Function declaration: VKAPI_ATTR void VKAPI_CALL vkCommand(void);

* Function pointer type: typedef void (VKAPI_PTR *PFN_vkCommand)(void);

#if defined(_WIN32)

// On Windows, Vulkan commands use the stdcall convention

#define VKAPI_ATTR

#define VKAPI_CALL __stdcall

#define VKAPI_PTR VKAPI_CALL

#elif defined(__ANDROID__) && defined(__ARM_ARCH) && __ARM_ARCH < 7

#error "Vulkan isn't supported for the 'armeabi' NDK ABI"

#elif defined(__ANDROID__) && defined(__ARM_ARCH) && __ARM_ARCH >= 7 && defined(__ARM_32BIT_STATE)

// On Android 32-bit ARM targets, Vulkan functions use the "hardfloat"

// calling convention, i.e. float parameters are passed in registers. This

// is true even if the rest of the application passes floats on the stack,

// as it does by default when compiling for the armeabi-v7a NDK ABI.

#define VKAPI_ATTR __attribute__((pcs("aapcs-vfp")))

#define VKAPI_CALL

#define VKAPI_PTR VKAPI_ATTR

#else

// On other platforms, use the default calling convention

#define VKAPI_ATTR

#define VKAPI_CALL

#define VKAPI_PTR

#endif

Vulkan官方API文档Vulkan® 1.0.95 - A Specification

Vulkan官方API文档 Vulkan® 1.0.95 - A Specification 对于开发者来说，非常有用。

由于官方网站访问非常缓慢，建议下载PDF版本到本地来查看。

官方文档地址： Vulkan® 1.0.95 - A Specification - Khronos Group

官方PDF版本地址： Vulkan® 1.0.95 - A Specification - Khronos Group

本站的一份PDF版拷贝
继续阅读Vulkan官方API文档Vulkan® 1.0.95 - A Specification

Vulkan中的"#version 430 core"的理解

最近在学习Vulkan,结果在查看示例代码的时候：

#version 430 core

layout (local_size_x = 64) in;

layout(std430, binding=4 ) buffer INFO

{

vec2 info[];

};

void main()

{

uint gid = gl_GlobalInvocationID.x;

info[gid].x += 1.0;

info[gid].y += 1.0;

memoryBarrier();

}

对于如下语句出现了疑问

1	#version 430 core

这句话的意思是OpenGL必须是4.3以及以上的版本。

那么是不是意味着，如果设备上的OpenGL低于这个版本，那么我们编写的Vulkan代码就不能执行呢？

答案是否定的，目前我们开发Vulkan默认是使用GLSL（OpenGL Shading Language）语言，然后编译完成后的操作符被直接映射成Vulkan的定义操作符。

换句话说，我们只要执行如下命令，

1	$ glslangValidator xx.comp --target-env vulkan1.0

能编译通过，就可以随意指定#version的版本。

这个版本号仅仅是GLSL语言在进行语法检查的时候需要的，而Vulkan是没有这个版本号需要的。

如果不使用GLSL语言编写，上述的#version应该都不会在语法中出现。

继续阅读Vulkan中的"#version 430 core"的理解

Vulkan中的gl_GlobalInvocationID, local_size_x的理解

最近在学习Vulkan,结果在查看示例代码的时候，对于如下两句出现了疑问：

1	layout(local_size_x = X, local_size_y = Y, local_size_z = Z) in;

1	ivec3 pos = ivec3(gl_GlobalInvocationID);

首先是Invocation这个单词的理解，计算机语言中他的意思是 "the act of making a particular function start" ,中文意思是 "调用，启用"。

其中

1	layout(local_size_x = X, local_size_y = Y, local_size_z = Z) in;

意思是初始化，X * Y * Z 个计算单元供我们的代码调用，可以简单理解成线程数。如果不设置这几个值，默认值是 1，也就是只提供一个计算单元（线程）。

而使用如下的代码

1	ivec3 pos = ivec3(gl_GlobalInvocationID);

意思是获取当前代码运行的计算单元的编号，也可以理解成获取当前线程的索引。

下面的代码都使用如下的命令编译成Vulkan使用的SPIR-V格式的代码

1	$ glslangValidator xx.comp --target-env vulkan1.0

比如下面的代码,就是一个简单的利用gl_GlobalInvocationID，进行并行计算的例子：

#version 430 core

layout (local_size_x = 64) in;

layout(std430, binding=4 ) buffer INFO

{

vec2 info[];

};

void main()

{

uint gid = gl_GlobalInvocationID.x;

info[gid].x += 1.0;

info[gid].y += 1.0;

memoryBarrier();

}

但是，如果传入的数组的大小超过我们设置的计算单元的数量的情况，上述的代码是处理不了的。

可以如下方式处理上述情况：

/*atomicAdd 从4.30版本的opengl开始提供，之前的版本没有这个函数*/

#version 430 core

layout (local_size_x = 64) in;

layout(std430, binding=4 ) buffer INFO

{

vec2 info[];

};

layout(std430, binding=5 ) buffer LEN

{

uint len;

};

uint counter = 0;

void main()

{

uint gid = atomicAdd(counter,1);

if (gid <= len ) {

info[gid].x += 1.0;

info[gid].y += 1.0;

memoryBarrier();

}

void main()

{

uint gid = atomicAdd(counter,1);

if (gid <= len ) {

info[gid].x += 1.0;

info[gid].y += 1.0;

memoryBarrier();

}

如果想动态调整计算单元的数量，增加处理灵活性，可以参考下面的代码：

#version 450

layout(local_size_x_id = 0) in;

layout(local_size_y_id = 1) in;

layout(local_size_z_id = 2) in;

//rest of the shader

外部通过

VkResult vkCreateComputePipelines(

VkDevice device,

VkPipelineCache pipelineCache,

uint32_t createInfoCount,

const VkComputePipelineCreateInfo* pCreateInfos,

const VkAllocationCallbacks* pAllocator,

VkPipeline* pPipelines);

函数调用的时候，指定

typedef struct VkComputePipelineCreateInfo {

VkStructureType sType;

const void* pNext;

VkPipelineCreateFlags flags;

VkPipelineShaderStageCreateInfo stage;

VkPipelineLayout layout;

VkPipeline basePipelineHandle;

int32_t basePipelineIndex;

} VkComputePipelineCreateInfo;

参数中的

typedef struct VkPipelineShaderStageCreateInfo {

VkStructureType sType;

const void* pNext;

VkPipelineShaderStageCreateFlags flags;

VkShaderStageFlagBits stage;

VkShaderModule module;

const char* pName;

const VkSpecializationInfo* pSpecializationInfo;

} VkPipelineShaderStageCreateInfo;

参数中的

typedef struct VkSpecializationInfo {

uint32_t mapEntryCount;

const VkSpecializationMapEntry* pMapEntries;

size_t dataSize;

const void* pData;

} VkSpecializationInfo;

参数中的

typedef struct VkSpecializationMapEntry {

uint32_t constantID;

uint32_t offset;

size_t size;

} VkSpecializationMapEntry;

指定的数值来动态调整所需要的计算单元的数量。

整个参数的设置流程特别长，非常难掌握。具体的使用例子参考 Glavnokoman/vuh以及 Vulkan® 1.0.95 - A Specification - Khronos Group文档中的上述参数的使用例子。

如果内部不指定，也可以通过外部调用

void vkCmdDispatch(

VkCommandBuffer commandBuffer,

uint32_t groupCountX,

uint32_t groupCountY,

uint32_t groupCountZ);

的时候设置，但是这样的设置存在一定的灵活性问题，可能需要多个独立的ComputePipeline来配合。

继续阅读Vulkan中的gl_GlobalInvocationID, local_size_x的理解

WordPress 5.0禁用古腾堡(Gutenberg)编辑器

最近升级到WordPress 5.0,这个版本的一个重要功能改进就是Gutenberg 编辑器，但是遗憾的是，这个版本的编辑器目前跟很多插件不兼容。我们只能是暂时禁用Gutenberg 编辑器，而是使用以前的经典版本的编辑器。

另外，目前试用来看，这个编辑器，也不好用。

最简单的办法就是安装官方提供的Classic Editor这个插件，如下图：
继续阅读WordPress 5.0禁用古腾堡(Gutenberg)编辑器

2025 年 6 月
一	二	三	四	五	六	日
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30