GPU 资源管理

[0x1306a94]

@domchen 想请教下
大多数OpenGL 教程，以及Apple Metal 的官方示例代码。对于 Program Pipeline Buffer Texture 等资源都是提前创建好。
在渲染loop中 也只是更新数据等。
但是我看 https://github.com/Tencent/libpag/blob/feature/partyhuang_update_tgfx/src/rendering/filters/RuntimeFilter.cpp 这些滤镜的实现都是在 onDraw 中每次创建。
而这些资源会在创建 CommandEncoder 时释放之前的，我理解的应该就是会在当前帧中会先释放上一帧的资源。
之所以这样是因为现代 GPU 驱动对于这些操作有优化，基本上不会有性能问题的原因吗？

std::shared_ptr<CommandEncoder> GLGPU::createCommandEncoder() {
  processUnreferencedResources();
  return std::make_shared<GLCommandEncoder>(this);
}

void GLGPU::processUnreferencedResources() {
  DEBUG_ASSERT(returnQueue != nullptr);
  while (auto resource = static_cast<GLResource*>(returnQueue->dequeue())) {
    resources.erase(resource->cachedPosition);
    resource->onRelease(this);
    delete resource;
  }
}

void GLGPU::releaseAll(bool releaseGPU) {
  if (releaseGPU) {
    for (auto& resource : resources) {
      resource->onRelease(this);
    }
  }
  resources.clear();
  returnQueue = nullptr;
}

std::shared_ptr<GLResource> GLGPU::addResource(GLResource* resource) {
  DEBUG_ASSERT(resource != nullptr);
  resources.push_back(resource);
  resource->cachedPosition = --resources.end();
  return std::static_pointer_cast<GLResource>(returnQueue->makeShared(resource));
}

[domchen]

实际上我们绝大部分GPU资源都是提前统一创建的，
你可以关注一下ResourceTask的子类，整个这类task都是在RenderTask之前执行，特别是那些含有提交数据的资源一定是提前集中创建，不然会引起渲染过程中的同步卡顿。小部分纹理（主要是纯RT）是用的时候创建，是因为方便进入回收池在一帧内最大化复用，加上单纯的创建操作不涉及提交数据的话并不会造成卡顿问题，所以RT都是延迟的。还有一类是program资源，理论上应该是提前创建的，但是program基本上很少会频繁创建，创建一次就持续缓存使用，所以暂时没有专门去优化提前它。

[0x1306a94]

你可以关注一下ResourceTask的子类，整个这类task都是在RenderTask之前执行 这个我有在源码DrawingBuffer::encode中看到。

我只是在找一些实现想看看 libpag 是如何应用的，然后发现在 libpag 的 filter 实现中是在 onDraw 中每次重新创建 program buffer 这些。
然后我也问了AI，说是 现代 GPU 驱动对频繁创建/销毁 buffer/texture/pipeline 已经做了非常深的内部对象池与延迟回收优化
而这种 frame-lifetime 资源模式在性能上也并不会很差，不确定这个结论是否是正确的。
但是libpag 这么久以来都是这种模式，也确实没有因为这个而产生性能问题。

[domchen]

RuntimeEffect是一个特殊的绘制流程，外部临时注入的，出于生命周期管理考虑比较不好做提前创建，理论上确实应该把含有数据提交的buffer也提前创建的，libpag里之所以性能没有被影响，主要的原因应该还是频率问题，大头的渲染都是引擎里标准处理的，自定义滤镜其实实际用到的次数没那么多。

[0x1306a94]

嗯，我看tgfx 内部的 drawOp 的 program 是会被添加到 context关联的cache中

[yuerolling]

@domchen 大佬，说到RuntimeEffect，我也有个问题咨询下， 我现在也基于它做了很多特效，发光，噪声，粒子等等，多个特效封装成多个RuntimeEffect实现，目前也只是参考tgfx实现，每一次ondraw都是一次新的流程，我目前测下开只要shader里算法处理得当，性能还是可以的，所以目前还没做任何优化，如果后面一帧加载的RuntimeEffect太多，具体优化 的方向是怎么样的或者说是否有优化的必要

[0x1306a94]

#include <tgfx/gpu/Context.h>

class IContextAware {
  public:
    virtual ~IContextAware() = default;

    bool attachContext(tgfx::Context *context);

    tgfx::Context *getContext() const {
        return context;
    }

    uint32_t getContextID() const {
        return contextID;
    }

  protected:
    /**
     * 重置资源（当 Context 变化时调用）
     * 子类应该在此方法中释放所有 GPU 资源（Pipeline、Buffer、Texture、Image 等）
     *
     * @note 此方法会在 attachContext() 检测到 Context 变化时自动调用
     * @note 子类必须实现此方法
     */
    virtual void onResetGPUResources() = 0;

