有没有办法在多 GPU 环境中以编程方式选择渲染 GPU？（视窗）

发布于 2024-11-14 23:52:54 字数 2385 浏览 4 评论 0原文

问题

我有一个 OpenGL 应用程序，它将在具有不同多 GPU 配置（可能还有不同的 Windows 版本，从 XP 到 7）的机器上运行。是否有通用方法来选择将充当独立于 GPU 组合的 OpenGL 渲染器的特定 GPU（例如 NVIDIA + NVIDIA、NVIDIA + AMD、NVIDIA + Intel 等）？它必须是一个可以从应用程序代码（即直接在 C++ 中）应用的解决方案，或者可以从应用程序调用的脚本，无需最终用户干预。

以下是我为寻找解决方案而进行的多项测试的详细信息，从非常具体的情况开始，但也许有一个解决方案可以在所有或大多数情况下工作。

有没有可靠的方法来强制哪个GPU进行OpenGL渲染？

任何提示将不胜感激。提前致谢！

尝试了

使用两个 NVIDIA Quadro 的 Windows XP 64

测试组合了两个 Quadro 卡

Quadro FX 1700 + Quadro FX 570
Quadro FX 1700 + Quadro FX 540
Quadro FX 1700 + Quadro NVS 285

在 Windows XP 64 下使用相同的驱动程序（版本 275.36） -bit，我通过各种方法取得了相对成功，例如：

让司机决定。
仅当两张卡使用相同的驱动程序并且它决定使用所需的卡时，此解决方案才有效。所以它太具体而且可能不可预测。
在让驱动程序决定之前，使用 NVAPI 更改代码中的驱动程序设置。
使用此解决方案，理论上可以让驱动程序按照我的意愿做出决定，但这很困难，需要两张卡使用相同的驱动程序，并且并不总是有效（对于 FX 1700 + NVS 285，它不起作用）。
更改主屏幕。
这会导致应用程序默认在选定的主屏幕中打开。该解决方案仅适用于 FX 1700 + FX 570 组合。对于 FX 1700 + FX 540，渲染器取决于驱动程序设置，与主屏幕无关；对于 FX 1700 + NVS 285，渲染器始终是 FX 1700。
当窗口位于特定屏幕时创建 OpenGL 上下文.
可以在所需的屏幕中创建窗口，与主屏幕无关，但它与上述解决方案具有相同的问题。
创建 OpenGL 上下文，仅启用所需显卡中的屏幕，然后启用其他屏幕。
这是我发现使用 NVS 285 作为渲染器的唯一方法，但它很丑陋，而且我不知道它是否可自动化或是否在所有情况下都有效。
尝试使用 WGL_NV_gpu_affinity 扩展程序选择渲染 GPU。
通过 FX 1700 和 FX 570 的组合，扩展报告两个 GPU 兼容，我可以将渲染限制为仅其中之一。对于 FX 1700 + FX 540 对，扩展仅报告一个兼容的 GPU，这是驱动程序决定用于 OpenGL 渲染的 GPU。对于 FX 1700 + NVS 285 组合，始终仅报告 FX 1700（我认为 NVS 285 不支持此扩展，因为如果它是唯一使用的卡，则扩展仍然不会报告）。< /p>

采用 Intel 和 AMD 的 Windows 7 64

该系统运行 Windows 7 64 位，显卡为一张 Intel HD Graphics 2000（集成在 CPU (Sandy Bridge) 中）和一张 AMD Radeon HD 6450。在所有情况下，渲染均适用于两者屏幕，但渲染 GPU 根据某些变量而变化：

如果主屏幕连接到 AMD 并且在此屏幕中打开窗口，则 AMD 是渲染器。
如果主屏幕连接到 AMD 并且在另一个屏幕中打开窗口，则渲染器是“GDI Generic”，速度非常慢。
如果主屏幕连接到 Intel，则 Intel 是渲染器，与窗口打开的位置无关。

对于这个系统，我还尝试了OpenGL 论坛中提出的解决方案。 TL;DR：选择 OpenGL 使用的驱动程序是一种 hacky 方法，因此它可以在使用不同驱动程序的 GPU 之间进行选择，但不能在使用相同驱动程序的卡之间进行选择。我得到以下结果：

