Sharing GrDirectContext Across Multiple MTKView

25 views
Skip to first unread message

BK

unread,
Jul 14, 2026, 8:48:18 AM (7 days ago) Jul 14
to skia-discuss
Hello Team,

On the Ganesh Metal backend (Skia m118, macOS), I need to render into many independent MTKView surfaces simultaneously.
All rendering happens on the main thread, and every view uses the same MTLDevice (and command queue).

I have a few questions about the recommended architecture:
1. Is it recommended to share a single GrDirectContext across multiple MTKView surfaces by creating one SkSurface per view, rather than creating a separate GrDirectContext for each view?
2. Is GrDirectContext::setResourceCacheLimit(...) the recommended way to cap GPU memory usage? If so, are there any guidelines for choosing the cache limit?
3. When a view is destroyed and its SkSurface is released, what is the recommended way to reclaim the associated GPU memory?
4. Are there any caveats to sharing a single GrDirectContext across multiple SkSurfaces on a single thread?


Regards,
BK

Michael Ludwig

unread,
Jul 14, 2026, 8:56:25 AM (7 days ago) Jul 14
to skia-discuss
1. Yes you should absolutely use a single GrDirectContext; this is Skia's way of accessing the MTLDevice and other heavy-weight objects representing the GPU.  It is supported to either create multiple SkSurfaces that are texture-backed (where Skia creates the underlying texture), or to wrap existing views/textures into SkSurfaces.
2. The recommended way to set the resource limit is through the ContextOptions struct that you provide when creating the GrDirectContext. This is a limit to the amount of unused resources that Skia will keep around, but if there are resources that are actively being used (or held by your references to an SkImage or SkSurface), Skia will go above the resource limit in order to render the frame.  The default limit is often quite safe, but you can shrink it or invoke the different deferred-cleanup functions that will remove resources that haven't been used in X amount of time (which will let you explicitly reduce the cache below the resource limit).
3. This depends entirely on how the texture and view are being created.  If you're using the RenderTarget SkSurface factories, the underlying texture is still owned by Skia and Ganesh will recycle it automatically.  If you are creating the MTKViews and MTLTextures and wrapping them using Ganesh's BackendTexture objects, then you are responsible for actually destroying the GPU memory when Skia says it's safe to do so. This also means it's under your control to re-wrap the view in a new SkSurface or SkImage as desired.  But you should not have a BackendTexture wrapped as multiple surfaces simultaneously.
4. As long as access to the GrDirectContext is single-threaded, you should be fine.

Reply all
Reply to author
Forward
0 new messages