CUDA-OpenGL Interop - CUDA API

Re the CUDA-OpenGL Interop APIs:

Needing some clarification on the relationships and mappings between CUDA objects (textures, surfaces, arrays, linear memory i.e. cudaMalloc( )) and OpenGL objects (buffers, textures, render buffers),

Specifically which OpenGL objects can map to which CUDA objects?

One at least seems clear -

OpenGL buffer (VBO) => CUDA linear memory pointer
Via cudaGraphicsGLRegisterBuffer( )
And cudaGraphicsMapResources( ) then
CudaGraphicsResourceGetMappedPointer( )

CudaGraphicsGLRegisterImage( ) -
Docs say it supports OpenGL texture or render buffer. In the case of mapping to a CUDA Surface object, is the flag = cudaGraphicsRegisterFlagsSurfaceLoadStore the only option to use?

Can an OpenGL texture be mapped to a writeable CUDA surface object?
Can an OpenGL texture or render buffer be mapped to a CUDA pointer?? (I.e. cudaGraphicResourceGetMappedPointer( cudaResourceToOpenGLTexture/Renderbuffer, …)

CudaGraphicsSubResourceGetMappedArray( ) - does it have to be passed a cuda resource registered as Image?

What is the difference between a CUDA texture, surface, and/or array?
Referring to CUDA Toolkit 12.1 docs section : Are both textures and surfaces instances of the general (‘abstract’) CUDA array type, or is there more to it? Is the Array type ever used directly from CUDA or just as textures and/or surface?


In general there is a connection between OpenGL textures and those things (CUDA texture, CUDA surface) that can access a cudaArray, and another connection between OpenGL buffers and CUDA linear memory (the type of stuff you get from cudaMalloc).

However, it’s possible to go from an OpenGL texture to an OpenGL buffer, if you do the work on the OpenGL side. This presentation albeit dated, is a good resource for basic understanding.

I don’t understand the question. What else would you use?


for cudaGraphicsResourceGetMappedPointer: Texture: No, unless you do the opengl work first that I referenced. Buffer: yes.

A cudaArray is an opaque device memory buffer, which holds data. The data held in it requires a special device code access method (texture or surface API) and cannot be accessed using “ordinary” C++ style pointer/array access methods. cudaArray has its own API to set up.

A CUDA texture is a read-only, opaque object, that fetches data “through” the texture cache. The details of the texture cache are not well specified AFAIK, but the general idea is that some access patterns that might receive lesser benefit from an “ordinary” cache may receive greater benefit from the texture cache, due to its specific design and the specific access pattern (“spatial”). A CUDA texture can be backed by either a cudaArray, or linear memory, but there is not complete symmetry in terms of API or feature set between using a CUDA texture backed by linear memory vs. one backed by cudaArray.

A CUDA surface is like a texture, except that it is readable and writable. Furthermore, a surface cannot be backed by linear memory, AFAIK. It requires a cudaArray backing.

cudaArray is used by CUDA texture or CUDA surface, and is also an interchange format in CUDA/graphics interop. I’m not aware of other uses for cudaArray.

I’m not sure why it should be necessary to suggest that textures and surfaces are instances of cudaArray type. First of all, cudaArray is not abstract. There is a specific API to set it up. Second, we have already covered that textures need not be backed by cudaArray.

Robert - thanks for the fast and detailed reply.
You’ve answered almost all my questions - and thanks for the links to the refs - see below for a few follow-ons,

A CUDA texture is not necessarily backed by a cudaArray. It may be.

I don’t know that cudaArray is “defined” anywhere. However you can find references to it and usage examples in the texturing section of the programming guide as well as in the runtime API.

I’ve mentioned a few times that it is “opaque”. By this I mean there is no programmatic way to directly study it, or every aspect of its organization, or any underlying details with a few superficial exceptions such as things that were known at creation time like the dimensions, and the bulk storage requirements.