新增功能Katana 3.5

介绍

本文档介绍了引入的显着更改Katana 3.5。这些更改包括：

• Geolib3-MT：这是Geolib3的演变- Katana的场景图处理引擎-提供本机多线程场景图扩展。Geolib3-MT项目的目标是：
  • 充分利用现代多核系统上的可用资源。
  • 提供共享的智能缓存技术，以便在遍历场景图时更好地管理内存资源。
  • 为了减少到达第一像素的时间（TTFP），允许艺术家有效地迭代拍摄并及时收到反馈。
  • 通过改善UI性能来提高艺术家的工作效率。
• 提供了分析和分析工具，可帮助用户调试给定时间中最耗时的操作Katana会议。
• 优化了关键工作流程，提高了创建大量位置的场景的性能。
• 现在，我们基于USD 19.11构建和交付USD插件，包括经过一些细微改动的USD节点类型，作为插件/资源/美元/作为一个目录的一部分Katana安装。有关如何选择使用美元插件的文档已添加到Katana新版开发人员指南编写插件> Katana USD插件部分。该部分还概述了现在随附的USD插件之间的区别Katana从Pixar USD存储库中发货的产品中提取。
• 实验性的“监控层”功能现已集成到查看器（九头蛇）标签，可以通过切换按钮，切换的菜单项或键盘快捷键（`）来打开和关闭。使用“监视层”，您可以查看覆盖在查看器中显示的场景上的渲染。
• 一个新的命令行选项： --reuse-render-process已添加。跑步时Katana在启用此选项的批处理模式下，将使用托管渲染插件的renderboot的单个实例来渲染多个帧，而不是为每个帧启动新的renderboot进程。使用此选项可以极大地提高帧的渲染序列的性能，因为渲染插件和所有其他Katana插件不必每帧都重新加载。

Geolib3-MT运行时

Katana节点图，其操作树和随后创建的场景非常灵活且变化多端。为了最佳地评估这些场景，评估引擎必须既高效又灵活，足以处理可能使用的场景的多样性和复杂性Katana。Geolib3-MT，下一代Katana场景图处理引擎比Geolib3的早期版本提供了更大程度的配置，自省和调整选项，可以满足日益复杂和变化的工作负载的需求。在本节中，我们将探讨其中的一些选项，以及如何利用它们来改善场景遍历性能。

组态

可以通过RenderSettings节点配置Geolib3-MT。所有Geolib3-MT选项都位于场景标题。

sceneTraversal.maxCores

确定场景遍历阶段将使用Geolib3-MT多少逻辑核心。与以前的版本不同，Geolib3-MT使用内部线程池来缩短场景遍历时间。下图演示了Geolib3-MT与以前版本的Katana。

注意：默认值（0）使Geolib3-MT使用主机上的所有可用逻辑核心。虽然核心Geolib3-MT处理引擎可以很好地缩放，但是随着核心数量的增加，运算树中的各个运算可能不会显示出相同的缩放特性。因此，线程数增加可能会导致场景遍历时间增加（而不是减少）。在这种情况下，可以使用新的配置工具Katana 3.5可用于识别这些操作并重构/优化其行为。标记为“线程不安全”的Ops也是如此，因为这些操作需要获取全局执行锁（GEL），这进一步限制了场景遍历的可伸缩性。

sceneTraversal.opTreeOptimizations

Geolib3-MT可以执行预处理步骤，在该步骤中，它会检查Op树的拓扑结构，以识别可以潜在优化的构造。一种这样的优化是将相同类型的Op序列折叠为该Op的单个实例。这有很多好处，

• 减少的函数调用开销-安排Op来烹饪场景图位置会涉及少量成本。通过组合类似Ops的链，可以减少此函数调用的开销。
• 减少的内存占用-缓存子系统中的10个操作链将占据10个单独的烹饪结果，一个成功折叠的操作链将每个位置仅占据1个烹饪结果。

注意：行动树优化阶段是一项实验性功能，因此默认情况下处于关闭状态。可以通过RenderSettings节点上的sceneTraversal.opTreeOptimizaions选项将其打开。

更多信息

如果调用，Op树优化器将尝试折叠任何相同类型的Ops链GeolibSetupInterface :: setOpsCollapsible（）在此期间设定（） 呼叫。该函数的调用者必须指定Geolib3传递给Op的属性的名称厨师（）作为Op参数调用。该属性将包含一个属性的有序数组（从上游Op到下游Op的顺序），其中包含折叠的Ops的参数。然后，Op可以适当地处理此“批处理” Op参数。

sceneTraversal.verboseLogging

为了避免大量信息性消息填充渲染日志，默认情况下，Geolib3-MT不记录与性能相关的消息。这些消息可以通过打开sceneTraversal.verboseLogging RenderSettings节点上的选项。当前，这些消息包括有关以下信息：

• 如果启用，则Op树优化器无法应用的优化。
• 缓存逐出后，缓存子系统使用的内存。

sceneTraversal.cache组

Geolib3-MT包含许多设置来控制缓存子系统的行为。缓存子系统负责存储和检索先前烹饪的场景图位置，称为“烹饪结果”。这些设置可以从RenderSettings节点逐个项目地进行修改。根据针对生产规模场景的测试，提供了合理的默认值。下面提供了有关每个设置的更多信息，

• sceneTraversal.cache.cacheEviction -默认情况下处于启用状态。如果关闭，则不会从缓存中清除任何烹饪结果。最初，关闭缓存逐出似乎是违反直觉的，但是在某些情况下，这是适当的。特别是当渲染器所需的场景大小和数据结构可以舒适地适合内存时；甚至更大的场景也可以在某种程度上受益，因为一旦渲染的场景生成阶段完成，将不再访问Geolib3-MT的烹饪结果所占用的内存页面，因此有资格分页到磁盘，因为这些页面将不再在渲染期间重新分页到主内存的性能损失最小。
• sceneTraversal.cache.cacheSoftLimit -如果启用了缓存逐出，则软限制将控制在使用最近最少使用的逐出策略逐出条目之前，将多少个烹饪结果存储在本地缓存中。注意：虽然这些条目可能是从本地缓存中逐出的，但它们可能在许多其他本地缓存或中央（共享缓存）中共享。在这种情况下，条目的内存将不会立即被回收。
• sceneTraversal.cache.collectionFrequency -如果打开了缓存逐出，则收集频率将控制收集周期之间的时间（以毫秒为单位）。在收集周期中，Geolib3-MT将收集自上一个收集周期以来逐出的所有缓存条目，如果不再使用烹饪结果，则逐出并回收该烹饪结果的内存。

更多信息

缓存以及到第一个像素的内存使用量和时间之间的折衷可能会对场景遍历时间和渲染的性能产生重大影响。使用Geolib3-MT提供的设置，可以在渲染的场景遍历阶段调整内存占用量。在决定尝试这些场景时，有一些注意事项，

• 考虑场景图和操作树的最大深度-缓存软限制按每个线程控制最近使用的烹饪结果的大小。这意味着在特定线程上进行烹饪的任何位置，或在烹饪过程中访问的任何位置（例如通过getAttr（））将存储在本地缓存中，并根据以下值逐出sceneTraversal.cache.cacheSoftLimit。
• 减少收集频率间隔将导致更积极地驱逐烹饪结果，从而减少内存占用，但可能会以场景遍历时间为代价。

sceneTraversal.useCachePrepopulation

如果打开，Geolib3-MT将遍历填充内部缓存的场景图。遍历的程度可以通过以下设置进行控制sceneTraversal.cachePrepopulation并在下面说明，

• sceneTraversal.cachePrepopulation.preCookSourceOps -默认情况下处于关闭状态，如果启用，则Geolib3-MT将首先完全遍历Op树中找到的任何源Op生成的场景。源Op被分类为没有输入的任何Op。当加载几何缓存或其他资产类型时，此设置可以带来好处。经验测试发现，在源Ops之后通常进行某种形式的修剪操作，结果，在这些情况下，预烹饪源Op可能会生成比所需场景更多的场景图位置，这可能会导致内存消耗和遍历时间增加。
• sceneTraversal.cachePrepopulation.preCookKeyOps -默认情况下处于启用状态，Geolib3-MT将在Op树中标识可以并行评估的Op。一个明显的例子是合并操作，在这种情况下，Geolib3-MT将并行评估每个分支，从而可以减少场景遍历时间。
• sceneTraversal.cachePrepopulation.preCookAllLocations -默认情况下处于启用状态，Geolib3-MT将烹饪所有剩余的场景图位置，从而完全扩展场景。

根据上述设置的值，在缓存预填充阶段完成后，Geolib3-MT缓存将被预填充整个场景图或其一部分。Geolib3-MT已经过优化，可以通过现有工具高效访问渲染器插件FnScenegraphIterator此缓存的API。此缓存是可伸缩的线程安全缓存，因此，我们鼓励渲染器插件编写器同时访问此缓存，以提高场景构建阶段的性能。

注意：如果未完全填充Geolib3-MT缓存，请通过以下方式访问缓存： FnScenegraphIterator）将导致缓存未命中。在这种情况下，将使用调用线程来烹调请求的位置。

API改进

扩展了各种API以改善性能和内存管理

• GeolibRuntime :: finalize（）和FnScenegraphIterator :: finalizeRuntime（） 渲染器插件使用的方法-通常，遍历场景后，渲染器插件现在可以明确声明不再需要Geolib3 Runtime。运行时将清除内存，并停止进一步的计算。
• FnAttribute :: getSize（） -此函数返回为特定属性动态分配的内存的大小。对于组属性，大小表示所有子属性的大小之和，以及子名称的长度。如果组属性包含相同属性实例的重复引用，则该属性的大小将与组中出现的次数一样多。
• AttributeKeyedCache包含线程有效的替代方法。模板类已根据TBB的并发哈希图重新实现。没有TBB的用户仍然可以通过定义以下内容使用互斥的版本ATTRIBUTEKEYEDCACHE_NO_TBB包括头文件之前。
• GeolibSetupInterface :: setOpsCollapsible（）。如果设置，则向Geolib3-MT指示此类型的Op支持折叠。在未来的版本中，Geolib3-MT将使用此信息来识别类似Ops的链并将其折叠为一个厨师（）呼叫。
• kFnKatGeolibThreadModeGlobalUnsafe已不推荐使用。所有操作都应该是线程安全的或实现自己的内部锁定。

• 一些名为的新功能setup（），cleanup（） 和 setRootIterator（）已添加到渲染库渲染器插件中的类plugin_apis / include / FnRender / plugin / RenderBase.h标头。这些使渲染插件可以在单个实例中渲染多个框架，而不是为每个帧创建该插件的新实例。

分析和分析工具

Geolib3-MT分析

Geolib3-MT添加了一个新的渲染类型，称为使用性能分析预览渲染，旨在帮助跟踪场景遍历中的性能问题。这将执行正常的预览渲染，但还会捕获有关运行了哪些Ops，它们用来烹饪位置的CPU数量以及用于属性和Lua脚本的内存数量的信息。

带有分析的预览渲染器在两个位置输出分析数据：

• 渲染日志中的摘要报告，包含总的CPU时间和使用的内存以及10个最昂贵的操作。
• 写入磁盘的JSON文件，包含原始分析数据，如下所述。

使用性能分析启动预览渲染

可以选择与其他任何渲染相同的菜单来启动带有性能分析的预览渲染。 使用性能分析预览渲染命令。

此选项可用于任何已经支持预览渲染的渲染器，并且在渲染器方面不需要任何额外的工作。如果渲染器实现了finalize（） Geolib3-MT Runtime的方法，这些分析报告将在运行时完成时创建；否则，报告将在渲染完成时写入。

捕获什么信息？

Op的名称，类型和数字ID。每个Op都有名称，类型和唯一的数字ID。例如，一个OpScript Op可能具有名称op74，类型OpScript.Lua和ID 77。请注意，名称和ID不需要关联。

的名称和类型Katana产生Op的节点。如果操作是由操作员直接生成的Katana节点，记录该节点的名称和类型。在隐式创建Op的情况下，节点名称将等于_无名_并且类型将等于 _NoType_。例如，这种情况发生在MaterialFilenameResolve操作：这些操作是在需要解析文件名时隐式创建的，因此不需要Katana节点被标识为创建者。

注意：如果sceneTraversal.opTreeOptimizations打开，操作链折叠，节点名称和类型将替换为从链中生成的字符串。如果链长Ť，由类型的Ops组成opType，其中Op ķ被称为 Ø_ķ并由Katana节点名为ñ_一世，字符串的一般形式为：

警察₀（n₀）-> o₁（n₁）-> ...-> o_Ť（n_Ť））

但是请注意，不能保证此字符串的格式保持固定。

Op在烹饪位置上花费的总CPU时间。每个操作员都会在很多地方做饭，并且花费在所有场景遍历线程上的时间会累积起来。因此，并行遍历场景时，CPU时间应随场景遍历线程数而定。如果不是这种情况，则可能在所讨论的Op上游存在线程不安全的Op。

该Op的内存占用量。每个Op必须分配内存来烹饪位置，并且每个Op的总内存是聚合的。当前，仅记录以下分配：

• 由FnAttribute库进行的分配，用于存储煮熟位置的属性；
• Lua解释器在执行OpScript时进行的分配；和
• 用于将CookResults存储在缓存中的分配。

分析摘要报告

带有概要分析的预览渲染完成后，摘要报告将写入渲染日志。该报告旨在提供概要文件数据的高级概述，并包含：

• 所有操作的总CPU时间；
• 所有操作的总内存占用；和
• CPU时间最慢的五个操作。

示例渲染日志的相关部分如下所示：

分析JSON文件

除了摘要报告之外，还将包含原始概要分析数据的JSON文件写入磁盘。写入的目录由--profiling-dir命令行选项；如果未设置，它将被写入到临时目录中。 Katana会议。如果此目录不存在，则会创建它（如果允许文件系统权限）。文件名采用以下格式：

profile_ <renderer> _previewRender_ <datetime> .json

• <渲染器>是渲染插件的名称，例如dl为3Delight;
• <日期时间>是渲染开始时的ISO8601时间戳。

该文件包含一个具有以下属性的JSON对象：

{“ KATANA_RELEASE”：“ 3.5v1”，“ KATANA_ROOT”：/ opt / foundry / katana3.5”，“ KATANA_RESOURCES”：“ <unset>”）}

的行动属性包含以下格式的对象数组，一个用于场景遍历期间执行的每个Op。

• 用于Op树调试的命令行工具 -一种新的命令行工具， 场景漫步者可用于协助Op的开发，场景调试和性能分析。场景漫步者可以配置为使用可配置数量的核心遍历Op树，或仅遍历特定位置并从场景图中输出原始属性数据。

实验功能

• 环境变量KATANA_EXPERIMENTAL_MONITOR_OVERLAY不再使用。现在，“监控层”功能是查看器（九头蛇）标签，可以通过切换按钮，切换的菜单项或键盘快捷键（`）。

