Jump to content
  • Advertisement
Sign in to follow this  

OpenGL OpenGL from remote computer

This topic is 4050 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Given that openGL lacks windowing facilities of course, you need window creation software, whether one uses SDL, X or windows, or whatever. However, framebuffer objects do not depend on the windowing system. Here is what I'd like to do: Create an openGL program that draws into a framebuffer object, retrieves the information, and sends it elsewhere using TCP or some other protocol. I should be able to run this program from a remote computer. In summary: I am not interested in creating a window or in processing events. Is this possible? If not, why not? Thanks, Gordon

Share this post

Link to post
Share on other sites
If I understand you want to be able to draw with openGL, without creating a window (on an invisable) window, and transmit that information.

Is this a simple screenshot, or you want to send like a 'recorded' scene, like a movie?

Either way, sounds like a trojan to me !!

Hey, whatever floats your boat !!

Share this post

Link to post
Share on other sites
Not a trojan, although any technology can be abused. We are building
collaborative software. Any remote rendering software on the market,
such as VNC, etc., essentially duplicate the server desktop on a client
machine for remote access. In that case, nobody can work on the remote
server since the screen is displaying the visual information requested
by the client. All I wish to do is draw into a framebuffer object, rather
than to the screen. Usually, one copies the contents of the framebuffer
object to the screen. I want to copy the contents of this buffer to a
screen on a remote computer. In that case, the windowing system on the server
is not required.

Can this be done?



Share this post

Link to post
Share on other sites
You must create a window to get a opengl context. You dont have to display it though.

Share this post

Link to post
Share on other sites
Thanks Cody. That makes sense. However, isn't there any other way to get
an OpenGL context than by opening a window? The very act of using the
command GLCreateWindow when using glut prevents me from using the software
from a remote site. Note that I am not ssh'ing using the "-X" option, but
rather, I wish to execute the program from the console.

Here are my lines of code with glut:

glutInitWindowSize(imageWinWidth, imageWinHeight);

If I comment out glutCreateWindow, the context is not created and the program
will crash. If I use lower level X functions, then I still will not be
able to use the program from a remote site (without actually logging in)
since X will not be available.

Perhaps I could use the Linux Framebuffer directFB? I have no experience at
this level. Any thoughts?


Share this post

Link to post
Share on other sites
OpenGL hardware cant work without a X server. The driver is for X.
So either you use X forwarding(though i dont know which libs must be installed on the client to make this work for opengl), or you use a software renderer like Mesa. That should run without X but will be extremely slow.

Share this post

Link to post
Share on other sites
Thanks Cody. That is unfortunate. But surely it is "possible" to create
a hardware driver that does not depend on X (or other windowing system).
After all, CUDA allows computation fully on the GPU and allows one to retrieve
data to the CPU. As long as displaying is not a requirement, there is no problem.
Computations can be done from a remote site. However, the use of glxxx routines
requires attachment to a windowing system. That means that even if I use
gl commands to write into a framebuffer (which is on the GPU and has nothing
to do with the X system), I cannot do so without switching back to software
mode. Something is not logical. X should not be required for the hardware.
If it were, hardware could not be run on windows or mac, or whatever.
Somehow, what is needed is bindings to the microcode of the GPU.

Thanks again,


Share this post

Link to post
Share on other sites
Hi again,

Why don't you explain a little more about what you are trying to achieve, and maybe we could suggest an alterative solution.

Since you are trying this in OpenGL, and you mention remote software such as VNC, I can only imagine you are trying to capture a 3D enviroment.

Are you trying to remotely view, say someone elses 'in-game' play for example, or is it like VNC for example, for a purely support reason.
Again are you trying to 'stream' desktop info, like a real-time video such as VNC, PcAnywhere etc etc.
Or is this purely to capture a screenshot?

Is this some attempt to utilize video memory to enhance or speed up the application someway.

Anyway, post a little more info might be helpful


Share this post

Link to post
Share on other sites
Thanks for your response. Here are some more details.

I have been interested for a long time in remote visualization: I am on a client in New York, but my visualization computer is in Florida. I'd like do all you
suggest, but mostly, for now, I'd like to debug from home. So I want to easily
run the CUDA programs that are linked to OpenGL, or any graphics program that I have on the visualization server, and display it on my client. Ideally, I'd like multiple people (say 2 or 3) to be able to this concurrently. This should be possible with the more recent cards that have more than enough internal memory to accomodate this.

Here is a particular example. I have written a program to visualize vector fields by tracking particles. The code is highly optimized on the Nvidia 7900. It updates approximately 40,0000,000 partices/sec. Everything occurs on the GPU using vertex array buffers, vertex buffer objects and framebuffer objects. At this time, I have versions linked to glut and to Qt. When I execute this program from my client, I get the message "Cannot open display:", which is expected. However, I do not
need a display, or a window. It should be possible to create a graphics context
without that. Hardware acceleration does not depend on X. It depends on some kind of external support for the library routines (but I am not cognizant of the details). I could log to the remote machine using ssh -X, and display the plot
on my local machine. But I want more flexibility. I want to have access to the
bitmap (generated with hardware acceleration), and have full control over how I
stream it, compress it, postprocess it (perhaps on another machine), etc.

Does this help,


Share this post

Link to post
Share on other sites
I'm not sure I am following this, but I think you might be confused somewhat.

Are you trying to run an OpenGl program (lets say 'Snake3D') where the EXE is stored on the 'server' and you want it to run on your 'client' machine.

If so this has nothing to do with OpenGL, but more over remote access to those files, so you can run the application 'locally'

If you are trying to 'visual monitor' or watch someone else play the game on the 'server' and you view from the 'client' it's a different matter.

You suggest there is no window on the 'server', so I would think the second suggestion is not what you are doing.

If you want the 'server' to run and "Render" 'Snake3D' without a window, and use the 'servers' (graphics card) processing power, AND stream this data for viewing on client machines (you say 2 or 3 people), I think you are expecting an awful lot.
Remember if the server is doing the 'rendering' work, your 'client' graphics card isn't doing it.

Not only will a 3D application take most of the 'servers' CPU time, as well as whatever else the 'server' is meant to be doing (unless it's dedicated to this task), you also want to compress and stream this data to multiple clients.

Some challange if you plan to stream bitmap images at say a minimum of 60fps.

unless you explain even more about what you are trying to achieve, it's a little difficult to help.
I think what you might be looking for, is like a networked game (say quake) where the server is just sending 'packets' of information about players position, health, other info, to a client EXE which then handles that data, and does the 'rendering'

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!