  protected:
    tgfx::Context *context = {nullptr};
    uint32_t contextID = 0;  // Context 的唯一 ID，用于检测变化
};

bool IContextAware::attachContext(tgfx::Context *context) {
    if (context == nullptr) {
        // Context 为 nullptr，如果之前有 Context 则重置资源
        if (this->context != nullptr) {
            this->context = nullptr;
            this->contextID = 0;
            onResetGPUResources();
            return true;
        }
        return false;
    }

    uint32_t newContextID = context->uniqueID();
    bool contextChanged = (this->context == nullptr) || (this->contextID != newContextID);

    if (contextChanged) {
        this->context = context;
        this->contextID = newContextID;
        onResetGPUResources();
        return true;
    }

    return false;  // Context 未变化
}

void CustomRenderPass::onResetGPUResources() {
    fillUBOBuffers.clear();
    fillVBOBuffer.reset();
    strokeVBOBuffer.reset();
    strokeUBOBuffer.reset();
    fillPipeline.reset();
    strokePipeline.reset();
    textureImage.reset();
    msaaTexture.reset();
    renderTexture.reset();
    colorTexture.reset();
    colorSampler.reset();
}

@yuerolling 我现在是这样做的，在最顶层的 onDraw 中，一开始前先调用对应继承了 IContextAware 的 attachContext
然后在具体的子类的onDraw 中如果相关资源没有则创建

[yuerolling]

#include <tgfx/gpu/Context.h>

class IContextAware {
  public:
    virtual ~IContextAware() = default;

    bool attachContext(tgfx::Context *context);

    tgfx::Context *getContext() const {
        return context;
    }

    uint32_t getContextID() const {
        return contextID;
    }

  protected:
    /**
     * 重置资源（当 Context 变化时调用）
     * 子类应该在此方法中释放所有 GPU 资源（Pipeline、Buffer、Texture、Image 等）
     *
     * @note 此方法会在 attachContext() 检测到 Context 变化时自动调用
     * @note 子类必须实现此方法
     */
    virtual void onResetGPUResources() = 0;

  protected:
    tgfx::Context *context = {nullptr};
    uint32_t contextID = 0;  // Context 的唯一 ID，用于检测变化
};

bool IContextAware::attachContext(tgfx::Context *context) {
    if (context == nullptr) {
        // Context 为 nullptr，如果之前有 Context 则重置资源
        if (this->context != nullptr) {
            this->context = nullptr;
            this->contextID = 0;
            onResetGPUResources();
            return true;
        }
        return false;
    }

    uint32_t newContextID = context->uniqueID();
    bool contextChanged = (this->context == nullptr) || (this->contextID != newContextID);

    if (contextChanged) {
        this->context = context;
        this->contextID = newContextID;
        onResetGPUResources();
        return true;
    }

    return false;  // Context 未变化
}

void CustomRenderPass::onResetGPUResources() {
    fillUBOBuffers.clear();
    fillVBOBuffer.reset();
    strokeVBOBuffer.reset();
    strokeUBOBuffer.reset();
    fillPipeline.reset();
    strokePipeline.reset();
    textureImage.reset();
    msaaTexture.reset();
    renderTexture.reset();
    colorTexture.reset();
    colorSampler.reset();
}

@yuerolling 我现在是这样做的，在最顶层的 onDraw 中，一开始前先调用对应继承了 IContextAware 的 attachContext 然后在具体的子类的onDraw 中如果相关资源没有则创建

你这个我理解其实整体类似一个懒加载的设计，我那个特效太多的话 ，中间会产生很多碎片化的gpu缓存资源，tgfx 本身也提供了资源清理的方式，我担心简单粗暴的做些缓存之类的设计 ，反而起到反效果，还不如不做优化。

[0x1306a94]

确实也是，如果说每次ondraw 你需要的资源， 比如 VBO UBO Texture 大小都不一样的话。那这种设计和直接每次创建其实每啥区别

[domchen]

其实主要就是两类：1.创建频率不高可以缓存的尽量缓存，不要每帧创建相同资源又销毁，能够复用的就第一次绘制的时候创建就缓存下来，后面就从缓存里拿。这种懒加载模式创建就行，没有什么问题，总次数也不多。2.每帧都需要创建的资源，如果涉及提交数据的。比如顶点数据对应的buffer。这些理论上应该提前。但是你数据量如果特别小直接提交差别也不大。我们对于引擎里绘制上万次的零碎顶点会提前集中提交，并且合并到一个Buffer上。对于RuntimeEffect还没加入到这个合并优化里。未来可以考虑。不过目前看起来确实没有到上万次绘制那种场景，只有少量的调用也不会构成太大差别。