CUDA-OpenGL Interop - CUDA API

[colinrei]

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 3.2.14.3 : 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?

Thanks

[Robert_Crovella]

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.

@colinrei

is the flag = cudaGraphicsRegisterFlagsSurfaceLoadStore the only option to use?

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

@colinrei

Can an OpenGL texture be mapped to a writeable CUDA surface object?

Yes.

@colinrei

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

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

@colinrei

What is the difference between a CUDA texture, surface, and/or array?

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.

@colinrei

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?

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.

[colinrei]

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,

@Robert_Crovella

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.

@colinrei

is the flag = cudaGraphicsRegisterFlagsSurfaceLoadStore the only option to use?

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

@colinrei

Can an OpenGL texture be mapped to a writeable CUDA surface object?

Yes.

@colinrei

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

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

@colinrei

What is the difference between a CUDA texture, surface, and/or array?

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.

@colinrei

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?

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.

(COLIN) to clarify here, I was using the terms “instances” and “abstract” in a non-specific way, i.e. not intended to imply specific C/C++ implementations but rather more general conceptual architectural pattern. As such it seems the answer is YES, since both CUDA textures and surfaces are “backed” by a cudaArray - whatever that exactly means…(I’d love to understand better). Where in the CUDA source is the cudaArray defined? Is it something we can look at?)
(/COLIN)**

[Robert_Crovella]

@Robert_Crovella

As such it seems the answer is YES, since both CUDA textures and surfaces are “backed” by a cudaArray

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

@Robert_Crovella

Where in the CUDA source is the cudaArray defined? Is it something we can look at?

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.