# Reading of current framebuffer **URL:** \ **Category:** CUDA Programming and Performance\ **Created:** [March 26, 2007, 9:40am UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468 "2007-03-26T09:40:44Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![mabo](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@mabo](https://forums.developer.nvidia.com/u/mabo)\ **Post date:** [March 26, 2007, 9:40am UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/1 "2007-03-26T09:40:44Z")
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? TIA ---
**Author:** ![prkipfer](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@prkipfer](https://forums.developer.nvidia.com/u/prkipfer)\ **Post date:** [March 26, 2007, 10:17am UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/2 "2007-03-26T10:17:43Z")
> [@](#): > > 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? > > TIA > > [snapback]176046[/snapback] 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. Peter ---
**Author:** ![erlebach](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@erlebach](https://forums.developer.nvidia.com/u/erlebach)\ **Post date:** [April 21, 2007, 4:05pm UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/3 "2007-04-21T16:05:59Z")
Peter, 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. Thanks, Gordon > [@](#): > > 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. > > Peter > > [snapback]176053[/snapback] ---
**Author:** ![prkipfer](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@prkipfer](https://forums.developer.nvidia.com/u/prkipfer)\ **Post date:** [April 23, 2007, 4:21pm UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/4 "2007-04-23T16:21:37Z")
Gordon, 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](http://www.markmark.net/misc/rendertexture.html) a while ago. Check it out. Peter ---
**Author:** ![erlebach](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@erlebach](https://forums.developer.nvidia.com/u/erlebach)\ **Post date:** [April 23, 2007, 5:54pm UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/5 "2007-04-23T17:54:07Z")
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. Gordon > [@](#): > > Gordon, > > 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. > > Peter > > [snapback]188591[/snapback] ---
**Author:** ![prkipfer](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@prkipfer](https://forums.developer.nvidia.com/u/prkipfer)\ **Post date:** [April 24, 2007, 12:25pm UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/6 "2007-04-24T12:25:23Z")
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. Peter ---
**Author:** ![Mark\_Harris](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/mark_harris/32/23175_2.png) [@Mark\_Harris](https://forums.developer.nvidia.com/u/Mark_Harris)\ **Post date:** [April 25, 2007, 8:38am UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/7 "2007-04-25T08:38:14Z")
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 [url=“[http://www.gpgpu.org/developer](http://www.gpgpu.org/developer)”][http://www.gpgpu.org/developer[/url]](http://www.gpgpu.org/developer%5B/url%5D) Mark ---
**Author:** ![prkipfer](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@prkipfer](https://forums.developer.nvidia.com/u/prkipfer)\ **Post date:** [April 25, 2007, 10:09am UTC](https://forums.developer.nvidia.com/t/reading-of-current-framebuffer/468/8 "2007-04-25T10:09:02Z")
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. Peter