PSO首次使用卡顿

一个特效第一次出现时卡一下，再出现就正常，可能是资源加载，也可能是管线创建触发了驱动编译。PSO 调查把首次请求、编译完成与首次绘制分开记录，再判断缓存缺失、预热过晚还是组合覆盖不足。机制与缓存键见 Pipeline State Object。

卡顿证据与缓存层次

同一着色器配上不同附件格式、样本数或顶点布局，会形成不同的完整管线状态。只预热材质名称无法证明这些组合都已准备。驱动还可能在创建或首次使用时完成设备相关工作，因此“着色器字节码已经打包”也不是无卡顿保证。

缓存要分层观察：

冷启动需要建立哪些层，决定启动工作量；热缓存只减少相应层的工作，不保证取用耗时为零。发布新着色器、修改状态或升级驱动，都可能再次触发准备。测试报告应写清清除了应用列表、驱动缓存还是内存对象，避免把不同条件都叫作“清缓存”。

组合收集与覆盖

运行记录捕获实际遇到的组合，适合沿功能用例、角色、特效、画质和渲染路径建立覆盖集合。收集路线需要触发低频材质、不同阴影通道和附件设置；只是走遍地图，未必触发全部组合。把组合键与首次出现的内容事件一起记录，才能补出缺失用例。

构建阶段把记录与稳定着色器身份合并，再生成目标平台可读的列表。稳定身份解决源码变化后的映射问题，实际工具参数与文件格式由锁定的引擎版本决定。日志至少保留原构建、目标平台、质量档位、记录数量、去重数量和无法映射的键。失去对应着色器的旧条目应明确丢弃或报错，不能继续当成有效覆盖。

准备过程本身会改变线程负载和缓存状态。收集运行用于发现组合，计时运行使用冻结列表并关闭记录，再按同一路线测量首次使用尖峰。

提前准备与加载边界

运行时可以从即将加载的材质、顶点工厂和组件状态推导候选组合。候选准备得足够早，编译就有机会与其他加载工作重叠；准备过晚，首次绘制仍要等待。自动推导与运行记录可以共同使用，覆盖范围由实际组件、全局着色器和 RHI 支持决定。

Epic 的 PSO Precaching 文档区分组件与资源收集：资源自身未必知道完整渲染状态，组件信息才能补齐部分状态。引擎还提供代理创建延迟等策略，用于处理管线尚未完成的情况。2026-10-22 核对的网页为 UE 5.8 文档；具体项目应锁定自己的引擎版本及 GRHISupportsPSOPrecaching 能力，不能直接沿用网页默认值。

下面是应用层算法伪代码。两种准备系统的进度来自各自接口，工作总量在内容加载期间可能增长，因此界面不应把一个瞬时计数当作永久总量。

request required content and pipeline combinations
while loading:
    update content loading progress
    collect newly requested pipeline work
    poll completion of required pipeline requests
    keep loading UI responsive
    if discoveryClosed and contentReady and allRequiredRequestsReadyAndRetained:
        enter target scene

循环中的discoveryClosed由首屏内容发现阶段封闭必需键集合后置位；allRequiredRequestsReadyAndRetained要求每个键都已就绪并取得保留引用，Failed不满足该条件。这里的“完成”只覆盖已发现且被列为必需的请求。UE 5.8 文档说明 FShaderPipelineCache::NumPrecompilesRemaining() 可以查询组合缓存与 PSO Precaching 当前未完成的编译请求。计数归零后仍可能因后续内容加载新增请求，因此不能由此判断所有未来组合已经准备好。真正验证是在首次绘制时关联请求键与完成时间。

若等待时间超过产品预算，可以优先准备首屏组合，把其余工作限制在受控后台预算内。跳过对象、默认材质和现场同步创建分别牺牲画面完整性、外观或流畅度，策略必须按项目目标定义并记录触发次数。

请求时间与首用期限

设必需组合K在加载开始后的20毫秒被请求，创建在80毫秒完成，首个绘制在60毫秒需要它；即使列表覆盖了K，仍有20毫秒缺口。把请求提前到0毫秒且创建耗时不变，可在60毫秒完成，但并发争用也可能延长创建，必须比较实际完成时刻。若首用时查询不到K，先比对完整状态键；同材质的四倍MSAA版本不是单样本版本的缓存命中。

记录请求、完成、回收和首用四类事件，分别定位覆盖缺失、准备过晚与回收重建。下文用K说明就绪以后怎样保持到首用。

请求状态与首次使用

应用为每个完整PSO键维护一条请求记录，状态按Missing→Queued→Creating→Ready推进；创建错误进入Failed并保存错误码。再次请求同一键时，Queued或Creating返回同一请求，避免多个加载线程重复创建；Ready返回持有所有权的对象，使用者按GPU完成条件释放引用；Failed按明确重试次数或回退策略处理，不能当作“等待计数已经归零”。缓存键的程序与状态字段见Pipeline State Object，记录里同时保存构建和目标设备兼容身份。

首屏所需键集合在对应内容完成发现后封闭。进入场景的条件是这组键全部Ready，并且对应内容可用；只检查全局剩余数为零，可能把尚未发现的请求或已失败的请求误当作准备完成。需要在预算到期后继续时，渲染端对每次首用显式选择等待、占位或暂缓绘制，并记下键与发生时刻；后台创建完成后再在帧边界发布真实对象，避免记录命令期间替换仍在使用的对象。

