Filament引擎分析--command抽象设备API

2023-12-07 04:15

本文主要是介绍Filament引擎分析--command抽象设备API,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1. 前言

Filament中使用了FrameGraph来管理渲染管线,需要准备两点:

  • 设备接口抽象:设备API抽象为Command
  • 资源抽象:使用虚拟资源,在实际用到时再创建,方便剔除无用资源

下面就围绕Filament中设备API抽象为Command代码部分做一个解读:

2. 代码分析

先贴一段创建顶点缓冲的接口调用堆栈:

[Inlined] filament::backend::CommandBase::CommandBase(void (*)(filament::backend::Driver &, filament::backend::CommandBase *, int *)) CommandStream.h:63
[Inlined] filament::backend::CommandType<void (filament::backend::Driver::*)(filament::backend::Handle<filament::backend::HwVertexBuffer>, unsigned char, unsigned char, unsigned int, std::__ndk1::array<filament::backend::Attribute, 16u>)>::Command<&filament::backend::Driver::createVertexBufferR(filament::backend::Handle<filament::backend::HwVertexBuffer>, unsigned char, unsigned char, unsigned int, std::__ndk1::array<filament::backend::Attribute, 16u>)>::Command<filament::backend::Handle<filament::backend::HwVertexBuffer>, unsigned char, unsigned char, unsigned int, std::__ndk1::array<filament::backend::Attribute, 16u>>(void (*)(filament::backend::Driver&, filament::backend::CommandBase*, int*), filament::backend::Handle<filament::backend::HwVertexBuffer>&&, unsigned char&&, unsigned char&&, unsigned int&&, std::__ndk1::array<filament::backend::Attribute, 16u>&&) CommandStream.h:154
[Inlined] filament::backend::CommandStream::createVertexBuffer(unsigned char, unsigned char, unsigned int, std::__ndk1::array<>) DriverAPI.inc:169
filament::FVertexBuffer::FVertexBuffer(filament::FEngine &, const filament::VertexBuffer::Builder &) VertexBuffer.cpp:185
[Inlined] utils::Arena::make<>(filament::FEngine &, const filament::VertexBuffer::Builder &) Allocator.h:647
[Inlined] filament::FEngine::create<>(filament::ResourceList<> &, const filament::FVertexBuffer::Builder &) Engine.cpp:680
filament::FEngine::createVertexBuffer(const filament::VertexBuffer::Builder &) Engine.cpp:690
filament::FEngine::init() Engine.cpp:277
filament::FEngine::create(filament::backend::Backend, filament::backend::Platform *, void *, const filament::Engine::Config *) Engine.cpp:110
[Inlined] FilamentTest::setupFilament() FilamentTest.cpp:98
FilamentTest::init() FilamentTest.cpp:68
boxing::xr::composer::StartBase::instance(ANativeWindow *, int, int) StartBase.h:263
[Inlined] native_OnDrawFrame::$_0::operator()() const JniImpl.cpp:100
[Inlined] std::__ndk1::__invoke<>(native_OnDrawFrame::$_0 &) type_traits:3874
[Inlined] std::__ndk1::__apply_functor<>(native_OnDrawFrame::$_0 &, std::__ndk1::tuple<> &, std::__ndk1::__tuple_indices<>, std::__ndk1::tuple<> &&) functional:2853
[Inlined] std::__ndk1::__bind::operator()<>() functional:2886
[Inlined] std::__ndk1::__invoke<>(std::__ndk1::__bind<> &) type_traits:3874
std::__ndk1::__packaged_task_func::operator()() future:1817
[Inlined] std::__ndk1::__packaged_task_function::operator()() const future:1994
std::__ndk1::packaged_task::operator()() future:2214
[Inlined] std::__ndk1::__function::__value_func::operator()() const functional:1884
[Inlined] std::__ndk1::function::operator()() const functional:2556
<lambda>::operator()() const ThreadPool.h:71
[Inlined] decltype(std::__ndk1::forward<boxing::core::ThreadPool::ThreadPool(unsigned int)::'lambda'()>(fp)()) std::__ndk1::__invoke<boxing::core::ThreadPool::ThreadPool(unsigned int)::'lambda'()>(boxing::core::ThreadPool::ThreadPool(unsigned int)::'lambda'()&&) type_traits:3874
[Inlined] std::__ndk1::__thread_execute<>(std::__ndk1::tuple<> &, std::__ndk1::__tuple_indices<>) thread:273
std::__ndk1::__thread_proxy<>(void *) thread:284
__pthread_start(void*) 0x00000000eab36828
__start_thread 0x00000000eaaed5ce

