欢迎来到皮皮网网首页

【php源码啥意思】【七七口诀指标源码】【商品行情 源码】随笔网站源码_写随笔的网站

来源:棋牌提现源码 时间:2024-12-24 04:24:14

1.[技术随笔]🛠🛠从源码安装Pytorch3D详细记录及学习资料
2.vn.py学习笔记(八)vn.py utility、随笔BarGenerator、网站网站ArrayManager源码阅读
3.游戏引擎随笔 0x29:UE5 Lumen 源码解析(一)原理篇
4.游戏引擎随笔 0x20:UE5 Nanite 源码解析之渲染篇:BVH 与 Cluster 的源码 Culling
5.游戏引擎随笔 0x36:UE5.x Nanite 源码解析之可编程光栅化(下)

随笔网站源码_写随笔的网站

[技术随笔]🛠🛠从源码安装Pytorch3D详细记录及学习资料

       这篇文章详细介绍了如何从源码安装Pytorch3D,包括选择合适的写随镜像、配置工具和编译步骤。随笔首先,网站网站php源码啥意思选择Pytorch 1.9的源码devel镜像,包含CUDA和驱动,写随确保与Pytorch3D的随笔版本要求相匹配,比如Python 3.7和CUDA .2。网站网站在镜像内,源码需要检查nvcc编译器、写随CUDA工具箱和驱动是随笔否正常,同时安装基本工具如git、网站网站vim、源码sudo和curl。

       配置CUB工具是关键步骤,根据Pytorch3D文档,需要在编译前设置CUB_HOME。即使Pytorch镜像自带CUDA,也建议手动设置`FORCE_CUDA`为1以确保兼容。接着,如果遇到conda依赖问题,作者选择从源码编译Pytorch3D,编译过程中的安装log和版本检查是必要的。

       最后,通过测试用例,如从ARkit导出数据并渲染白模,验证GPU的使用。结果显示GPU正常工作,安装成功。对于更深入的Pytorch3D使用,作者还分享了一些参考资源,以便初学者入门。

vn.py学习笔记(八)vn.py utility、BarGenerator、ArrayManager源码阅读

       在量化投资的探索中,作者对vn.py产生了浓厚的兴趣,并投身于相关学习。目前,作者主要专注于vn.py在A股市场量化策略的学习,面临的主要技术难点包括获取和维持日线数据、实现自动下单交易、七七口诀指标源码开发全市场选股程序、编写选股策略回测程序,以及运用机器学习进行股票趋势预测。作者计划通过阅读vn.py源码,深入了解其架构机制,并通过分享形式记录学习心得,以便更好地理解vn.py。

       相关github仓库地址:github.com/PanAndy/quan...

       如有收获,请关注公众号以支持作者。同时,作者也收集了一些量化投资和技术相关的视频及书籍资源,欢迎关注公众号亚里随笔获取。

       本文将重点探讨vn.py/trader/utility.py中的内容,主要包括工具函数、BarGenerator和ArrayManager。工具函数部分相对容易理解,主要是对通用功能进行封装。BarGenerator是K线合成器,负责根据实时tick数据合成1分钟K线,并进一步合成n分钟K线。ArrayManager是指标计算辅助类,负责维护一定量的历史数据,以供计算sma、ema、atr等常见指标。BarGenerator和ArrayManager是本次学习的重点。

       工具函数部分主要提供合约代码转换、路径读取、json文件读写、数值位数设置、日志等功能,主要是对基本功能进行封装,没有复杂的算法。

       BarGenerator类用于从tick数据中生成1分钟bar数据,也可以用于从1分钟的bar数据中合成x分钟或x小时的bar。BarGenerator的主要函数包括update_tick、update_bar、update_bar_minute_window、update_bar_hour_window、on_hour_bar和generate。

       ArrayManager是一个时间序列容器,用于按时间序列缓存bar数据,商品行情 源码提供技术指标的计算。ArrayManager提供的函数分为四类:init函数、update_bar、@property函数和技术指标函数。

