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

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?

Thanks,

Gordon

You must create a window to get a opengl context. You dont have to display it though.

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:

glutInit(&argc,argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
glutInitWindowSize(imageWinWidth, imageWinHeight);
glutCreateWindow("gordon");
glewInit();

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?

Gordon

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.

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,

Gordon

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,

Gordon