首屏集合还绑定内容发现代次、着色器构建身份和目标渲染配置。加载期间更换画质或热更新内容时，在加载入口递增发现代次，重新枚举必需键；旧集合的Ready不能打开新集合的门。已经发出的旧任务按自己的键和设备引用结清，新集合只消费匹配自身版本的请求。集合封闭与进入场景的比较经过同一入口，避免检查全部就绪后才发现目标配置已经变化。

就绪对象的保留与发布

首屏集合封闭时，加载器取得各请求的强引用或保留令牌。就绪状态和取得引用在同一缓存锁内检查：Ready必须同时有当前设备代次的可用对象，才能把引用交给调用方。LRU只移除没有保留者的缓存项；已经返回给加载器或录制任务的对象不因缓存淘汰失效。若预算不足以保留首屏集合，加载器按前述占位或暂缓策略重新安排内容，并记录未满足的键，不能仍按全部Ready进入首屏。

录制开始时，把请求引用转成该批命令的资源引用。录制结果在等待提交期间继续持有引用。取消请求先等待记录线程退出，再通过状态转换取得尚未提交的批次，随后释放引用；提交者取得同一批次后，将引用转入提交记录并挂到覆盖该批命令的完成值，GPU完成才释放。取消与提交只能有一方取得所有权，提交期间发生故障的批次按队列故障流程保留资源。加载器自己的保留持续到首屏录制者取得引用以后，两个阶段有交接而没有空隙。假设K在80毫秒就绪、100毫秒成为LRU候选、200毫秒首次绘制，首屏保留使100毫秒的淘汰跳过K；只保存一个Ready布尔值会在200毫秒重新创建。

后台创建结果也携带设备代次和请求代次。设备重建后，即使旧任务返回成功，它的对象也不能发布到新设备缓存；完成回调在锁内比较两份代次，不符就释放旧结果并保留当前请求。设备代次变化会使首屏保留集合重新进入准备流程，旧完成通知不能打开新场景的加载门。

同一键的请求可以被两个场景共同持有。场景A退出时只撤销A的等待者和保留引用，场景B仍需要的Creating任务继续。最后一个等待者离开时，可以撤销尚未开始的任务；已经进入驱动创建的任务保留输入与设备引用直到调用返回，再依据请求代次决定缓存结果或丢弃。重新进入场景的请求取得新的等待者身份，旧取消回调不能取消这次请求。这样退出加载界面不会提前销毁后台调用仍在读取的数据，也不会误取消另一场景的首屏准备。

等待者加入、退出和工作线程领取Queued任务都经过同一缓存锁。设A是K的最后一个等待者，A退出与B请求竞争：若B先登记，A只移除自身；若A先把Queued改成Cancelled，B创建新请求代次，旧队列项领取时检查代次与状态后退出。若工作线程先取得Creating所有权，A只留下无人等待标记，输入仍由创建任务持有。创建返回时在锁内核对请求仍为当前代次，再发布Ready或丢弃结果。旧回调按完整请求身份定位，不能只凭K删除新请求。这个仲裁把“最后一个等待者”从瞬时计数变成可执行的取消条件。

内存与编译预算

并行编译会占 CPU 和临时内存，更多工作线程不一定更快。测量编译墙钟时间、峰值内存、加载界面帧时间和关键请求的等待时间，再设并发上限。帧数预算或毫秒预算限制的是调度策略，驱动的一次调用可能仍然耗时较长。

按质量档位或内容集合筛选候选，可以避免同时准备当前不需要的组合。LRU 回收内存对象则减少常驻量，但对象再次使用时仍可能重建；驱动缓存是否保留以及重建成本需要实测。关卡卸载不等于所有管线对象被销毁，也不等于对象永远不能回收，实际所有权由缓存策略决定。

图形接口与实现范围

Vulkan 提供管线缓存接口，缓存数据具有实现相关的兼容条件。D3D12 有缓存 PSO 与管线库等路径。Metal 提供 MTLBinaryArchive，可收集并序列化兼容管线的编译数据。OpenGL 的主要准备对象是 Program，程序二进制与并行编译能力分别由版本、扩展和驱动支持决定。

这些 API 能力不能直接推导某个引擎后端已经使用它们。是否保存运行中新发现的数据、什么时候写盘、如何处理不兼容缓存，都属于具体实现。查目标版本的缓存写入与加载入口，再用实际文件变化和冷暖运行确认。

复现与验收

先冻结构建、设备、驱动、画质和路线。在可控测试环境清除指定缓存，记录冷启动准备时间、峰值内存和首次使用事件；同样条件重复运行，记录暖缓存差异。内容路线至少包含首次特效、画质切换、新阴影组合与场景切换。

每个尖峰对应一个假设：若请求在使用前从未出现，是覆盖问题；已请求但未完成，是时机或编译预算问题；已完成仍卡顿，则继续检查对象回收、驱动工作和资源加载。主线程或渲染线程出现等待只是现象，需要时间线指向具体工作。

本文给出调查流程与已核对的接口职责，未运行 Unreal 构建、设备编译或冷暖缓存性能实验。没有项目测量时，预热时长、内存收益和运行时卡顿率均保持未验证。

相关主题

• Pipeline State Object
• Shader Variant管理
• 帧瓶颈诊断
• 性能对照实验

参考资料

• Epic Games，PSO Precaching，Component/Resource Precaching、编译等待与对象保留，2026-10-22 核对，网页标记 UE 5.8。
• Apple，MTLBinaryArchive，管线二进制归档接口。
• Khronos，Vulkan Pipelines，Pipeline Cache：缓存数据的兼容与读取规则。
• Microsoft，Managing Graphics Pipeline State，PSO 与动态状态的边界。