Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8373acb3 authored by Greg Daniel's avatar Greg Daniel Committed by Android (Google) Code Review
Browse files

Merge "Implement functions for managing Graphite memory budget." into main

parents e95dc83f 40618595
Loading
Loading
Loading
Loading
+32 −0
Original line number Diff line number Diff line
@@ -110,8 +110,40 @@ bool GraphiteGpuContext::isAbandonedOrDeviceLost() {
    return mContext->isDeviceLost();
}

void GraphiteGpuContext::setResourceCacheLimit(size_t maxResourceBytes) {
    // Graphite has a separate budget for its Context and its Recorder. For now the majority of
    // memory that Graphite will allocate will be on the Recorder and minimal amount on the Context.
    // The main allocations on the Context are MSAA buffers (not often, if ever used in
    // RenderEngine) and stencil buffers. However, both of these should be "memoryless" in Vulkan on
    // tiled GPUs, so they don't actually use GPU memory. However, in Vulkan there are scenarios
    // where Vulkan could end up using real memory for them. Skia will regularly query the device to
    // get the real memory usage and update the budgeted appropriately. Though for all real usage
    // patterns we don't expect to ever trigger the device to allocate real memory.
    //
    // Therefore, we set the full maxResourceBytes budget on the Recorder. However, in the rare
    // chance that the devcies does allocate real memory we don't want to immediately kill device
    // performance by constantly trashing allocations on the Context. Thus we set the Context's
    // budget to be 50% of the total budget to make sure we allow the MSAA or Stencil buffers to be
    // allocated in Skia and not immediately discarded. But even with this extra 50% budget, as
    // described above, this shouldn't result in actual GPU memory usage.
    //
    // TODO: We will need to revise this strategy for GLES which does not have the same memoryless
    // textures.
    // TODO: Work in Graphite has started to move a lot more of its scratch resources to be owned
    // by the Context and not on Recorders. This will mean most memory is actually owned by the
    // Context and thus the budgeting here will need to be updated.
    mContext->setMaxBudgetedBytes(maxResourceBytes / 2);
    mRecorder->setMaxBudgetedBytes(maxResourceBytes);
}

void GraphiteGpuContext::purgeUnlockedScratchResources() {
    mContext->freeGpuResources();
    mRecorder->freeGpuResources();
}

void GraphiteGpuContext::dumpMemoryStatistics(SkTraceMemoryDump* traceMemoryDump) const {
    mContext->dumpMemoryStatistics(traceMemoryDump);
    mRecorder->dumpMemoryStatistics(traceMemoryDump);
}

} // namespace android::renderengine::skia
+3 −9
Original line number Diff line number Diff line
@@ -39,16 +39,10 @@ public:
    size_t getMaxRenderTargetSize() const override;
    size_t getMaxTextureSize() const override;
    bool isAbandonedOrDeviceLost() override;
    // No-op (large resources like textures, surfaces, images, etc. created by clients don't count
    // towards Graphite's internal caching budgets, so adjusting its limits based on display change
    // events should be unnecessary. Additionally, Graphite doesn't expose many cache tweaking
    // functions yet, as its design may evolve.)
    void setResourceCacheLimit(size_t maxResourceBytes) override{};

    // TODO: b/293371537 - Triple-check and validate that no cleanup is necessary when switching
    // contexts.
    // No-op (unnecessary during context switch for Graphite's client-budgeted memory model).
    void purgeUnlockedScratchResources() override{};
    void setResourceCacheLimit(size_t maxResourceBytes) override;
    void purgeUnlockedScratchResources() override;

    // No-op (only applicable to GL).
    void resetContextIfApplicable() override{};