渲染设备API定义:

filament\filament\backend\include\private\backend\DriverAPI.inc

DriverAPI.inc中使用大量的宏替换操作,将设备接口进行封装,或打包,这部分代码可读性极差,不过可从其调用逻辑来进行拆解和理解:
先来分析其中一个接口: createVertexBuffer 创建一个顶点缓冲

DECL_DRIVER_API_R_N(backend::VertexBufferHandle, createVertexBuffer,uint8_t, bufferCount,uint8_t, attributeCount,uint32_t, vertexCount,backend::AttributeArray, attributes)

这里不是真的创建,而要看这个宏接口在哪里使用,我们主要看看这两个地方:

  CommandStream.h  //命令流Driver.h   //设备接口

这两个文件中都对DriverAPI.inc进行了include,但是意义完全不一样,先看DECL_DRIVER_API_R_N:

#define DECL_DRIVER_API_R_N(R, N, ...) \DECL_DRIVER_API_RETURN(R, N, PAIR_ARGS_N(ARG, ##__VA_ARGS__), PAIR_ARGS_N(PARAM, ##__VA_ARGS__))

关键在DECL_DRIVER_API_RETURN这个宏,在CommandStream.h和Driver.h头文件中include文件DriverAPI.inc 之前分别定义了自己的DECL_DRIVER_API_RETURN宏,看看CommandStream.h中:

#define DECL_DRIVER_API(methodName, paramsDecl, params)                                         \inline void methodName(paramsDecl) {                                                        \DEBUG_COMMAND_BEGIN(methodName, false, params);                                         \using Cmd = COMMAND_TYPE(methodName);                                                   \void* const p = allocateCommand(CommandBase::align(sizeof(Cmd)));                       \new(p) Cmd(mDispatcher.methodName##_, APPLY(std::move, params));                        \DEBUG_COMMAND_END(methodName, false);                                                   \}#define DECL_DRIVER_API_SYNCHRONOUS(RetType, methodName, paramsDecl, params)                    \inline RetType methodName(paramsDecl) {                                                     \DEBUG_COMMAND_BEGIN(methodName, true, params);                                          \AutoExecute callOnExit([=](){                                                           \DEBUG_COMMAND_END(methodName, true);                                                \});                                                                                     \return apply(&Driver::methodName, mDriver, std::forward_as_tuple(params));              \}#define DECL_DRIVER_API_RETURN(RetType, methodName, paramsDecl, params)                         \inline RetType methodName(paramsDecl) {                                                     \DEBUG_COMMAND_BEGIN(methodName, false, params);                                         \RetType result = mDriver.methodName##S();                                               \using Cmd = COMMAND_TYPE(methodName##R);                                                \void* const p = allocateCommand(CommandBase::align(sizeof(Cmd)));                       \new(p) Cmd(mDispatcher.methodName##_, RetType(result), APPLY(std::move, params));       \DEBUG_COMMAND_END(methodName, false);                                                   \return result;                                                                          \}

上面三个宏的作用基本是一样的,都将要调用的函数和参数封装为了Command,不同之处在于DECL_DRIVER_API是command无返回值的,DECL_DRIVER_API_SYNCHRONOUS是封装为command后同步执行的,DECL_DRIVER_API_RETURN是需要返回值的
主要看看DECL_DRIVER_API_RETURN:

RetType result = mDriver.methodName##S();    

将方法名后面拼接了S,调用拿到返回类型
看看拼接S后的实现:

Handle<HwVertexBuffer> OpenGLDriver::createVertexBufferS() noexcept {return initHandle<GLVertexBuffer>();
}

