Repository navigation
Sharing buffers with display renderers (like OpenGL, Vulkan, etc.) #241
Description
Activity
- added a sub-issue
on Feb 24, 2025 I think OpenGL should be the primary target. John has linked to various discussions and works in the issue description that some of us contributed to in the past few years, which should be good starting points especially those involving CuPy <-> vispy inter-op.
My understanding is users would like an object that represents a GL buffer (analogous to
StridedMemoryView) and has RAII style behavior so cleanup happens during Python GCHaving a function to facilitate that conversion (
StridedMemoryViewtoGLStridedMemoryView?) would also helpThis comment captures this: vispy/vispy#1986 (comment)
- linked a pull request that will close this issueAdd CUDA-Graphics (OpenGL) interop support to cuda.core #1608
on Feb 27, 2026 Just adding this to cross-link onto the DLPack issue I opened: dmlc/dlpack#183
A common use case is to do some computation on the GPU and then render the result in a display ( cupy/cupy#5711 ) ( vispy/vispy#1985 ) ( vispy/vispy#1986 ) ( napari/napari#2243 ). This could be an image that is shown or a plot or something else. Given the registration/unregistration and mapping/unmappaing of memory, this can generate quite a bit of boilerplate in Python ( vispy/vispy#2391 ), which in turn hinders adoption. Ideally some standard objections/functions could be supplied (ideally in CUDA Python) that users could leverage to prep data for rendering. Preferably they could use one function call to covert any
__cuda_array_interface__,__dlpack__, etc. supporting object into one that can be used for rendering (and hang onto the lifetimes of any supporting buffers via RAII-style semantics)