[newzhunter]

Graphics sub-systems with numerous graphics processing units (GPUs) have existed for more than one decade and in the recent years leading developers of graphics processing units – ATI, graphics business group of Advanced Micro Devices, and Nvidia Corp. – resurrected graphics boards with two chips. So far multi-GPU operation relied mostly on drivers from ATI or Nvidia. But the recent OpenGL extension from ATI allows game developers to optimize their titles for multi-chip rendering.

The new “WGL_AMD_gpu_association” provides a mechanism for applications to explicitly use the GPU resources on a given system individually. By providing this functionality, a driver allows applications to make appropriate decisions regarding where and when to distribute rendering tasks. In particular, when multiple GPUs are present, a context can be created for off-screen rendering that is associated with a specific GPU. This will allow applications to achieve an app-specific distributed GPU utilization.

WGL_AMD_gpu_association is currently supported by ATI Catalyst 9.6 beta drivers. Applications have to support the extension to gain performance benefit out of multi-GPU configurations.

It is interesting to note that the forthcoming Microsoft DirectX 11 application programming interface (API) does not have any multi-GPU specific optimizations.

ATI to Boost Efficiency of Multi-GPU Operation in OpenGL - X-bit labs

Share|

[Guilherme]

Originally Posted by xbit-labs

It is interesting to note that the forthcoming Microsoft DirectX 11 application programming interface (API) does not have any multi-GPU specific optimizations.

Unnecessary open source fanboy/ignorant comment from Xbit.

The responsibility for multi-GPU doesn't have to lie on graphics API or any other software, it has to be at the hardware level, being transparent to the API or the game.

Multi-GPU has to evolve to a hardware, software-transparent level, so the workload can be addressed directly by an on-board command processor. This is the only way to maximize efficiency and to avoid driver overheads.

If Microsoft starts to implement some routines in DirectX, or if Khronos Group accept this extension as a standard, graphics card guys will never push to the right way.

Multi-GPU will never engage while is a software bound solution.

Microsoft is right and so Khronos (while not accept this workaround extension as standard)

[lennardseah]

bah start innovating not working on power zapping tech

[power666]

Microsoft doesn't allow any vendor specific features to be exposed by the DirectX API. Thus all multi-GPU functionality has to be shoe horned into the driver underneath the DirectX API. From a conceptual standpoint, the driver has to behave in a more generic fashion for allocating hardware resources. While this can lead to a suboptimal performance situation (poor multi-GPU scaling), it does not take additional time for a programmer.

On the other hand, AMD's new OpenGL extension allows for a finer grain of optimization by the programmer. The obvious downside is programming effort and the expectation of having a multi-GPU system. If a small percentage of the market has a multi-GPU set up, no one will take advantage of this extension regardless of how much of a performance boost it can provide: a chicken and the egg scenario.

I am curious if this new extension explicitly requires a multi-GPU setup to function. The graphics driver maybe able to context switch the workloads for multi-GPU rendering on a single GPU but with a massive performance hit.

[BaLtO]

Originally Posted by Guilherme

Unnecessary open source fanboy/ignorant comment from Xbit.

The responsibility for multi-GPU doesn't have to lie on graphics API or any other software, it has to be at the hardware level, being transparent to the API or the game.

Multi-GPU has to evolve to a hardware, software-transparent level, so the workload can be addressed directly by an on-board command processor. This is the only way to maximize efficiency and to avoid driver overheads.

If Microsoft starts to implement some routines in DirectX, or if Khronos Group accept this extension as a standard, graphics card guys will never push to the right way.

Multi-GPU will never engage while is a software bound solution.

Microsoft is right and so Khronos (while not accept this workaround extension as standard)

It's impossible for Multi-GPU to evolve to a hardware level. Multi-GPU is like Multi-Core, it's different from stuff like HyperThreading. The applications need to address and make use of Multi-GPU so there's no concurrency problems.

Single GPU and Multi GPU have different set of concurrency problems.

Hardware is there. You need the firmware, drivers, API to control it. If it's totally hardware, there will be much AI in it, and it might cause more overheads.

Multi-GPU performance, will come from both hardware and software, with OpenGL or DirectX in between.

[Guilherme]

Originally Posted by BaLtO

It's impossible for Multi-GPU to evolve to a hardware level. Multi-GPU is like Multi-Core, it's different from stuff like HyperThreading. The applications need to address and make use of Multi-GPU so there's no concurrency problems.

Single GPU and Multi GPU have different set of concurrency problems.

Hardware is there. You need the firmware, drivers, API to control it. If it's totally hardware, there will be much AI in it, and it might cause more overheads.

Multi-GPU performance, will come from both hardware and software, with OpenGL or DirectX in between.

With all respect, but, did you ever heard anything about Hydra?

Computing graphics is a data-parallel concept of parallelism (mutli-core CPUs lie more - not always - on task parallel), it's the easiest way of addressing workload. Ask yourself how things such ATI Ultra Threading Dispatch Processor or Nvidia Thread Processor works, they don't depend on driver neither API.

I agree it is hard to make a hardware level workload addressing while exists fixed functions in the rendering pipeline (but not theoretically impossible), but the pipeline is evolving a lot and that will be much less complicated soon, so, why care about API support now?

There is no need to bring data parallel workload addressing to the hands of developers. Today developers don't need to care about when and how a thread processor address the various types of shaders across the stream processors. That is the way multi-GPU had to go.

If graphics industry transfer that responsibility to developers, the concept of multi-GPU will never engage (like now).

I'm not an engineer, but it is clear: game developers has to care about games, not when and how to address frames to cards. Finding a way to divide the load across the cards is the role of ATI and Nvidia engineers, not soft houses.

[BaLtO]

And further info on the extension
New workstation class applications, like CAD, CAE, DCC (digital content creation), now make use of this extension to determine what types of GPUs are in a given system (computer) and pick which contexts to allocate on each GPU. This allows a workstation application to process multiple images and datasets simultaneously and combine the final image for display.
AMD advances OpenGL - new extension binds | Architosh

Some applications need this to control individually to be efficiently. Yes, you would split, using microcontroller, but that might not be too optimal for the application.

The Hydra one seemed to be catered more for game instead. And also might add to the cost too.