initHandle()这句在filament内存池HandleArena上创建了一个GLVertexBuffer对象,然后根据内存地址创建了对象的唯一handeID
再看下面这句:
using Cmd = COMMAND_TYPE(methodName##R);
方法名后面拼接了R,然后获取了command的类型,没有执行方法,看看拼接R后的实现:

void OpenGLDriver::createVertexBufferR(Handle<HwVertexBuffer> vbh,uint8_t bufferCount,uint8_t attributeCount,uint32_t elementCount,AttributeArray attributes) {DEBUG_MARKER()construct<GLVertexBuffer>(vbh, bufferCount, attributeCount, elementCount, attributes);
}

内存池HandleArena上创建了一个GLVertexBuffer对象
再看下面一句

void* const p = allocateCommand(CommandBase::align(sizeof(Cmd)));   
new(p) Cmd(mDispatcher.methodName##_, RetType(result), APPLY(std::move, params));   

在CommandStream内部的环形缓冲上申请了一块Command对象的内存p,然后在内存p上new了对象Command
看看CommandBase* execute执行函数的实现:

inline CommandBase* execute(Driver& driver) {// returning the next command by output parameter allows the compiler to perform the// tail-call optimization in the function called by mExecute, however that comes at// a cost here (writing and reading the stack at each iteration), in the end it's// probably better to pay the cost at just one location.intptr_t next;mExecute(driver, this, &next);return reinterpret_cast<CommandBase*>(reinterpret_cast<intptr_t>(this) + next);
}

mExecute就是上面new(p) Cmd(mDispatcher.methodName##_, RetType(result), APPLY(std::move, params)); 后的函数和参数的封装体,然后拿到了下一个圆形缓冲中下一个command的地址偏移量next,返回下一个command地址
CommandStream中执行command,执行完然后获取下一个执行。。。

mDriver.execute([this, buffer]() {Driver& UTILS_RESTRICT driver = mDriver;CommandBase* UTILS_RESTRICT base = static_cast<CommandBase*>(buffer);while (UTILS_LIKELY(base)) {base = base->execute(driver);}
});

这篇关于Filament引擎分析--command抽象设备API的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/464456

相关文章

Android kotlin中 Channel 和 Flow 的区别和选择使用场景分析

《Androidkotlin中Channel和Flow的区别和选择使用场景分析》Kotlin协程中,Flow是冷数据流,按需触发,适合响应式数据处理;Channel是热数据流,持续发送,支持... 目录一、基本概念界定FlowChannel二、核心特性对比数据生产触发条件生产与消费的关系背压处理机制生命周期

Knife4j+Axios+Redis前后端分离架构下的 API 管理与会话方案(最新推荐)

《Knife4j+Axios+Redis前后端分离架构下的API管理与会话方案(最新推荐)》本文主要介绍了Swagger与Knife4j的配置要点、前后端对接方法以及分布式Session实现原理,... 目录一、Swagger 与 Knife4j 的深度理解及配置要点Knife4j 配置关键要点1.Spri

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

MySQL之InnoDB存储引擎中的索引用法及说明

《MySQL之InnoDB存储引擎中的索引用法及说明》:本文主要介绍MySQL之InnoDB存储引擎中的索引用法及说明,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐... 目录1、背景2、准备3、正篇【1】存储用户记录的数据页【2】存储目录项记录的数据页【3】聚簇索引【4】二

MySQL中的表连接原理分析

《MySQL中的表连接原理分析》:本文主要介绍MySQL中的表连接原理分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1、背景2、环境3、表连接原理【1】驱动表和被驱动表【2】内连接【3】外连接【4编程】嵌套循环连接【5】join buffer4、总结1、背景

python中Hash使用场景分析

《python中Hash使用场景分析》Python的hash()函数用于获取对象哈希值,常用于字典和集合,不可变类型可哈希,可变类型不可,常见算法包括除法、乘法、平方取中和随机数哈希,各有优缺点,需根... 目录python中的 Hash除法哈希算法乘法哈希算法平方取中法随机数哈希算法小结在Python中,

Java Stream的distinct去重原理分析

《JavaStream的distinct去重原理分析》Javastream中的distinct方法用于去除流中的重复元素,它返回一个包含过滤后唯一元素的新流,该方法会根据元素的hashcode和eq... 目录一、distinct 的基础用法与核心特性二、distinct 的底层实现原理1. 顺序流中的去重

SpringBoot集成LiteFlow工作流引擎的完整指南

《SpringBoot集成LiteFlow工作流引擎的完整指南》LiteFlow作为一款国产轻量级规则引擎/流程引擎,以其零学习成本、高可扩展性和极致性能成为微服务架构下的理想选择,本文将详细讲解Sp... 目录一、LiteFlow核心优势二、SpringBoot集成实战三、高级特性应用1. 异步并行执行2

关于MyISAM和InnoDB对比分析

《关于MyISAM和InnoDB对比分析》:本文主要介绍关于MyISAM和InnoDB对比分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录开篇:从交通规则看存储引擎选择理解存储引擎的基本概念技术原理对比1. 事务支持:ACID的守护者2. 锁机制:并发控制的艺

HTML5 getUserMedia API网页录音实现指南示例小结

《HTML5getUserMediaAPI网页录音实现指南示例小结》本教程将指导你如何利用这一API,结合WebAudioAPI,实现网页录音功能,从获取音频流到处理和保存录音,整个过程将逐步... 目录1. html5 getUserMedia API简介1.1 API概念与历史1.2 功能与优势1.3