CAD的vSGA基准测试

嗨雷切尔，
vSGA软件在VM中有一个垫片驱动程序，位于应用程序之间，最终与管理程序中的NVIDIA硬件驱动程序通信。
与vGPU工作站相比，这是不同的，其中VM内部有NVIDIA驱动程序，而管理程序内部有另一部分。
这可能会产生一些关键差异：
1）VM中的vSGA驱动程序将公开一定级别的API版本支持，对于vSGA，它是DirectX 9.0c和OpenGL 2.1。
因此，要求创建DX10或11的应用程序将失败，同样，除了2.1之外定义的任何OpenGL功能以及vSGA驱动程序也不支持的扩展都将失败。
2）在两个API中，数据经常从应用程序通过API传递到驱动程序，最终传递到用于绘制像素的GPU。
在vSGA的情况下，在到达GPU之前更有可能存在更多副本。
根据数据量，应用程序调用的频率，额外的数据传输可能会产生影响。
3）在某些情况下，vSGA驱动程序会将应用程序发出的API调用转换为一组不同的调用，并将其发送给虚拟机管理程序中的NVIDIA驱动程序，例如DX。
此转换也是影响性能的潜在领域。
检查Redway基准测试的确切图形调用需要做更多的工作，但是通过结合上述3个关键差异，在比较vSGA与vDGA，vGPU和裸机替代品时可能会产生很大的开销。
某些OpenGL数据类型（即使在OpenGL 2.1中）（如缓冲区对象）也会创建并在使用参考存储器GPU内存时，并且在虚拟化环境中，这些可能会触发管理程序中的额外工作，以确保虚拟机内存映射对于VM执行是正确的。
与裸金属相比，这反过来可能会导致额外的工作。
在vGPU的情况下。
对于vSGA，可能会对这些类型的数据产生一些额外的影响。
因此，即使两个比较下面都有相同的硬件，也有很多软件层，而在vSGA情况下，它们是非常不同的，并且与vGPU相比，它们更多。
正如我所说，需要进行详细调查才能明确说明瓶颈是什么，但额外的层有可能对性能产生影响。



以下为原文

Hi Rachel,

The vSGA software has a shim driver within the VM that sits between the application and communicates ultimately with the NVIDIA hardware driver in the hypervisor. This is different when compared to vGPU workstation where there is an NVIDIA driver inside the VM and another part inside the hypervisor. This can yield some key differences:

1) The vSGA driver in the VM will expose a certain level of API version support, which for vSGA is DirectX 9.0c and OpenGL 2.1. So apps asking to create a DX10 or 11 will fail and likewise any OpenGL functions defined beyond 2.1, as well as extensions also not supported by the vSGA driver, will fail.

2) In both APIs data is frequently passed from the application through the API into the driver and ultimately to the GPU where its used to draw pixels. In the case of vSGA there are more likely to be more copies before it reaches the GPU. Depending on the amount of data, how frequently calls are by the application the additional data transfer can be an impact.

3) In some cases the vSGA driver will translate the API calls made by the application into a different set of calls which it issues to the NVIDIA driver in the hypervisor, eg DX. This translation is also a potential area for performance impact.

It would take more work to examine the exact graphics calls being made by the Redway benchmark but through a combination of the above 3 key differences there could be a significant overhead when comparing vSGA to vDGA, vGPU and baremetal alternatives.

Certain OpenGL data types (even in OpenGL 2.1) such as buffer objects also create and when used reference memory GPU memory and in a virtualized environment these may trigger extra work in the hypervisor to ensure the virtual machine memory mappings are correct for the VM executing. This in turn may cause extra work compared to baremetal. In the case of vGPU. In the case of vSGA there may be some extra implications for these types of data.

So even though the same hardware is underneath both comparisons there are a lot of software layers and in the vSGA case they are very different and there are more of them compared with vGPU. As I say it would require detailed investigation to say definitively what is the bottleneck however the extra layers have the potential for performance impact.