Reading of current framebuffer

Hi, I have one question. Is there any way how to read whole currently displayed screen content (something similar as XShmGetImage(display, RootWindow(display, 0, …) do in XLib) in CUDA program on linux/Xorg?


No. CUDA does not entertain a graphics context and thus has no connection to the X server or Win GDI. You have to read the buffer as you said and then upload it to a CUDA buffer.

I would however consider the option to change the program that produces the framebuffer to render into an offscreen FBO. This one can be bound to a CUDA buffer. There will still be a copy operation but it will happen in GPU memory. This is much faster than download/upload over the bus. See the image post-processing demo by Simon Green somewhere on this forum.



Ok, so CUDA does not have a graphics context. But how could I create one on Linux

without the need for the X infrastructure. I am interested in reading the contents of a framebuffer

object (or writing to it using OpenGL commands), but I am not interested in displaying

the results. The example you mention (from Simon Green), if it is the one that comes with the

SDK still uses glutCreateWindow(). As a consequence, when I try to execute the program

from a remote site using ssh, I cannot: I get a “…Failed to open display…” error.

Surely, given the fact that there are so many libraries to create opengl contexts for

different operating systems, there must be a way to create a context when there is

no operating system, i.e., when everything happens on the GPU?

Any help or direction to look is appreciated.




I am pretty sure that you need always an operating system ;-)

You can create an offscreen context by creating a P-Buffer. Then create the graphics resources in the P-Buffer. Mark has written a nice P-Buffer code a while ago. Check it out.


Thnaks Peter. I appreciate the link. I worked with Mark’s software a few years back. But do pbuffers create their own context, or must a routine such as glutCreateWindow() still be called?

Of coure I need an OS :-), but I do not wish to use the standard display.

I will keep investigating and keep you informed if I find anything useful. Two solutions that have presented themselves are the latest version of Mesa3D and Virtual GL.


Yes, the P-Buffer has a separate graphics context. You cannot get around the connection to the window manager, as it manages concurrent access to the graphics resources. So on Linux there is no way to talk to the GPU if there is an X server that has claimed it. Same for Windows - you cannot talk to the card if GDI owns it. This is why the CUDA driver is currently included in the graphics driver, so it can serialize the resource access.

Should NVIDIA one day come up with a CUDA driver that is not integrated in the graphics driver, you will not be able to run an X server on this card. The other way around, if you run your CUDA program on a card that does not run an X server, you will not be able to create a graphics context on it.

To cut it short: as you want to read the content of a framebuffer, you need a) a connection to the display manager and B) a CUDA version that is running with the graphics driver.


Guys, p-buffers (and my RenderTexture class) are obsolete. Please use Framebuffer Objects (FBOs) for off-screen rendering. There’s a nice FBO wrapper class linked on


Sure, but the question was specifically about a separate (offscreen) graphics context. The FBO lives in the current context. You can construct an FBO in the P-Buffer, right.