View Full Version : OpenGL With multiple video cards
06-22-2004, 09:49 AM
This is my first post to this great forum.
I noticed that I can drag an openGL application across multiple monitors (run by different video cards) and it is still accelerated, while direct3D is not (you choose the device you want acceleration on).
I am wondering what architecture is used to make this possible. When does the openGL driver for each video card take over? Is a full frame buffer created on each card?
Does anyone have any ideas on how I could target a single card? I would like to target each card individually like in Direct3D, so I can get acceleration accross all the monitors (I am doing research on an 8 monitor system).
Right now I seemed to be limited by some total framebuffer size, after which software acceleration takes over. What I want to do is have a small frame buffer on each card. Creating multiple contexts doesn't seem to help.
Thanks in advance for any comments or ideas!!!
Ilab, Univeristy of Calgary
06-22-2004, 11:33 AM
As a partial answer. I noticed that when I use single buffering, I am able to use double the size of framebuffer (I can almost get full screen on 8 display at 1024x768). Does this mean this is purely a memory issue?
I am using two quadro NVS 400 cards (each have two dual-head GPUs). I can't see how it would run out of memory since each GPU has 32MB.
Anyway, any comments on how OpenGL is even accomplishing this would be great.
06-22-2004, 01:50 PM
In fact you can thank the nvidia drivers in this case, it has nothing to do with OpenGL (directly).
With cards from different manufacturers, you loose any accelerated GL stuff.
Indeed, it seems to be related to video memory.
for a rgba32+z24+stencil8 framebuffer, on each card you get :
1024*768*(4+4) * 4 = 24 MB !!
So for double buffering, it is close to 50 MB, so it does absolutely not fit in 32. Maybe try 16bit color and 16bit zbuffer without stencil.
06-22-2004, 03:08 PM
The Quadro NVS cards are pure 2D displays.
To answer your question, an OpenGL contexts are always bound to a window, and which card "takes over" the rendering is determined by the card that displays that window.
With many displays from the same vendor and with the exact same functionality the driver can, in theory at least, "multicast" all commands and data sent through an OpenGL context, so that it is possible to accelerate rendering to a window that spans two (or more) displays.
However, in your special case, it's just a software renderer that splits its front buffer to multiple displays.
06-22-2004, 03:09 PM
>for a rgba32+z24+stencil8 framebuffer, on each >card you get : 1024*768*(4+4) * 4 = 24 MB !!
That sounds right, but it sounds like you are talking about the size of the entire buffer (for all 8 monitors). This is at the heart of my question. Where is this huge framebuffer? Is it in system memory? or does it exist on each card?
What I would think they would do would be to store only the nessesary part of the framebuffer on each card (so for a dual-head GPU it would be about 6MB at 1024x768).
This makes me wonder what is being done on each card. If the huge framebuffer is on each card, is it rendering the whole scene on each card?
Thanks in advance!
06-23-2004, 09:51 AM
Thanks for your reply zeckensack.
>The Quadro NVS cards are pure 2D displays
I know these aren't the greatest cards for 3D, but I am able to get decent openGL/Direct3D acceleration.
>With many displays from the same vendor and
>with the exact same functionality the driver
>can, in theory at least, "multicast" all
>commands and data sent through an OpenGL
>context, so that it is possible to accelerate
>rendering to a window that spans two (or more)
This multicasting appears to be happening on my setup, its just that it drops to software acceleration when the window gets too big (about 2048x1536. When I go to single buffering I can get the window to span almost all 8 monitors (4096x1536). Unfortunately the card doesn't seem to support 16 bit accelerated modes.
In any event, would you agree that the entire scene is being rendered on each card? Do you think this is a driver specific thing, or that all drivers do this?
If this is the standard way of doing things, then I am interested in intervening somewhere to make this more efficient. Is it possible to get access to a single monitor's driver myself?
For Direct3D I actually wrote my own d3d9.dll that creates small framebuffers on each card and multicasts calls to each card. My framerate is hardly affected when I render to 4 GPUs vs. 1 GPU. I would like to do something similar for OpenGL, but I would need to be able to access each GPU on its own.
Anyway thanks for everyones comments so far, and I would love to hear any more ideas. I am thinking of looking at Mesa since it is an openSource implementation of OpenGL.
ILab, University of Calgary
06-23-2004, 11:25 AM
>for a rgba32+z24+stencil8 framebuffer, on each card you get : 1024*768*(4+4) * 4 = 24 MB !!
Really, I am speaking about only one card.
width*height*(rgba bytes+ zb and stencil bytes) * 4monitors = framebuffer size for one card.
What I missed was that you said is has 32MB per GPU, so 64MB for each card, with a grand total of 128MB.
So one card has 64 MB, a double buffer GL full window needs 48MB, maybe we have to had the desktop 12Mb, 60M, mmh, that is pretty close.
Have you tried openning 2 half size windows ?
Are you absolutely sure you can not get hardware acceeration in 16 bits mode (put the desktop in 16bits, get a PFD with 16bit color 16bit z and no stencil, it should work) ?
06-23-2004, 01:52 PM
I have tried creating seperate contexts for each GPU, but this doesn't work. As soon as I pass some total framebuffer size they stop being accelerated.
Here's an example. If I have just one card (desktop of 2048x1536), I can get acceleration over almost all 4 monitors. Adding the second card makes no difference though, I am still limited to the same size. I can move that window around the entire desktop, but I can't make it any bigger.
06-24-2004, 03:07 PM
Im not sure, but this guys maybe can help you...
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.