如果主屏幕连接到AMD，我可以选择任何GPU作为渲染器。
如果主屏幕连接到 Intel，我可以选择 Intel 作为渲染器（无用，因为这是自动的），但如果我尝试选择 AMD，则会出现错误；我认为这可能是驱动程序中的一个错误。

原文

Question

I have an OpenGL application that will run in machines with diverse multi-GPU configurations (and possibly different Windows versions, from XP to 7). Is there a general way to select the specific GPU that will act as the OpenGL renderer independently of the GPU combination (e.g. NVIDIA + NVIDIA, NVIDIA + AMD, NVIDIA + Intel, etc.)? It has to be a solution that can be applied from application code, i.e. directly in C++ or a script that would be called from the application, with no end-user intervention.

Below are the details of several tests I have done to try to find a solution, starting with very specific cases, but maybe there is a solution that can work in all or most cases.

Is ther any reliable method to force which GPU does the OpenGL rendering?

Any hint will be very appreciated. Thanks in advance!

Tried possible solutions

Windows XP 64 with two NVIDIA Quadro

Testing with combinations of two Quadro cards

Quadro FX 1700 + Quadro FX 570
Quadro FX 1700 + Quadro FX 540
Quadro FX 1700 + Quadro NVS 285

using the same driver (version 275.36) under Windows XP 64-bit, I have had relative success with various methods, such as:

Letting the driver decide.
This solution is only good as long as both cards use the same driver and it decides to use the desired card. So it is too specific and maybe unpredictable.
Changing driver settings in code with NVAPI before letting the driver decide.
With this solution it is in theory possible to make the driver decide as I want, but it is hard, needs that both cards use the same drivers and doesn't always work (with FX 1700 + NVS 285 it doesn't work).
Changing the main screen.
This has the effect that the application opens in the selected main screen by default. This solution has worked on its own only with the FX 1700 + FX 570 combination. With FX 1700 + FX 540 the renderer depends on the driver settings, independently of the main screen, and with FX 1700 + NVS 285 the renderer is always the FX 1700.
Creating the OpenGL context when the window is in a specific screen.
The window can be created in the desired screen, independently of which is the main, but it has the same problems as the above solution.
Creating the OpenGL context having enabled only the screen in the desired graphics card and then enabling the other/s.
This is the only way I have found to use the NVS 285 as the renderer, but it is ugly and I don't know if it is automatizable or if it would work in all cases.
Trying to select the rendering GPU using the WGL_NV_gpu_affinity extension.
With the combination of the FX 1700 and the FX 570 the extension reports both GPUs as compatible and I can limit the rendering only to one of them. With the FX 1700 + FX 540 pair the extension reports only one compatible GPU, which is the one the driver decides to use for OpenGL rendering. With the FX 1700 + NVS 285 combination, only the FX 1700 is reported, always (I suppose that the NVS 285 does not support this extension, because if it is the only card in use it is still not reported by the extension).

Windows 7 64 with Intel and AMD

This system runs with Windows 7 64-bit and the graphics cards are one Intel HD Graphics 2000 (integrated in the CPU (Sandy Bridge)) and one AMD Radeon HD 6450. In all cases rendering works on both screens, but the rendering GPU varies depending on some variables:

If the main screen is connected to the AMD and the window is opened in this screen, then the AMD is the renderer.
If the main screen is connected to the AMD and the window is opened in the other screen, then the renderer is "GDI Generic", which is very slow.
If the main screen is connected to the Intel, then the Intel is the renderer, independently of where the window is opened.

With this system I have also tried a solution proposed in the OpenGL forums. TL;DR: it's a hacky method to choose the driver used by OpenGL, so it can choose between GPUs that use different drivers, but not between cards that use the same driver. I obtained the following results:

If the main screen is connected to the AMD, I can choose any GPU as the renderer.
If the main screen is connected to the Intel, I can choose the Intel as the renderer (useless, as this is automatic), but I get an error if I try to choose the AMD; I think this may be a bug in the driver.

分享到QQ

分享到微博