游戏引擎随笔 0x:UE5 Lumen 源码解析(一)原理篇

       实时全局光照的追求一直是图形渲染界的焦点。随着GPU硬件光线追踪技术的兴起,Epic Games的Unreal Engine 5推出了Lumen,一个结合SDF、Voxel Lighting、Radiosity等技术的软件光线追踪系统。Lumen的实现极其复杂,涉及个Pass,近5.6万行C++代码和2万行Shader,与Nanite、Virtual Shadow Map等系统紧密集成,并支持混合使用硬件和软件光线追踪。

       本系列将逐步解析Lumen,从原理入手。Lumen以简化间接光照(主要由漫反射构成)为核心,采用Monte Carlo积分方法估算,利用Ray Tracing获取Radiance,生成Irradiance,最终得到光照值。它的核心是Radiance的计算、缓存和查询,以及这些操作的高效整合。

       数学原理上,Lumen依赖渲染方程,通过离散采样近似无限积分。它主要处理Diffuse部分,利用Lambert Diffuse和Ray Tracing获取Radiance。加速结构方面,Lumen利用SDF Ray Marching在无需硬件支持的情况下实现高效的SWRT。

       Surface Cache是关键技术,通过预生成的低分辨率材质属性图集,高效获取Hit Point的Material Attribute,结合SDF Tracing,为Lumen提供了实时性能。Radiance Cache则是将Direct Lighting结果保存,便于后续的光照计算和全局光照的无限反弹。

       Lumen构建了一个由DF和Surface Cache构成的低精度场景表示,即Lumen Scene,苏州分销软件源码负责Mesh DF更新、Global DF合并和Surface Cache更新。通过Screen Space Probe的自适应放置,Lumen实现了高效的光照追踪和降噪处理。

       总体流程包括Lumen Scene更新、Lighting计算和Final Gather,涉及众多数据流和过程,通过3D Texture和Spatial Filtering进行降噪和Light Scattering的处理。后续篇章将深入源码,以更详细的方式揭示Lumen的实现细节和优化策略。

游戏引擎随笔 0x:UE5 Nanite 源码解析之渲染篇:BVH 与 Cluster 的 Culling

       在UE5 Nanite的渲染深度中,一个关键组件是其独特的剔除策略,特别是通过高效的BVH(Bounded Volume Hierarchy)和Cluster Culling技术。Nanite的目标在于智能地控制GPU资源,避免不必要的三角形绘制,确保每一点计算都被最大化利用。

       首先,Nanite的渲染流程中,异步数据传输和GPU初始化完成后,进入CullRasterize阶段,其中的PersistentCulling pass至关重要。它分为两个步骤: BVH Node Culling 和 Cluster Culling,每个阶段都利用多线程并行处理,实现了GPU性能的极致发挥。

       在Node Culling中,每个线程处理8个节点,通过Packed Node数据结构,确保数据的一致性和同步性。每组个线程间通过MPMC Job Queue协同工作,保证了负载均衡,避免了GPU资源的浪费。GroupNodeMask和NodeReadyMask等优化策略,确保了节点处理的高效性和准确性。

       核心部分是TGS GroupNodeData,它接收并处理来自候选节点的Packed Node,进行实例数据、动态数据和BVH节点数据的整合。通过Frustum Culling,仅保留可见的节点,非叶节点的计数更新和候选Cluster的生成,都在这个过程中完成。

       叶节点的什么是手机源码Cluster Culling更为精细,通过计算Screen Rect,判断是否适合渲染。当遇到硬件光栅化需求时,Nanite会利用上一帧的LocalToClip矩阵进行HZB遮挡剔除,确保每个Cluster的可见性和正确性。

       在硬件光栅化中,VisibleClusterOffset的计算和Cluster的有序写入,体现了UE5团队对性能的精心调教。而软光栅化则采取相反的存储策略,确保了渲染的高效执行。

       尽管Nanite在百万面模型处理上展现出惊人的0.5ms速度,但它并非无懈可击,如不支持Forward Rendering。然而,随着UE5技术的不断迭代,Nanite的潜力和优化空间将继续扩展,推动着游戏开发的创新边界。

       总之,UE5 Nanite的渲染篇是技术与艺术的完美融合,通过深度剖析其渲染流程,我们不仅能领略到高效剔除策略的魅力,更能感受到Unreal团队在性能优化上的匠心独运。深入源码,解锁游戏引擎的内在魔力,让我们一起期待Nanite在未来的更多可能。

