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

2023-12-07 04:15
文章标签 分析 引擎 api 设备 抽象 command filament

本文主要是介绍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。

相关文章

Nginx分布式部署流程分析

Nginx分布式部署流程分析

《Nginx分布式部署流程分析》文章介绍Nginx在分布式部署中的反向代理和负载均衡作用,用于分发请求、减轻服务器压力及解决session共享问题,涵盖配置方法、策略及Java项目应用,并提及分布式事... 目录分布式部署NginxJava中的代理代理分为正向代理和反向代理正向代理反向代理Nginx应用场景
阅读更多...
Redis中的有序集合zset从使用到原理分析

Redis中的有序集合zset从使用到原理分析

《Redis中的有序集合zset从使用到原理分析》Redis有序集合(zset)是字符串与分值的有序映射,通过跳跃表和哈希表结合实现高效有序性管理,适用于排行榜、延迟队列等场景,其时间复杂度低,内存占... 目录开篇：排行榜背后的秘密一、zset的基本使用1.1 常用命令1.2 Java客户端示例二、zse
阅读更多...
Redis中的AOF原理及分析

Redis中的AOF原理及分析

《Redis中的AOF原理及分析》Redis的AOF通过记录所有写操作命令实现持久化,支持always/everysec/no三种同步策略,重写机制优化文件体积,与RDB结合可平衡数据安全与恢复效率... 目录开篇：从日记本到AOF一、AOF的基本执行流程1. 命令执行与记录2. AOF重写机制二、AOF的
阅读更多...
MyBatis Plus大数据量查询慢原因分析及解决

MyBatis Plus大数据量查询慢原因分析及解决

《MyBatisPlus大数据量查询慢原因分析及解决》大数据量查询慢常因全表扫描、分页不当、索引缺失、内存占用高及ORM开销,优化措施包括分页查询、流式读取、SQL优化、批处理、多数据源、结果集二次... 目录大数据量查询慢的常见原因优化方案高级方案配置调优监控与诊断总结大数据量查询慢的常见原因MyBAT
阅读更多...
分析 Java Stream 的 peek使用实践与副作用处理方案

分析 Java Stream 的 peek使用实践与副作用处理方案

《分析JavaStream的peek使用实践与副作用处理方案》StreamAPI的peek操作是中间操作,用于观察元素但不终止流,其副作用风险包括线程安全、顺序混乱及性能问题,合理使用场景有限... 目录一、peek 操作的本质：有状态的中间操作二、副作用的定义与风险场景1. 并行流下的线程安全问题2. 顺
阅读更多...
MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决

MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决

《MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决》MyBatis默认开启一级缓存,同一事务中循环调用查询方法时会重复使用缓存数据,导致获取的序列主键值均为1,... 目录问题原因解决办法如果是存储过程总结问题myBATis有如下代码获取序列作为主键IdMappe
阅读更多...
使用Go调用第三方API的方法详解

使用Go调用第三方API的方法详解

《使用Go调用第三方API的方法详解》在现代应用开发中,调用第三方API是非常常见的场景,比如获取天气预报、翻译文本、发送短信等,Go作为一门高效并发的编程语言,拥有强大的标准库和丰富的第三方库,可以... 目录引言一、准备工作二、案例1：调用天气查询 API1. 注册并获取 API Key2. 代码实现3
阅读更多...
Java中最全最基础的IO流概述和简介案例分析

Java中最全最基础的IO流概述和简介案例分析

《Java中最全最基础的IO流概述和简介案例分析》JavaIO流用于程序与外部设备的数据交互,分为字节流（InputStream/OutputStream）和字符流（Reader/Writer）,处理... 目录IO流简介IO是什么应用场景IO流的分类流的超类类型字节文件流应用简介核心API文件输出流应用文
阅读更多...
录音功能在哪里? 电脑手机等设备打开录音功能的技巧

录音功能在哪里? 电脑手机等设备打开录音功能的技巧

《录音功能在哪里?电脑手机等设备打开录音功能的技巧》很多时候我们需要使用录音功能，电脑和手机这些常用设备怎么使用录音功能呢？下面我们就来看看详细的教程... 我们在会议讨论、采访记录、课堂学习、灵感创作、法律取证、重要对话时，都可能有录音需求，便于留存关键信息。下面分享一下如何在电脑端和手机端上找到录音功能
阅读更多...
PHP应用中处理限流和API节流的最佳实践

PHP应用中处理限流和API节流的最佳实践

《PHP应用中处理限流和API节流的最佳实践》限流和API节流对于确保Web应用程序的可靠性、安全性和可扩展性至关重要,本文将详细介绍PHP应用中处理限流和API节流的最佳实践,下面就来和小编一起学习... 目录限流的重要性在 php 中实施限流的最佳实践使用集中式存储进行状态管理（如 Redis）采用滑动
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2