Dual monitor with OpenGL ?

Hi,

Do you now a portable way ( my be a library ) that provides dual or multiple monitors with OpenGL ( ARB must think about ). I’m developing a aplication ( a server ) that must map some events in some monitors ( at the moment 4 ) at same time. It’s a sercurity system and must be on full screen not windowed.

Thanks

DelNeto

You should say what platforms you want to port to. There are cards that have multiple outputs to monitors. And then there is the case of multiple video cards, each with one or more outputs.

I don’t know if the later is resolved on Windows yet. I don’t have any PCI cards either so I can never test.

V-man

OK thanks for replay.

My test base are:

First one.
AGP SLOT - Nvidia GeForce 4 MX460.
This card is dual but i need to test in not dual card way.

Second one.

PCI SLOT - Nvidia TNT 2 MODEL 64.

Main target OSs - Windows and Linux.

In order to have OpenGL rendered across multiple monitors supplied by multiple cards, you’d have to fall back to software rendering in Windows. Unfortunately, the OpenGL ICD model does not allow a program to choose which ICD to bind a particular render context to. Because each OpenGL implementation (GeForce4 and TNT2) is different, you can’t actually choose which one you use. The primary card is the one that is used in this case; the other card is not and cannot be used by your program for OpenGL purposes under Windows.

Originally posted by Korval:
Unfortunately, the OpenGL ICD model does not allow a program to choose which ICD to bind a particular render context to.

Have you tested this? I thought it should at least be possible to render to a window with its own context on one card and to a second window with different context on the second card.
Since for example DescribePixelFormats accepts an HDC as parameter, it should be possible to get the pixel formats supported by each adapter, create a window on each of the adapters, set the pixel format and create an appropriate context.
Or is it only possible to have one ICD installed in the system and that’s why it doesn’t work?

Regards.

Originally posted by Asgard:
Or is it only possible to have one ICD installed in the system and that’s why it doesn’t work?

That’s correct.
I assume it’s because when your app loads opengl32.dll at runtime, that dll queries the primary adapter for opengl support in its attach-to-process section in DllMain. I would imagine it would be simple for Microsoft to sort this out, but I believe only Microsoft could sort this out - and they ain’t gonna.

Hm, that’s not good. I wish MS would improve WGL a bit…not only regarding multiple adapter/head support.

Anyhow, I’m very interested in using multiple adapters for an application I’m working on. How can you use multiple adapters under Linux? Say I have two different graphic cards from two different vendors. Can that work under X? I guess there would at least be a problem with having two GLX extension modules…but I’m not a Linux expert, so maybe it can work without problems?
And if it does work, how do you tell the X server to create a window on a specific adapter?

Cheers.

I had some problems using OpenGL on multiple monitor as well (with different graphic cards):

  • Win2K (maybe NT4 and XP too): OpenGL will work only if the window is on the primary monitor (“use this device as the primary monitor” in display properties).
  • Win98: multiple monitor doesn’t work at all, in 2 monitors are in use, no ICD is available. You have to disable one monitor to have ICD.
  • Linux: I never tried to use OpenGL on it, but I know it’s possible to export the display to another computer. Maybe you can export the display to the same computer, but on another monitor … The nVidia Final Fnatasy RT demo was using a cluster of Linux computers (with tile rendering I think).

[This message has been edited by opla (edited 07-23-2002).]

Hmmm… interesting, because I’ve been doing debug the last few weeks with our new portable with NVidias NView (GEForce4ToGo) that supports “extend my desktop to this monitor”. I’ll have Visual Studio on the second monitor and the OpenGL Application on the primary - never tried the other way around (because one of our concerns is the LCD being viewable under harsh lighting conditions)… I’m on XP, as soon as I get the portable back I’ll let you know if I can swap!

I’d be surprised if MS ever updated the WGL libraries… wouldn’t hold my breath. Maybe try using some of the libraries that let you send OpenGL commands to another machine via TCP/IP?
-Chris

ChrisBond, that might work on the laptop, because it’s the same video card. The desktop is just expanded.
It also work with GeForce4 cards with 2 outputs: in the display properties, you just see ONE large desktop.

Some interesting stuff…
Isn’t it “normal” that you can only have one ICD ? In the scenario where you have two different cards working together to form one big desktop, what would/should happen if you drag a windowed OGL app to the other monitor ? I don’t see how you can ‘port’ the RC with everything it got to the new ICD ? :\ How does D3D handle this ?..

what would/should happen if you drag a windowed OGL app to the other monitor ?
the window isn’t refresh anymore. Nothing is drawing inside.

Has anyone ever tried to get multimon working by linking to the opengl drivers at runtime?

This could be a solution as long as you were able to make it easy for the customer to find and select which driver to use on the non-primary monitors (the primary monitor’s ICD location is stored in a registry key I think)

I think that you would need to make sure that SetPixelFormat, SwapBuffers and friends are loaded out of driver and not from GDI. There are details on how to do this in the FAQ on this site.

EDIT: I just realized that to implement this idea, you would need a library similar to the one I wrote where I could switch between multiple sets of OpenGL functions quickly. I use it to switch between debug wrappers which checked all calls for errors and unwrapped versions, but it could be extended it to swap between two different ICDs easily enough.

Each window would already have its own RC, so you would only have to call a function to switch the function pointers out.