在批处理渲染中重用渲染过程

• 一种优化启动的新模式渲染启动宿主渲染插件的进程已添加到Katana的批处理模式，可以通过传递新的--reuse-render-process命令行选项Katana可执行文件（除 - 批量）。跑步时Katana在启用此选项的批处理模式下，将使用单个实例渲染多个帧渲染启动托管渲染插件，而不是启动新的渲染启动每帧的处理。使用此选项可以极大地提高帧的渲染序列的性能，因为渲染插件和所有其他Katana插件不必每帧都重新加载。

  注意：渲染插件必须针对Katana 3.5v1渲染API为了支持--reuse-render-process批处理模式下的命令行选项。

• 一些名为的新功能setup（），cleanup（） 和 setRootIterator（）已添加到渲染库渲染器插件中的类plugin_apis / include / FnRender / plugin / RenderBase.h标头。这些使渲染插件可以在单个实例中渲染多个框架，而不是为每个帧创建该插件的新实例。

其他显着的功能增强

• TP 55592 / BZ 27736-新-V / -详细用于控制日志信息性消息的详细程度的命令行选项已添加到Katana可执行文件：

   -V LEVEL，--verbose = LEVEL记录信息性消息的详细程度。默认为1。设置为0可禁止显示大多数信息性消息。

• TP 280477-现在可以复制选定项目的文本表示形式延迟组树中的小部件属性标签到剪贴板。此类小部件用于，例如， lightList的群组属性/ root / world而对于材质节点上的群组属性材料代表网络资料的位置。