I am curious as to why the OpenGL board has not considered adding specification for dealing with multiple GPUs, or did I miss the boat on that?
On Linux, this is not so much an issue because an application can be programmed to run on a specific device. On Windows, however, it’s such a problem for an application demanding control of having to render or perform computation on multiple GPU without SLI or Crossfire type setup.
Volume rendering for example could use the memory of each GPU to aggregate them to render a larger volume. With SLI or Crossfire setup, memory is often duplicated across the multiple GPU: highly inefficient.
With the arrival of GPGPU, there are plenty of memory hungry applications. PCI-e express 2.0 has advanced sufficient enough to make the video memory a history. However, with system memory limited to DDR2 and maybe DDR3 SDRAMS, we are not going to see that benefit anytime soon. Perhaps AMD Fusion (or Larrabee) would be the life saver here.
One can get away with creating a window on multiple monitors and forcing an OpenGL context on a window of a particular monitor. However, this approach requires that monitors be hooked up on to the back of the cards. The approach is not reliable when standard GeForce or Radeon cards are used, but work fairly well on Quadro or FireGL cards. Hooking multiple monitors to the back or simulating it with KVM switches isn’t the best option either.
It seems like a life saver when NVIDIA released an extension called WGL_nv_gpu_affinity but NVIDIA marketing limited it to their Quadro system, in favor of better margin for the same piece of hardware. Talk about selling ice to the Eskimos!
Direct-X have had the ability to render on to a particular GPU by creating a surface attached to a particular device for many years now.
When will OpenGL anticipate supporting the existence of a multiple GPU system?
Hi
Under windows, you can use a specific graphics card by getting the desired screen and a corresponding dc, like in DirectX. Using multiple GPUs on Windows can be tricky. I saw once someone replacing an ATI card with an nVidia one without removing the ATI driver. When requesting a pixel format, windows returned the ones from the ATI driver + the ones from the nVidia driver, and of course selecting one from ATI with the nVidia card doesn’t work…
I definitely do not want on-card memory to go away any time soon. PCIe is fast, but it’s not that fast. The on-card bandwidth is already the bottleneck in a number of algorithms----no need to exacerbate things!
Sharp_pixel, yes you can do that (as i described regarding multiple monitor) - but it’s not reliable.
Lindley, of course, but that assumes that video is on PCI-e. AMD Fusion is on HyperTransport accessing to system memory. So, if we get the bandwidth of a GDDR on system memory, only then we’ll see the benefit. Can I say maybe 3-5-or-10 years?
PCI-e 2.0 is sufficient enough to fetch memory from system memory to GPU, while the algorithm that’s GPU memory intensive is working on a subset of the video memory. Kinda like the system being an L3 cache like – okay, don’t slam me for saying that!
Either way, the issue I brought up is when will OpenGL recognize that we are in the multiple GPU arena? There isn’t a talk or extension that is leading this way, except of the WGL_nv_gpu_affinity.
I believe that ATI/nVidia are very aware of the problems using MGPU with Windows. I really hope, they agree on some nice API for that. We don’t really need much more than an API providing
a) enumeration of all attached GPUs
b) creation of a rendering context on specific GPU(s)
c) tools to copy/duplicate/share data (be it textures, vbos, fbos etc…) between GPUs
d) change opengl behaviour to minimize system memory usage (I don’t want to pay twice the memory if I use the same texture in two contexts).
e) controlling SLI setups manually (i.e. how are the results of the outcome of different GPUs combined, if needed at all)
I guess, d) is most challenging here. But we’ll hit this very problem for single-GPU setups anyway as soon as the first 2GB cards hit the market and we actually fill them to their limits
I hoped too that stereoscopic control would be available with an API. Instead, Nvidia insists on develepping a specific driver that is (badly) customized for each relevant game on the market, instead of providing an API so the application could at least choose between alternate (LCD shutter glasses) or simultaneous stereo frames (everything else, from anaglyph to passive polarized and mirrored setups).
By the way, dual GPUs would be great for stereo 3D.
So I will not hold my breath on this, especially as the market for multi GPU systems is pretty small (and currently absent from console market).