[This message has been edited by Nakoruru (edited 07-24-2002).]

Originally posted by bpeers:
Some interesting stuff…
Isn’t it “normal” that you can only have one ICD ? In the scenario where you have two different cards working together to form one big desktop, what would/should happen if you drag a windowed OGL app to the other monitor ? I don’t see how you can ‘port’ the RC with everything it got to the new ICD ? :\ How does D3D handle this ?..

The main idea of multiple monitors is to have a larger view of your scene. So normally u are suppose to create one fullscreen window per monitor-card.

I’m pretty sure that the ICD can communicate its information to the second card and have a second OGL window created on the other cards. To me this doesn’t sound like a worth while idea due to the “main idea” I mentioned above.
For GDI graphics, some resources will be wasted but it’s not complicated like for ogl or d3d. Plus, it looks neat.

V-man

Hi, and thanks for all. For thus that use Windows 2000 just try the OpenGL text savescreen, it’s doing what i want. How ?

Thanks

DelNeto

I could not get 3D Text to work (On this computer I have a TNT and an S3), but I got 3D Flower Box to work. Apparently it creates a window the size of the entire desktop and uses Microsoft’s software implementation to draw. You will not be able to get hardware acceleration to work this way however.

I think that 3D Pipes creates two seperate windows, but I would have to look at the source to see (the source for Pipes is available in MSDN, 3D flowerbox should be available as well)

if anyone is interested, apparently this is implemented for Apple. i don’t know from experience, but i was reading about it in the mail archive on the Linux openGL ABI page - sorry no link. it’s on the SGI site.

anyway, under AGL you can request a multi-monitor context - the AGL implementation then intercepts a lot of the GL calls and generally does jiggery-pokery so you can drag a GL window between monitors.

i think it even sorts out which extensions are implemented by all cards on the system, and only returns those from glGetString(GL_EXTENSIONS). this does mean there is an extra layer between your app and the GL driver, though. apparently it is possible to get pointers directly to the driver functions for higher performance.

however, they decided not to allow this possibility for Linux - if you are interested, i think the discussion was provoked by the question of whether extension function pointers returned by glXGetProcAddress() should be context-dependent like they are from wglGetProcAddress(). there seems to be no reason in theory why such a multi-monitor scheme couldn’t be implemented on Windows because extension pointers are context-dependent and RCs take an HDC parameter… but i don’t expect MS to bother.

MS won’t change anything about GL for sure. Why are there still remarks about MS and gl. GL 2 should offer an alternative to the ICD mechanism.

Whether it will… I don’t know since I haven’t gone deep in the docs on that.

V-man

V-man - i seem to remember the GL2 docs say something about moving all the Context related and buffer-swapping code into the core GL - the way they specified it it looked like the funcs will still be called wgl, glX, agl etc, just they are part of the GL2 spec not part of an additional library.

ha- just found this:

5 Standardization of Non-Core Features
Certain operations that are fundamental to OpenGL were left to be defined as part of the
window-specific “glue” libraries for different operating environments. This has made it harder to
specify these operations and has hampered application portability.
We propose that certain key operations be defined as part of the OpenGL 2.0 specification, even
if they have window-specific bindings. These operations include:
• CreateContext
• GetCurrentContext
• GetCurrentDC/Drawable
• MakeCurrent
• StreamSwapBuffers
• AsyncSwapBuffers
Certain requirements should also be defined in the OpenGL specification for creating a drawing
surface (window) and choosing the format of attached buffers. These changes would give
architectural control of key features back to the OpenGL ARB.

and this:

Synchronization
A number of new functions to support synchronization and increased parallelism are defined in
the white paper Asynchronous OpenGL. These functions are required as part of Pure OpenGL
2.0.
SyncAlloc, SyncFree, SyncWait, SyncWaitMultiple,
wglConvertSyncToEvent/wglConvertEventToSync (and something
equivalent for GLX), FlushStream, Fence, QueryFence,
StreamSelect, StreamCopyContext, QueryFenceBackground,
wgl/glxGetVerticalBlankPulse, FenceWait,
wgl/glxGetVerticalBlankRate, wgl/glxGetVerticalBlankCount,
StreamSwapBuffers, wgl/glxAsyncSwapBuffers AllocateStreamFence,
InsertStreamFence, StreamFenceWait, DeleteStreamFence,
TriggerFence

also WGL_ARB_pixel_format is listed as “add” under the extensions lists - so it becomes core openGL too.
so requesting a multi-monitor context could be standardized - also triple-buffering maybe?

do you reckon it is possible to implement this kind of GL2 system using something similar to the current ICD approach? or will MS have to change it if they want to support GL2?

[This message has been edited by vshader (edited 08-10-2002).]

Glad to hear the decision has been taken. I don’t have that sheet on my drive right now. Gone have to download them all sometime.

I just hope that everything will be regarded as being core, and not extensions. I’m not sure what this talk is about extensions with names like GL2_xxxxxxx.

I’m sure that it is possible to add on capabilities to whatever this ICD thing does. Of course, everyone will have to update their drivers.

Nice page about ICD & MCD http://www.leadtek.com/icdmcd.htm

I haven’t seen anything about the details. Microsoft’s version seems to have been removed.

Any clue as to what will happen to all the wgl functions? There’s a whole set of them called I3D. It’s all about dealing with buffers.

V-man