游戏引擎随笔 0x:UE5.x Nanite 源码解析之可编程光栅化(下)

       书接上回。

       在展开正题之前,先做必要的铺垫,解释纳尼特(Nanite)技术方案中的Vertex Reuse Batch。纳尼特在软光栅路径实现机制中,将每个Cluster对应一组线程执行软光栅,每ThreadGroup有个线程。在光栅化三角形时访问三角形顶点数据,但顶点索引范围可能覆盖整个Cluster的个顶点,因此需要在光栅化前完成Cluster顶点变换。纳尼特将变换后的顶点存储于Local Shared Memory(LDS)中,进行组内线程同步,确保所有顶点变换完成,光栅化计算时直接访问LDS,实现软光栅高性能。

       然而,在使用PDO(Masked)等像素可编程光栅化时,纳尼特遇到了性能问题。启用PDO或Mask时,可能需要读取Texture,根据读取的Texel决定像素光栅化深度或是否被Discard。读取纹理需计算uv坐标,而uv又需同时计算重心坐标,增加指令数量,降低寄存器使用效率,影响Active Warps数量,降低延迟隐藏能力,导致整体性能下降。复杂材质指令进一步加剧问题。

       此外,当Cluster包含多种材质时,同一Cluster中的三角形被重复光栅化多次,尤其是材质仅覆盖少数三角形时,大量线程闲置,浪费GPU计算资源。

       为解决这些问题,纳尼特引入基于GPU SIMT/SIMD的Vertex Reuse Batch技术。技术思路如下:将每个Material对应的三角形再次分为每个为一组的Batch,每Batch对应一组线程,每个ThreadGroup有个线程,正好对应一个GPU Warp。利用Wave指令共享所有线程中的变换后的顶点数据,无需LDS,减少寄存器数量,增加Warp占用率,提升整体性能。

       Vertex Reuse Batch技术的启用条件由Shader中的NANITE_VERT_REUSE_BATCH宏控制。

       预处理阶段,纳尼特在离线时构建Vertex Reuse Batch,核心逻辑在NaniteEncode.cpp中的BuildVertReuseBatches函数。通过遍历Material Range,统计唯一顶点数和三角形数,达到顶点去重和优化性能的目标。

       最终,数据被写入FPackedCluster,根据材质数量选择直接或通过ClusterPageData存储Batch信息。Batch数据的Pack策略确保数据对齐和高效存储。

       理解Vertex Reuse Batch后,再来回顾Rasterizer Binning的数据:RasterizerBinData和RasterizerBinHeaders。在启用Vertex Reuse Batch时,这两者包含的是Batch相关数据,Visible Index实际指的是Batch Index,而Triangle Range则对应Batch的三角形数量。

       当Cluster不超过3个材质时,直接从FPackedCluster中的VertReuseBatchInfo成员读取每个材质对应的BatchCount。有了BatchCount,即可遍历所有Batch获取对应的三角形数量。在Binning阶段的ExportRasterizerBin函数中,根据启用Vertex Reuse Batch的条件调整BatchCount,表示一个Cluster对应一个Batch。

       接下来,遍历所有Batch并将其对应的Cluster Index、Triangle Range依次写入到RasterizerBinData Buffer中。启用Vertex Reuse Batch时,通过DecodeVertReuseBatchInfo函数获取Batch对应的三角形数量。对于不超过3个材质的Cluster,DecodeVertReuseBatchInfo直接从Cluster的VertReuseBatchInfo中Unpack出Batch数据,否则从ClusterPageData中根据Batch Offset读取数据。

       在Binning阶段的AllocateRasterizerBinCluster中,还会填充Indirect Argument Buffer,将当前Cluster的Batch Count累加,用于硬件光栅化Indirect Draw的Instance参数以及软件光栅化Indirect Dispatch的ThreadGroup参数。这标志着接下来的光栅化Pass中,每个Instance和ThreadGroup对应一个Batch,以Batch为光栅化基本单位。

       终于来到了正题:光栅化。本文主要解析启用Vertex Reuse Batch时的软光栅源码,硬件光栅化与之差异不大,此处略过。此外,本文重点解析启用Vertex Reuse Batch时的光栅化源码,对于未启用部分,除可编程光栅化外,与原有固定光栅化版本差异不大,不再详细解释。

       CPU端针对硬/软光栅路径的Pass,分别遍历所有Raster Bin进行Indirect Draw/Dispatch。由于Binning阶段GPU中已准备好Draw/Dispatch参数,因此在Indirect Draw/Dispatch时只需设置每个Raster Bin对应的Argument Offset即可。

       由于可编程光栅化与材质耦合,导致每个Raster Bin对应的Shader不同,因此每个Raster Bin都需要设置各自的PSO。对于不使用可编程光栅化的Nanite Cluster,即固定光栅化,为不降低原有性能,在Shader中通过两个宏隔绝可编程和固定光栅化的执行路径。

       此外,Shader中还包括NANITE_VERT_REUSE_BATCH宏,实现软/硬光栅路径、Compute Pipeline、Graphics Pipeline、Mesh Shader、Primitive Shader与材质结合生成对应的Permutation。这部分代码冗长繁琐,不再详细列出讲解,建议自行阅读源码。

       GPU端软光栅入口函数依旧是MicropolyRasterize,线程组数量则根据是否启用Vertex Reuse Batch决定。

       首先判断是否使用Rasterizer Binning渲染标记,启用时根据VisibleIndex从Binning阶段生成的RasterizerBinHeaders和RasterizerBinData Buffer中获取对应的Cluster Index和光栅化三角形的起始范围。当启用Vertex Reuse Batch,这个范围是Batch而非Cluster对应的范围。

       在软光栅中,每线程计算任务分为三步。第一步利用Wave指令共享所有线程中的Vertex Attribute,线程数设置为Warp的Size,目前为,每个Lane变换一个顶点,最多变换个顶点。由于三角形往往共用顶点,直接根据LaneID访问顶点可能重复,为确保每个Warp中的每个Lane处理唯一的顶点,需要去重并返回当前Lane需要处理的唯一顶点索引,通过DeduplicateVertIndexes函数实现。同时返回当前Lane对应的三角形顶点索引,用于三角形设置和光栅化步骤。

       获得唯一顶点索引后,进行三角形设置。这里代码与之前基本一致,只是写成模板函数,将Sub Pixel放大倍数SubpixelSamples和是否背面剔除bBackFaceCull作为模板参数,通过使用HLSL 语法实现。

       最后是光栅化三角形写入像素。在Virtual Shadow Map等支持Nanite的场景下,定义模板结构TNaniteWritePixel来实现不同应用环境下Nanite光栅化Pipeline的细微差异。

       在ENABLE_EARLY_Z_TEST宏定义时,调用EarlyDepthTest函数提前剔除像素,减少后续重心坐标计算开销。当启用NANITE_PIXEL_PROGRAMMABLE宏时,可以使用此机制提前剔除像素。

       最后重点解析前面提到的DeduplicateVertIndexes函数。

       DeduplicateVertIndexes函数给每个Lane返回唯一的顶点索引,同时给当前Lane分配三角形顶点索引以及去重后的顶点数量。

       首先通过DecodeTriangleIndices获取Cluster Local的三角形顶点索引,启用Cluster约束时获取所有Lane中最小的顶点索引,即顶点基索引。将当前三角形顶点索引(Cluster Local)减去顶点基索引,得到相对顶点基索引的局部顶点索引。

       接下来生成顶点标志位集合。遍历三角形三个顶点,将局部顶点索引按顺序设置到对应位,表示哪些顶点已被使用。每个标志位是顶点的索引,并在已使用的顶点位置处设置为1。使用uint2数据类型,最多表示个顶点位。

       考虑Cluster最多有个顶点,为何使用位uint2来保存Vertex Mask而非位?这是由于Nanite在Build时启用了约束机制(宏NANITE_USE_CONSTRAINED_CLUSTERS),该机制保证了Cluster中的三角形顶点索引与当前最大值之差必然小于(宏CONSTRAINED_CLUSTER_CACHE_SIZE),因此,生成的Triangle Batch第一个索引与当前最大值之差将不小于,并且每个Batch最多有个唯一顶点,顶点索引差的最大值为,仅需2个位数据即可。约束机制确保使用更少数据和计算。

       将所有Lane所标记三个顶点的Vertex Mask进行位合并,得到当前Wave所有顶点位掩码。通过FindNthSetBit函数找出当前Lane对应的Mask索引,加上顶点基索引得到当前Lane对应的Cluster Local顶点索引。

       接下来获取当前Lane对应的三角形的Wave Local的三个顶点索引,用于后续通过Wave指令访问其他Lane中已经计算完成的顶点属性。通过MaskedBitCount函数根据Vertex Mask以及前面局部顶点索引通过前缀求和得到当前Lane对应的Vertex Wave Local Index。

       最后统计Vertex Mask所有位,返回总计有效的顶点数量。

       注意FindNthSetBit函数,实现Lane与顶点局部索引(减去顶点基索引)的映射,返回当前Lane对应的Vertex Mask中被设置为1的位索引。如果某位为0,则返回下一个位为1的索引。如果Mask中全部位都设置为1,则实际返回为Lane索引。通过二分法逐渐缩小寻找索引范围,不断更新所在位置,最后返回找到的位置索引。

       最后,出于验证目的进行了Vertex Reuse Batch的性能测试。在材质包含WPO、PDO或Mask时关闭Vertex Reuse Batch功能,与开启功能做对比。测试场景为由每颗万个三角形的树木组成的森林,使用Nsight Graphics进行Profiling,得到GPU统计数据如下:

       启用Vertex Reuse Batch后,软光栅总计耗时减少了1.毫秒。SM Warp总占用率有一定提升。SM内部工作量分布更加均匀,SM Launch的总Warp数量提升了一倍。长短板Stall略有增加,但由于完全消除了由于LDS同步导致的Barrier Stall,总体性能还是有很大幅度的提升。

       至此,Nanite可编程光栅化源码解析讲解完毕。回顾整个解析过程,可以发现UE5团队并未使用什么高深的黑科技,而是依靠引擎开发者强悍的工程实现能力完成的,尤其是在充分利用GPU SIMT/SIMD机制榨干机能的同时,保证了功能与极限性能的实现。这种能力和精神,都很值得我们学习。