Multiple Monitors

Well actually, not multiple monitors, but rather multiple 3D accelerators.

There appears be MUCH confusion (and little support) in the industry on what to do if a machine is hosting multiple 3D accelerators.

The most common solution is to only use one (the primary) accelerator - even if there are many available.

(((Ironic Note: In days past, you would have to DISABLE the other cards in order to run OpenGL apps on the primary display - this appears to be fixed nowadays - and now Vendors are using this bug-fix to claim “Multi-Monitor OpenGL Compliance”. Geeze, this just means that they fixed that bug, it does NOT mean that OpenGL can be accelerated across the multiple monitors. This is way confusing.)))

Another solution is spanned displays (i.e. Parhelia) that uses one accelerator to drive one large “logical” display that spans across mutliple “physical” monitors. However, this approach slams that single accelerator with a huge mount of work.

Call me naive, but it seems like it would be better to take advantage of any and all 3D acceleration hardware that is available in a system. But this is not done. Why?

Is this a problem that can NEVER be solved?

What are the technical issues involved here?

Is this an OpenGL issue, or an ICD issue, or simply an application issue (doubtfull)or is it a wacky combination of these?

Would solving this problem require some sort of new “Industry Standard”?

Is there anyone out there interested in finding a solution to this issue?

Comments?

Hm just curious: why would you need more than 1 3d accel per machine?

-Lev

You get multiple accelerators when you install multiple graphics cards.

For example, suppose you want to drive 4 monitors to create a panoramic display for a sim or RPG game. This is more common now that LCD monitors are the norm.

If you install 2 dual-head cards, you end up with 2 accelerators.

Presumably, you’re looking for the ability to either render to both by switching back and forth, or to render to only one GL context and have it dispatch the data appropriately.

If it is the latter, that’s, pretty much, impossible. Graphics hardware, to say nothing of OpenGL implementations and the GL Spec itself, is simply not designed to provide this kind of functionality. The last card I recall that had the ability to really communicate with another at any real speed was either the Voodoo 5 or the Voodoo 2.

The former is, in theory, possible. But, it isn’t doable today.

Is this an OpenGL issue, or an ICD issue, or simply an application issue (doubtfull)or is it a wacky combination of these?

Well, besides being a fundamental hardware-communication issue? It’s probably quite a bit of all of them.

Assuming you’re using the multi-RC approach, you will have to deal with the ICD issue. Attempting to bypass this issue is almost impossible; if the drivers are only designed to recognise one card, there won’t be functions to pick one. So, you’re going to need to modify the ICD mechanism. Because each GL command will have to be funneled to a completely different implementation, this could cause some function-call overhead.

Once you’ve got an ICD mechanism (and appropriate drivers for each graphics card) that lets you pick which one to render to, you have to get one render context for each. Then, you have to render to each context, duplicating the textures and vertex data for each (sharing between two RC’s from 2 implementations is, for all intents and purposes, impossible).

Note: D3D already has a mechanism to select which card to use. However, I’m not sure if it allows you to use both at once. And, even if it does, I am sure that you can’t share textures or vertex data across them.

This is more common now that LCD monitors are the norm.

Since when? LCD monitors are still expensive (~1.7 * a CRT), and they still have visual-quality issues. Also, what does the “commonality” of LCD monitors have to do with multiple displays?

[This message has been edited by Korval (edited 03-19-2003).]

Ah, mental meat, thank you Korval!

Yes indeed, I was thinking of rendering only one GL context and having it (what?) dispatch appropriate data across all 3D accels.

HOWEVER, you bring up a very interesting new concept, that I have never heard of.

Originally posted by Korval:
[b]…the ability to either render to both by switching back and forth

…in theory, possible. But, it isn’t doable today.
[/b]

Can you expand on this “switching” idea?

If this is not doable today, what would it take to make it doable tomorrow?

Originally posted by Korval:
…Since when? LCD monitors are still expensive (~1.7 * a CRT), and they still have visual-quality issues. Also, what does the “commonality” of LCD monitors have to do with multiple displays?

Oops, you caught me Korval. LCD monitors are indeed NOT the “norm” today - I should have said that LCD monitors are becoming “more common” today.

The huge size of CRT monitors discouraged the use of multiple monitors on a desk. But the advent of smaller lighter LCD monitors is increasing the adoption of multiple monitors, thus multiple vid cards, thus multiple 3D accelerators.

Also of note; I have read secondary reports that the AGP 2.0 spec allows for multiple AGP ports on a mobo - this needs confirmation, tho it sounds credible.

Also, due to mass market opportunities in flat screen televisions, LCD manufacturers are working hard, and with gradual success (Mitsubishi), to decrease the latency inherent in today’s LCD monitors.

My point here is simply to emphasize the relevance and importance of this discussion.

So let us look toward the future - please tell us more about your switching idea.

Can you expand on this “switching” idea?

If this is not doable today, what would it take to make it doable tomorrow?

Well, you make 2 render contexts, one for each physical card. Then, you render half the scene to one, and the other half to the other.

But, like I said, even if you change the ICD mechanism and so forth, the textures and other server-side state data cannot be shared between these two render contexts.

So if you create 2 render contexts, you imply that it is currently possible to specify which hardware that context should be rendered on?

If true, and the only remaining roadblock is as you stated:

the textures and other server-side state data cannot be shared between these two render contexts.

Then perhaps the hardware may give us a solution?

What AGP does is to allow the video
processor to access the [b]system memory[/b] for 
other tasks that require memory, such as 
[b]texturing[/b] and other 3D operations. The 
theory is that this memory isn't as crucial 
as the frame buffer, and doing this design 
means that higher-end video cards can be 
made more inexpensively by saving on the 
cost of dedicated video card memory that is 
only being used for these operations.
[i]http://www.pcguide.com/ref/mbsys/buses/types/agpMemory-c.html[/i]

But, you may ask, where does this get us when we can only use one AGP port? Soon we will be seeing multple AGP ports!

Finally, AGP 3.0 adds some new
capabilities, including isochronous mode
operation for improved data streaming and—
get this—support for multiple AGP 3.0
ports, with multiple AGP devices per port, in a single system.
[i]http://www.tech-report.com/reviews/2002q4/gf4-8x/index.x?pg=2[/i]

Thoughts?

[This message has been edited by The_Donz (edited 03-21-2003).]

[This message has been edited by The_Donz (edited 03-21-2003).]

[This message has been edited by The_Donz (edited 03-21-2003).]

I, for one, would love to see that ICD limitation gone or bypassed. I think that it is definitely useful to be able to maintain two independent hardware-accelerated device contexts. Sure, they can’t automagically share server state but that’s something you can manage at the application level. Gimme.

If you really wanted multiple video cards to be transparent, then I suppose you can do it with multi-AGP. I suppose the server-side video memory would contain frame buffer and texture memory would really be a big cache (I think 3Dlabs cards already do this), but you’d probably have to deal with all sorts of silly coherency issues which would make it all pretty unacceptably complicated and/or slow.

-Won