Hi there,

Due to how different video card manufacturers handle OpenGL (especially with regards to the presence of multiple video cards in the system), I am having to write some code that handles OpenGL based on the particular type of video card(s) that it will make use of in my game engine.

Generally speaking, nVidia and ATI/AMD are the only manufacturers of "true" video cards if I am correct? I know motherboards, laptops and such often have their own built in "fake" video cards (I'm assuming I won't have any problems with those since there is only one(?) of them anyway), so if nVidia and ATI/AMD are all that I need to worry about aside from that, then this should be relatively easy.

I can't think of any other video card manufacturers than nVidia and ATI/AMD off the top of my head.

Is there a list of possible values for glGetString GL_RENDERER and GL_VENDOR, or does OpenGL retrieve this information from somewhere else?

I have three ATI/AMD video cards hooked up to this system. Initialization of my game engine currently logs the following:

0056 Querying OpenGL version information...0057 Renderer: ATI Radeon HD 45500058 Vendor: ATI Technologies Inc.0059 Version: 3.3.10317 Compatibility Profile Context

When I initialize my game engine on my laptop, I get this:

0048 Querying OpenGL version information...0049 Renderer: Intel Cantiga0050 Vendor: Intel0051 Version: 2.0.0 - Build 7.15.10.1829

This is what I mean by "fake" video cards (I'm sure there is a technically correct term for this).

So basically speaking, I need to know if there are any other considerations I need to take into account aside from nVidia and ATI/AMD's differing support for OpenGL, which is under the assumption that there are no any other types of "true" video card manufacturers aside from them.

Also, is it correct that you can't mix multiple video cards from nVidia and ATI/AMD in a system? If so, does this also extend to the video cards' model, series or GPU?

Any feedback would be appreciated.

Thanks,
- Sig

i believe the term you are looking for is "integrated". I know nvidia makes integrated cards as well (and I believe they are decent), I think ATI might too. why are you discounting them? that output shows your laptop is Opengl 2.0 capable (unless I'm missing something).

I think some high end motherboards allow you to combine to cards from different manufacturers. I don't know much about this though.

Quote:Original post by PATrainwreck
i believe the term you are looking for is "integrated". I know nvidia makes integrated cards as well (and I believe they are decent), I think ATI might too. why are you discounting them?

I'm not discounting them.

OpenGL capability isn't the problem I'm trying to tackle, but rather differences in OpenGL implementation in general.

If you restrict yourself to only functionality available in OpenGL 2.0, then the same program should work on every computer capable of at least OpenGL 2.0. If you want to use the features in OpenGL 3.3, then only 3.3 capable systems can run it. The basic OpenGL functions in gl.h/opengl32.lib will probably run on anything in the last 10 years or more. OpenGL 2.0 should run on anything reasonably modern. 3.x will run on NVidia/AMD from the last years if they have updated drivers.
So choose the version you want that runs on all your target hardware.

As for differences in the implementations of the same GL version, it's hard to say. You just have to test your program on both NVidia and AMD if you want to be sure.

It is possible to have several graphics cards from different vendors, but I believe it can have some problems and I don't know anyone who actually does it. It's not something you need to worry about when making a game.

Basically one of the issues I am trying to handle is that nVidia and ATI/AMD video cards share data between one another differently (especially with regards to Windows and their crappy OpenGL support). When using multiple video cards, I believe nVidia cards keep a copy of texture data and such one each card. However, ATI/AMD video cards don't do this, and you need to generate textures etc... for each video card. Otherwise, trying to draw a texture that is stored on a different video card will not work.

So basically I need to be able to figure out if the multiple video cards OpenGL is using are capable of sharing data between one another.

Quote:Original post by Sigvatr
Basically one of the issues I am trying to handle is that nVidia and ATI/AMD video cards share data between one another differently (especially with regards to Windows and their crappy OpenGL support). When using multiple video cards, I believe nVidia cards keep a copy of texture data and such one each card. However, ATI/AMD video cards don't do this, and you need to generate textures etc... for each video card. Otherwise, trying to draw a texture that is stored on a different video card will not work.

So basically I need to be able to figure out if the multiple video cards OpenGL is using are capable of sharing data between one another.

There is no problem with OpenGL support on Windows, and if there is it has nothing to do with Windows as the OpenGL support is in the driver. Also, what you mention about textures is not an issue.

Iff you do something fancy that targets high-end systems with multiple workstation GPUs for tens of thousands of dollars and your only concern is speed, then and only then might you want to investigate multiple graphics cards working together in perfect harmony. Normally you just create an OpenGL context and it just works, you don't need to care about where the texture is stored.

If you are specifically concerned about multiple separate graphics cards, and need your game to work on any monitor, then the following page has some information: http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html.
Basically, you can't do anything about it at all except create your window centered on the monitor you want to play on and let the driver do what it feels is best, unless you buy the $4000 Quadro model where you can use an extension to control which GPU handles which context. This still doesn't have anything to do with a texture within a context however. More importantly, it has nothing to do with games as no one plays games with those cards.

Quote:Original post by Erik Rufelt

I've already read through this document thoroughly and I am not as pessimistic about implementing multiple monitor/video card support as you are. The bulk of my multiple monitor/video card support in my game engine is already mostly functional. The only problem I'm having is providing the engine with the capability of discerning whether or not it needs to manually share data between multiple video cards or if the video cards know how to do this.

Although multiple video cards are relatively uncommon at the moment, I want my game engine to be able to support them in the case that they do become commonplace one day. It already has become not unusual for desktop PCs to have two or more monitors, and some video cards these days contain more than a single GPU (I don't know what kind of implications this has from a programming perspective).

For the record, I have managed to successfully display multiple OpenGL contexts and scenes on all of my desktop's monitors (there are 5, connected to 3 video cards). However, these video cards are manufactured by ATI/AMD, so I do not know what would happen if I ran the engine in its current incarnation on a system with multiple nVidia video cards and monitors.

As far as I am currently aware, the only GPUs (integrated or not) that I am aware of are Intel, nVidia and ATI/AMD (AMD manufactures both integrated and external GPUs). If there are no other brands of GPUs, then most of my questions have been answered already.

Everything in OpenGL belongs to one context. If enabled with wglShareLists or wglCreateContextAttribsARB, then two contexts can share data between them. This has nothing to do with the graphics cards, which is handled by the driver.

I agree that multi-monitor support is excellent, I just fail to see exactly what you're asking. There is no such thing as manually sharing data, unless you are referring to when sharing between contexts fails. If you use wglShareLists and it returns FALSE, then nothing is shared between the two contexts.

Perhaps I am misunderstanding you. When you say different graphics cards, do you mean different contexts created on different cards?
Nothing will ever be automatically shared between different contexts unless you ask for it. If sharing fails, then you have to manually create the same texture on each context, if the same texture is to be used on both contexts.

If you have one NVidia and one ATI card and have one context on each, then sharing between them will always fail according to the documentation for wglShareLists. That page, along with the documentation for pixel formats and http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt has some more information on that.


As for support, I have tested on NVidia and Intel integraded graphics with the following results:

I have two NVidia cards and three monitors. Unless you have a Quadro then NVidia does not support choosing which card is used for a context (perhaps all are used together). The same OpenGL window can be dragged across all monitors and it works just the same. If the window is dragged to the monitor which does not belong to the same card as the primary monitor, then there is an extra overhead of a few ms, I guess from a transfer of the image across cards or similar. It never matters what HDC or window is used to create the context.

I also have a laptop with integrated Intel graphics. The primary monitor has good OpenGL performance, but a secondary monitor connected to the laptop has a bit worse performance. However, if the secondary monitor is made 'primary' in the monitor control panel then that has good performance instead, while the builtin display has worse performance. It never matters what HDC or window is used to create the context.

Because of these limitations, you can't really do more than create your game window on the monitor your user wishes to play on. It sounds however like you want to run your game on multiple monitors at the same time. Is that correct?
If you are designing such a game then I understand your concern, but according to what I have read you can't really do anything other than creating one window on each monitor.
You shouldn't need to handle this any differently on different graphics cards however, as that is taken care of by the driver. You just need to check the return value if you try to use sharing between contexts.

It is also possible to use the same context and SwapBuffers to multiple windows. The documentation for the wgl* functions has information on this. In particular, you need to select a compatible pixel format in the window you swap to. This is also likely to not work if you have two graphics cards of different vendors. Again, check the return values and display an error or create a separate context for a window if it fails.

Quote:Original post by Erik Rufelt
Unless you have a Quadro then NVidia does not support choosing which card is used for a context (perhaps all are used together).

Actually, this is a relatively simple problem to solve; you simply need to specify the HDC that the window your OpenGL context will be associated with and the video card to be used with this context is determined by the position of your window (it works for me, although I might be technically incorrect).

Quote:It is also possible to use the same context and SwapBuffers to multiple windows. The documentation for the wgl* functions has information on this. In particular, you need to select a compatible pixel format in the window you swap to. This is also likely to not work if you have two graphics cards of different vendors.

I have considered using the above method when I first encountered difficulties sharing data across contexts/video cards. I have not tried it yet, although I am dubious about a few things, specifically which video cards are storing/handling what, the case you pointed out where the video cards are from different vendors and also how to handle different scenes on each monitor/context (ie, if one context does not need to perform a render when another does).

Any other thoughts?

If you are interested in my findings and successes so far, then I can provide you with information on how I achieved it, because you seem to be interested in this sort of thing.