Hi JeanClaude,

Unfortunately it is not possible to load balance or distribute processing to multiple graphics cards.
The main reason being the memory bandwidth intensive nature of vMix. It has to transfer large amounts of
video to the GPU every second and having to transfer this to multiple cards simultaneously would negate any benefit
of load balancing.

For what you are doing, vMix should not need much GPU power anyway, but unfortunately the NVS420
is is quite slow compared to current mid range GeForce cards.

Regards,

Martin
vMix

Might be me, but personaly, I don't see how the vast majority of users could be negatively impacted by the current architecture of Vmix. Most users build their system specificly for Vmix. Since it doesn't need that much GPU power, I don't see why anyone would build a multi GPU system. Since a simple gaming card will do, most people will pick that option.

Isn't it an option to swap one Quadro card for a more powerfull one?

Jean-Claude,

We have looked into what you are saying, however what you are suggesting is not actually how multi GPU workloads work in the real work.
While you are correct there can be direct data transfer between the GPUs, there is a heavy penalty for doing this with a
large amount of data (such as live video) and provides no performance benefit for what vMix is doing.

vMix is certainly not running in "compatibility mode". There just isn't the sort of API you are thinking of.

Have a look at the benchmarks for the NVS420 and you will see the performance is quite low compared to modern graphics cards.
Also, most graphics cards today support up to three simultaneous outputs. So you could look
at one powerful three output GeForce and perhaps a second card for a fourth display.

Regards,

Martin
vMix

Martin,

Yes, you are quite right, the benchmarks for the NVS420 are quite low relative to other graphics cards that are today targeted for high-end gaming. However this is not what is causing the lack of performance in our system. The issue is that VMIX isn't taking advantage of the available GPU processing that's available to it in our system. This is what is causing the problem.

For example in our system with two NVS 420s installed, when we go to the main settings panel in VMIX under the Performance section, we see six NVIDIA Quadro NVS 420 entries and one Default entry. These entries correspond not to the number of GPUs that are available in our system, but rather to the number of display adapters that are connected to our system. In our system, we have 4 display adapters connected to one NVS 420, and 2 display adapters connected to the other. Each NVS 420 has two available GPUs that any application can access via the NVIDIA API. However, since the NVS 420 does not support SLI, the NVIDIA API does not support virtual bonding of the two installed NVS 420s as one virtual graphics processor. This is essentially what SLI provides. In lieu of this, the NVIDIA API instead provides the ability for an application to either have direct access to each GPU located on each NVS 420, or in the alternate, to access the two available GPUs on each NVS 420 as one virtual "bonded" GPU, wherein the application simply needs to read and write to the graphics card and the NVIDIA API takes over the task of load balancing the work across the two available GPUs on the graphics card (but not across the two graphics cards). This functionality as described herein is available via the NVIDIA API on all NVIDIA graphics cards that support NVIDIA drivers 244 and greater.

Unfortunately, our testing shows that VMIX does not take advantage of this native performance scaling capability. VMIX instead runs in what is referred to as by NVIDIA as Compatibility Mode, wherein only 1 GPU is selected and used by the graphics API device (or application context) and any other GPU in the system remains idle. At minimum, VMIX should at least be capable of leveraging all GPUs that are available to it on a single graphics card. More preferably however, VMIX should be capable of directly accessing all GPUs that are available to it in the system. In our system configuration with two installed NVS 420s this would provide VMIX with a total of four available GPUs. As it is now, VMIX only uses one GPU of out of the four. As a result, VMIX quickly maxes out one GPU with only a few inputs added while the other GPUs remain idle.

So this really isn't a question of the VMIX application doing more work. Quite the contrary. It's a question of whether the VMIX application intelligently leverages the GPUs that are available to it on the graphics card via the driver native API. Our analysis shows that the VMIX application doesn't do this well at all. It just spins very hard and maxes out on a single GPU. Your suggestion to swap out one of the NVS 420s and to substitute a more powerful graphics card, while I appreciate this, isn't the solution for the reasons stated herein.

More detailed developer information regarding the NVIDIA API may be found at https://developer.nvidia.com/nvapi The NVIDIA API allows direct access to all NVIDIA GPUs and drivers on all windows platforms. I would kindly encourage you to take a look at this. If what I have discussed here sounds a bit too technically daunting, then I would also encourage you to contact NVIDIA directly about possibly sending your VMIX application to NVIDIA so that they can analyze and create a profile for your application. This may obviate the need for some of the common changes suggested in their API developer documentation to handle for example, SLI configurations. In some cases, however, driver profiles may not be the most optimal solution, and application changes may be recommended. Once NVIDIA has created a profile for your application, this profile will be automatically added to their next driver release, making it available to all end users as soon as they install the updated driver.

I believe this would benefit your entire installed VMIX user base.

Best,
Jean-Claude

Did you read Martin's replies? Don't think so...
And why should he take time for 1% of the users that are unable/unwilling to use a recommended GPU instead of investing the time for useful features for the other 99%?

Thanks for all the wonderful feedback, guys. I have no intent of engaging in a subjective pissing contest with anyone here. Granted, Quadro's aren't for everyone. But for those of us who use them, they're indispensable for what we do. If you're a gamer and a gaming card works well for you in your VMIX application, then great for you. Unfortunately, they don't work well for us in our use case. The fact that our test case involves an NVS 420 setup isn't what's relevant here. It's the fact that our NVS 420 setup exposes a graphics subsystem issue with VMIX that gaming cards simply mask, and that if this issue were to be properly addressed under the hood as suggested, VMIX would perform even better on all types of systems. Just saying, guys.

Hi Jean-Claude,

NVAPI is a configuration API and does not provide any rendering capabilities as far as I am aware.
Perhaps you are thinking of something else?

Maybe the CUDA API which is a Compute API and not a Render API which is what vMix needs to process
and composite multiple video feeds in real time.

As I said, memory bandwidth is the key here and multi GPU workloads will actually run slower because of the amount of data
vMix needs to process.

In typical workstation applications, only one or two video feeds are processed by the GPU at a time (typically by effects and
editing applications). Or only a small amount of data in the case of CAD.
Thus it is very easy to copy this across all GPUs and submit code for processing.

vMix is only capable of doing what it does by taking advantage of every last bit of power available on modern PCs.
I have researched in depth the various APIs and methods available over the years, and the way vMix currently works is the fastest available, Quadro or not.

Regards,

Martin
vMix