Why not RemoteFX, as well as more information about NVIDIA GRID VGPU technology
The increase in the number of workplaces in the enterprise and the growth of the IT infrastructure in general sooner or later makes one think about a number of issues related to a more competent construction of the IT infrastructure itself, aimed at solving the following tasks facing the IT department staff:
The most popular solution to the first and second voiced tasks is the introduction of terminal servers in the enterprise and the replacement of expensive workstations with thin clients. Indeed, in the context of the constant need to purchase hardware and software, the terminal server and thin clients can reduce the costs associated with an increase in the number of workplaces, as well as allow IT department employees to use more convenient and transparent mechanisms for administering and maintaining the above-mentioned jobs. With the implementation of the solution of the third problem, virtualization of workplaces and servers is excellent. A powerful toolkit of various modern hypervisors allows IT department employees to back up unnoticed by users and, in the event of a workplace or server failure, quickly restore them to a fully operational state.
However, sometimes the capabilities of a remote session of a terminal server or operating system deployed as a guest are not enough. I'm talking about cases where a user working on a thin client using remote desktop capabilities needs to work with a specific set of programs, for example, various CAD programs and other software related to using 3D graphics. It is not at all necessary to return to the use of full-fledged, independent workplaces. The manufacturers of video cards and servers together with the developers of various virtual platforms have been thinking about using the capabilities of a physical video card in guest operating systems for quite some time. However, not all hypervisor developers succeeded (or perhaps they did not want) to develop a general concept of using the capabilities of a video card by virtual machines, which was proposed by leading manufacturers of computational graphics modules. There are quite a few holivars on this subject, I will try to do without participating in them and assess the state of affairs based only on dry facts.
For a long time, I have known the Microsoft hypervisor called Hyper-V. It should be noted that this hypervisor with each subsequent generation of the server platform Windows Server is becoming more functional and intuitive to administer. New cmdlets are added to PowerShell to make it easy to manage the hypervisor. There is a great opportunity to implement using such scripts even such necessary tasks as backing up virtual machines and creating snapshots on a schedule in the scheduler without using third-party and quite expensive programs. It is easy to administer Hyper-V, the performance of the hypervisor is not satisfactory, the list of operating systems with either installed hypervisor integration services, with the ability to install such services, or supporting Hyper-V thanks to kernel modules is constantly growing. More recently, the release of FreeBSD 10.0, the first of the BSD systems, was easily installed as a guest on the Microsoft hypervisor, and which got rid of children's sores, such as the limited size of the virtual hard disk and the possibility of using only an outdated network adapter (legacy or emulated ), whose speed can not exceed 100 Mbps, while the physical network adapter is gigabit. In general, as it may seem, the trend towards improvement has a very positive trend. That is why we initially started looking for the answer to the question of whether there is a possibility of using a physical video card in the guest operating system Hyper-V. The answer, as it seemed to us then, did not take long to wait and after 5 minutes, judging by the articles on the Internet, we were confident that this possibility existed and, moreover, it was qualitatively implemented by the Hyper-V developers. As it turned out, we were cruelly mistaken, but first things first.
Microsoft offered as a solution the RemoteFX technology, which was originally developed by Calista Technologies, which was later acquired by Microsoft. The technology itself has very significant hardware requirements for both the virtualization server and the video card, which will later be used by the guest operating system through this technology. The requirements are that the server itself should have a CPU with SLAT support (EPT on Intel, NPT / RVI on AMD), but with a GPU it is still more fun. Here are the actual requirements and recommendations voiced by Microsoft themselves:
In the vastness of the world wide web there are quite a few guides to deploying RemoteFX on Windows Server. However, almost none of these articles is about quality application, but basically the article has such a complete meaning: “I picked it up, picked it up, it seemed to work, it seemed to even move faster, it seemed to even reduce the CPU load. What did you do? God knows. ”
')
So, I want to tell you about our experience in finding a solution to the task of empowering virtual machines in processing 3D graphics. We faced a fairly clearly outlined task. We needed to make sure that the users of remote desktops of the terminal server deployed on the Windows Server 2012 R2 platform were able to at least qualitatively view various 3D drawings and assemblies in specialized viewers, and at most, they could no-no, and run various CAD programs.
The initial idea was to deploy RemoteFX on Windows Server 2012R2. No sooner said than done. There was a DELL PowerEdge R720 server platform, equipped with two Intel Xeon CPU E5-2670 v2 @ 2.50GHz processors that support SLAT, as well as an NVIDIA GRID K2 computing graphics module. The server was equipped with the Windows Server 2012R2 standard operating system with a graphical shell, the Hyper-V service was deployed and RemoteFX was configured. In fact, then we thought that this was the final decision and the RemoteFX technology would completely suit us. However, later we learned that Microsoft imposes on technology and essential software requirements that only Windows 7 and 8 operating systems and only in Ultimate and Enterprise editions can act as a guest operating system capable of using a three-dimensional graphic adapter RemoteFX. Of course, not entirely fair, given that the hypervisor itself, according to the statements of its developers, supports a lot of other operating systems.
It became clear that our goal to use a graphics adapter in a virtual terminal server, which is deployed on Windows Server 2012R2, will remain unworkable. Okay, working with what is. So what do we have? Very little. Only the ability to install as a guest operating system Windows 7-8 Ultimate-Enterprise with the ability to connect to them only one user. And even the excellent RDP Wrapper library is not able to solve this problem. Besides, as we learned from the performance results, the 3D RemoteFX graphics adapter hardly works with such an API as OpenGL, which most CAD programs use, and instead only fully supports Microsoft’s proprietary development for Windows — Direct3D. About this very modestly modestly declare only two lines in the description of the RemoteFX technology on the Microsoft website:
What is this, proprietary development to support the ability to deploy a terminal server based on virtual machines, proposed in the latest generation of Windows Server? It is difficult to answer this question. However, only one thing is clear, the RemoteFX technology is not applicable to solving the task set before us, especially in view of the excessively high hardware and software requirements for the platform, server and guest operating systems. Of course, we are ready to meet all these requirements, but to get a ready-made solution with extremely dubious functionality as a result is a waste.
That is why the search has not stopped and, to my shame, the first time we paid attention to what NVIDIA itself writes about the graphical computing module it developed and its application. You can read more here , or more briefly, NVIDIA created the NVIDIA GRID vGPU technology, thanks to which the graphic commands of each virtual machine are transmitted directly to the GPU, without being broadcast by the hypervisor. Thanks to the driver, one physical graphics module has several virtual GPU profiles with different number of cores and discrete graphics memory. Here is a table of available virtual profiles for NVIDIA GRID graphics cards:
Everything is extremely simple and beautiful. The driver has the ability to allocate virtual profiles from the hardware platform of the board, differing from each other in the number of graphics cores and memory, which can become analogous to a physical video card in a virtual machine. At the same time, the RemoteFX technology is just a software layer between the virtual machine and the real graphics card, which selectively transfers a particular graphics for processing. Why then does Microsoft recommend using a graphics card whose functionality is not fully supported by the capabilities of their hypervisor? Why recommend this board for use if the hypervisor, written by them, does not follow the path of development of the concept proposed by the manufacturers of the graphics card? Unclear. However, it should be noted that the description of the NVIDIA GRID VGPU technology on the NVIDIA website does not say a word (and thank God) about the Microsoft hypervisor, but instead mentions such developers as VMware c vSphere and Citrix with its XenServer.
It was decided to try XenServer 6.5 from Citrix as a hypervisor, whose functionality in the Enterprise edition just supports the distribution of virtual graphical profiles among virtual machines. Although this has nothing to do with the article, I’ll note that the installation and configuration of the server is simple and intuitive to disgrace. The server was installed and activated with a trial license for 90 days, which can be obtained, taking into account the number of host sockets, in 5 minutes by registering on the developers site. After activation, the distribution function of graphical profiles becomes available in XenCenter. Unfortunately, while drivers are available for download only for Windows operating systems, it is good that the graphical profile can be installed not only on Windows 7-8 Ultimate-Enterprise versions, but also on other Microsoft operating systems such as Windows 7-8 other editions and Windows Server 2008-2012, out of the box, supports OpenGL 4.4 and DirectX 11 and OpenCL, and also has no restrictions on the number of simultaneous connections by means of remote desktop to the virtual machine.
In order to assess the quality of work of virtual graphic profiles, the Windows 8.1_x64_Enterprise operating system was installed as a guest, the first three profiles (K280Q, K260Q, K240Q) were added alternately in the virtual machine settings, and each graphic profile was 4 benchmarks were launched, testing 3D graphics performance using the OpenGL API and Direct3D. So that the comparison does not seem excessively abstract, it was decided to compare the results of benchmarks running on the VM with the results of the same benchmarks running on a physical machine that has similar characteristics. Briefly about the technical characteristics of the virtual and physical machines can be found in the table below.
In the tables with the results of benchmarks, I will only indicate the name of the graphics adapter.
So, the first benchmark will be SPECviewperf 12.0.2, which is revered by many experts as a benchmark for testing graphics of various CAD programs. Who cares, more here . The results are in the table below. The resolution of the window is 1900x1060 everywhere (by default in the benchmark).
All the results spread as is. I was a little embarrassed that the K260Q profile was supposed to be “weaker” than K280Q, but showed more outstanding results. I rechecked by running the test again on both profiles and came to the conclusion that the readings are stable (not random) and, although different from the original, but within reasonable limits of 0.2-0.4.
The next benchmark, or rather a set of various benchmarks for graphics testing OpenGL, was GpuTest from the site geeks3d.com, you can find out more here . The results are in the table below in format (points / FPS). All tests are made in full screen mode 1920x1080.
The next benchmark was the RedSDK turbine benchmark from the company REDWAY3D. Read more here . The results are in the table below. All tests are made in full screen mode 1920x1080.
The latest benchmark was the free version of Heaven Benchmark 4.0 from Unigine developers. Read more here . The choice fell on him, among other things, because he can test Direct3D graphics. All tests were performed in a window with a resolution of 1280x720 due to the fact that the benchmark did not want to run in full-screen mode on virtual machines for unknown reasons, giving an error. The results in the tables below.
I will not draw any conclusions from the tests I have made; it is better to leave it to the public. To be honest, the results of the tests are not completely clear to me, and if the reader has something to comment on them qualitatively, I will only be happy.
Summing up, I will say that all CAD programs and other software used in our company are successfully installed and run on virtual machines. It remains to let the specialist using these programs work with the remote desktop and let him make the final verdict about the possibility of using this solution. I also want to emphasize that I did not write this article because of idleness, but precisely because when I myself was looking for a solution to the task assigned to the IT department, I didn’t see such articles completely uncovering the differences between different technologies for forwarding graphics card capabilities to a virtual machine, didn’t see articles which describe the qualitative application of these technologies.
I hope the experience of our IT department will come in handy for someone. Thank you for attention.
- reducing the cost of creating full-fledged jobs;
- creation of a more convenient mechanism for administering workplaces by IT department employees and, as a result, reducing the time for performing certain operations related to technical user support;
- implementation of backup and quick data recovery (or the entire workplace).
The most popular solution to the first and second voiced tasks is the introduction of terminal servers in the enterprise and the replacement of expensive workstations with thin clients. Indeed, in the context of the constant need to purchase hardware and software, the terminal server and thin clients can reduce the costs associated with an increase in the number of workplaces, as well as allow IT department employees to use more convenient and transparent mechanisms for administering and maintaining the above-mentioned jobs. With the implementation of the solution of the third problem, virtualization of workplaces and servers is excellent. A powerful toolkit of various modern hypervisors allows IT department employees to back up unnoticed by users and, in the event of a workplace or server failure, quickly restore them to a fully operational state.
However, sometimes the capabilities of a remote session of a terminal server or operating system deployed as a guest are not enough. I'm talking about cases where a user working on a thin client using remote desktop capabilities needs to work with a specific set of programs, for example, various CAD programs and other software related to using 3D graphics. It is not at all necessary to return to the use of full-fledged, independent workplaces. The manufacturers of video cards and servers together with the developers of various virtual platforms have been thinking about using the capabilities of a physical video card in guest operating systems for quite some time. However, not all hypervisor developers succeeded (or perhaps they did not want) to develop a general concept of using the capabilities of a video card by virtual machines, which was proposed by leading manufacturers of computational graphics modules. There are quite a few holivars on this subject, I will try to do without participating in them and assess the state of affairs based only on dry facts.
For a long time, I have known the Microsoft hypervisor called Hyper-V. It should be noted that this hypervisor with each subsequent generation of the server platform Windows Server is becoming more functional and intuitive to administer. New cmdlets are added to PowerShell to make it easy to manage the hypervisor. There is a great opportunity to implement using such scripts even such necessary tasks as backing up virtual machines and creating snapshots on a schedule in the scheduler without using third-party and quite expensive programs. It is easy to administer Hyper-V, the performance of the hypervisor is not satisfactory, the list of operating systems with either installed hypervisor integration services, with the ability to install such services, or supporting Hyper-V thanks to kernel modules is constantly growing. More recently, the release of FreeBSD 10.0, the first of the BSD systems, was easily installed as a guest on the Microsoft hypervisor, and which got rid of children's sores, such as the limited size of the virtual hard disk and the possibility of using only an outdated network adapter (legacy or emulated ), whose speed can not exceed 100 Mbps, while the physical network adapter is gigabit. In general, as it may seem, the trend towards improvement has a very positive trend. That is why we initially started looking for the answer to the question of whether there is a possibility of using a physical video card in the guest operating system Hyper-V. The answer, as it seemed to us then, did not take long to wait and after 5 minutes, judging by the articles on the Internet, we were confident that this possibility existed and, moreover, it was qualitatively implemented by the Hyper-V developers. As it turned out, we were cruelly mistaken, but first things first.
Microsoft offered as a solution the RemoteFX technology, which was originally developed by Calista Technologies, which was later acquired by Microsoft. The technology itself has very significant hardware requirements for both the virtualization server and the video card, which will later be used by the guest operating system through this technology. The requirements are that the server itself should have a CPU with SLAT support (EPT on Intel, NPT / RVI on AMD), but with a GPU it is still more fun. Here are the actual requirements and recommendations voiced by Microsoft themselves:
| Rank | Nvidia | AMD |
|---|---|---|
| Best | NVIDIA Grid 1. Grid K1 2. Grid K2 | AMD FirePro series 1. AMD FirePro S10000 2. AMD FirePro S9000 3. AMD FirePro S7000 |
| Better | NVIDIA Quadro 1. Quadro K6000 2. Quadro K5000 | AMD FirePro series 1. AMD FirePro V9800P 2. ATI FirePro V9800 |
| Good | AMD FirePro series 1. ATI FirePro V8800 2. ATI FirePro V7800 3. AMD FirePro V7800P 4. ATI FirePro V5800 |
In the vastness of the world wide web there are quite a few guides to deploying RemoteFX on Windows Server. However, almost none of these articles is about quality application, but basically the article has such a complete meaning: “I picked it up, picked it up, it seemed to work, it seemed to even move faster, it seemed to even reduce the CPU load. What did you do? God knows. ”
')
So, I want to tell you about our experience in finding a solution to the task of empowering virtual machines in processing 3D graphics. We faced a fairly clearly outlined task. We needed to make sure that the users of remote desktops of the terminal server deployed on the Windows Server 2012 R2 platform were able to at least qualitatively view various 3D drawings and assemblies in specialized viewers, and at most, they could no-no, and run various CAD programs.
The initial idea was to deploy RemoteFX on Windows Server 2012R2. No sooner said than done. There was a DELL PowerEdge R720 server platform, equipped with two Intel Xeon CPU E5-2670 v2 @ 2.50GHz processors that support SLAT, as well as an NVIDIA GRID K2 computing graphics module. The server was equipped with the Windows Server 2012R2 standard operating system with a graphical shell, the Hyper-V service was deployed and RemoteFX was configured. In fact, then we thought that this was the final decision and the RemoteFX technology would completely suit us. However, later we learned that Microsoft imposes on technology and essential software requirements that only Windows 7 and 8 operating systems and only in Ultimate and Enterprise editions can act as a guest operating system capable of using a three-dimensional graphic adapter RemoteFX. Of course, not entirely fair, given that the hypervisor itself, according to the statements of its developers, supports a lot of other operating systems.
It became clear that our goal to use a graphics adapter in a virtual terminal server, which is deployed on Windows Server 2012R2, will remain unworkable. Okay, working with what is. So what do we have? Very little. Only the ability to install as a guest operating system Windows 7-8 Ultimate-Enterprise with the ability to connect to them only one user. And even the excellent RDP Wrapper library is not able to solve this problem. Besides, as we learned from the performance results, the 3D RemoteFX graphics adapter hardly works with such an API as OpenGL, which most CAD programs use, and instead only fully supports Microsoft’s proprietary development for Windows — Direct3D. About this very modestly modestly declare only two lines in the description of the RemoteFX technology on the Microsoft website:
“Support in Windows Server 2012 R2 is provided for DX 11.0, DirectCompute, and C ++ AMP. Most of the latest graphics cards will support OpenGL 4.0 and OpenCL 1.1 or later, but these APIs are currently unsupported by RemoteFX in Windows Server 2012 R2. ”
What is this, proprietary development to support the ability to deploy a terminal server based on virtual machines, proposed in the latest generation of Windows Server? It is difficult to answer this question. However, only one thing is clear, the RemoteFX technology is not applicable to solving the task set before us, especially in view of the excessively high hardware and software requirements for the platform, server and guest operating systems. Of course, we are ready to meet all these requirements, but to get a ready-made solution with extremely dubious functionality as a result is a waste.
That is why the search has not stopped and, to my shame, the first time we paid attention to what NVIDIA itself writes about the graphical computing module it developed and its application. You can read more here , or more briefly, NVIDIA created the NVIDIA GRID vGPU technology, thanks to which the graphic commands of each virtual machine are transmitted directly to the GPU, without being broadcast by the hypervisor. Thanks to the driver, one physical graphics module has several virtual GPU profiles with different number of cores and discrete graphics memory. Here is a table of available virtual profiles for NVIDIA GRID graphics cards:
| NVIDIA GRID Graphics Card | Virtual GPU profile | Graphic memory | Maximum number of displays per user | Maximum display resolution | Maximum number of users per graphics card |
|---|---|---|---|---|---|
| GRID K2 | K280Q K260Q K240Q K220Q | 4GB 2GB 1GB 512MB | four four 2 2 | 2560x1600 2560x1600 2560x1600 2560x1600 | 2 four eight sixteen |
| GRID K1 | K180Q K160Q K140Q K120Q | 4GB 2GB 1GB 512MB | four 2 2 2 | 2560x1600 2560x1600 2560x1600 2560x1600 | four eight sixteen 32 |
Everything is extremely simple and beautiful. The driver has the ability to allocate virtual profiles from the hardware platform of the board, differing from each other in the number of graphics cores and memory, which can become analogous to a physical video card in a virtual machine. At the same time, the RemoteFX technology is just a software layer between the virtual machine and the real graphics card, which selectively transfers a particular graphics for processing. Why then does Microsoft recommend using a graphics card whose functionality is not fully supported by the capabilities of their hypervisor? Why recommend this board for use if the hypervisor, written by them, does not follow the path of development of the concept proposed by the manufacturers of the graphics card? Unclear. However, it should be noted that the description of the NVIDIA GRID VGPU technology on the NVIDIA website does not say a word (and thank God) about the Microsoft hypervisor, but instead mentions such developers as VMware c vSphere and Citrix with its XenServer.
It was decided to try XenServer 6.5 from Citrix as a hypervisor, whose functionality in the Enterprise edition just supports the distribution of virtual graphical profiles among virtual machines. Although this has nothing to do with the article, I’ll note that the installation and configuration of the server is simple and intuitive to disgrace. The server was installed and activated with a trial license for 90 days, which can be obtained, taking into account the number of host sockets, in 5 minutes by registering on the developers site. After activation, the distribution function of graphical profiles becomes available in XenCenter. Unfortunately, while drivers are available for download only for Windows operating systems, it is good that the graphical profile can be installed not only on Windows 7-8 Ultimate-Enterprise versions, but also on other Microsoft operating systems such as Windows 7-8 other editions and Windows Server 2008-2012, out of the box, supports OpenGL 4.4 and DirectX 11 and OpenCL, and also has no restrictions on the number of simultaneous connections by means of remote desktop to the virtual machine.
In order to assess the quality of work of virtual graphic profiles, the Windows 8.1_x64_Enterprise operating system was installed as a guest, the first three profiles (K280Q, K260Q, K240Q) were added alternately in the virtual machine settings, and each graphic profile was 4 benchmarks were launched, testing 3D graphics performance using the OpenGL API and Direct3D. So that the comparison does not seem excessively abstract, it was decided to compare the results of benchmarks running on the VM with the results of the same benchmarks running on a physical machine that has similar characteristics. Briefly about the technical characteristics of the virtual and physical machines can be found in the table below.
| OS | CPU | Ram | Video adapter | |
|---|---|---|---|---|
| FM | Windows 8.1 x64 Enterprise | Inter Core (TM) i5-4670 @ 3.40GHz CPU | 12GB | Nvidia GeForce GTX 650 |
| VM | Windows 8.1 x64 Enterprise | Inter Xeon CPU E5-2670 v2 @ 2.50GHz | 12GB | Nvidia GRID VGPU K280Q || K260Q || K240Q. |
In the tables with the results of benchmarks, I will only indicate the name of the graphics adapter.
So, the first benchmark will be SPECviewperf 12.0.2, which is revered by many experts as a benchmark for testing graphics of various CAD programs. Who cares, more here . The results are in the table below. The resolution of the window is 1900x1060 everywhere (by default in the benchmark).
| Test | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Catia-04 | 9.06 | 17.16 | 31.83 | 12.14 |
| Creo-01 | 9.21 | 17.85 | 34.41 | 17.72 |
| Energy-01 | 0.43 | 0.72 | 0.74 | 0.18 |
| Maya-04 | 22.45 | 6.14 | 13.99 | 2.85 |
| Medical-01 | 6.18 | 15.17 | 18.76 | 15.38 |
| Showcase-01 | 14.99 | 11.14 | 32.80 | 10.84 |
| Snx-02 | 2.07 | 18.31 | 34.80 | 18.41 |
| SolidWorks-03 | 20.56 | 19.02 | 38.14 | 20.79 |
All the results spread as is. I was a little embarrassed that the K260Q profile was supposed to be “weaker” than K280Q, but showed more outstanding results. I rechecked by running the test again on both profiles and came to the conclusion that the readings are stable (not random) and, although different from the original, but within reasonable limits of 0.2-0.4.
The next benchmark, or rather a set of various benchmarks for graphics testing OpenGL, was GpuTest from the site geeks3d.com, you can find out more here . The results are in the table below in format (points / FPS). All tests are made in full screen mode 1920x1080.
| Test | GTX 650 (points / FPS) | K280Q (points / FPS) | K260Q (points / FPS) | K240Q (points / FPS) |
|---|---|---|---|---|
| FurMark (OpenGL 2.1 / 3.0) | 1214/20 | 2068/34 | 1790/29 | 1619/26 |
| GiMark (OpenGL 3.3) | 960/15 | 1630/27 | 1578/26 | 1604/26 |
| PixMark Julia FP32 (OpenGL 2.1 / 3.0) | 6724/111 | 2231/37 | 3874/64 | 3364/56 |
| Pixmark Julia FP64 (OpenGL 4.0) | 490/8 | 1046/17 | 1216/20 | 1082/18 |
| Plot3D (OpenGL 2.1 / 3.0) | 39817/664 | 2289/38 | 2299/38 | 2296/38 |
| TessMark x16 (OpenGL 4.0) | 13458/224 | 1545/25 | 1329/22 | 1542/25 |
| TessMark x64 (OpenGL 4.0) | 3039/50 | 1511/25 | 1419/23 | 1535/25 |
| Triangle (OpenGL 2.1 / 3.0) | 145268/2421 | 3748/62 | 3871/64 | 3757/62 |
The next benchmark was the RedSDK turbine benchmark from the company REDWAY3D. Read more here . The results are in the table below. All tests are made in full screen mode 1920x1080.
| Test | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Real-time viewport | 1623 | 1018 | 368 | 400 |
| High quality real-time | 1800 | 1576 | 355 | 366 |
| Dynamic ambient occlusion | 1311 | 2459 | 2378 | 2418 |
| Hybrid ray-tracing | 1114 | 414 | 413 | 399 |
| Total score | 1437 | 1131 | 599 | 614 |
The latest benchmark was the free version of Heaven Benchmark 4.0 from Unigine developers. Read more here . The choice fell on him, among other things, because he can test Direct3D graphics. All tests were performed in a window with a resolution of 1280x720 due to the fact that the benchmark did not want to run in full-screen mode on virtual machines for unknown reasons, giving an error. The results in the tables below.
| Opengl | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| FPS | 44.9 | 56.8 | 54.0 | 56.3 |
| Score | 1131 | 1432 | 1361 | 1418 |
| Min FPS | 11.2 | 13.2 | 8.8 | 11.8 |
| Max FPS | 83.7 | 66.1 | 66.0 | 66.0 |
| Direct3d 11 | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| FPS | 46.9 | 69.4 | 34.2 | 57.4 |
| Score | 1183 | 1747 | 862 | 1446 |
| Min FPS | 10.7 | 9.2 | 6.9 | 9.9 |
| Max FPS | 88.1 | 137.5 | 93.8 | 67.5 |
I will not draw any conclusions from the tests I have made; it is better to leave it to the public. To be honest, the results of the tests are not completely clear to me, and if the reader has something to comment on them qualitatively, I will only be happy.
Summing up, I will say that all CAD programs and other software used in our company are successfully installed and run on virtual machines. It remains to let the specialist using these programs work with the remote desktop and let him make the final verdict about the possibility of using this solution. I also want to emphasize that I did not write this article because of idleness, but precisely because when I myself was looking for a solution to the task assigned to the IT department, I didn’t see such articles completely uncovering the differences between different technologies for forwarding graphics card capabilities to a virtual machine, didn’t see articles which describe the qualitative application of these technologies.
I hope the experience of our IT department will come in handy for someone. Thank you for attention.
Source: https://habr.com/ru/post/257425/
All Articles