Test-Driving NVIDIA's GRID GPU Cloud Computing Platform

MojoKid writes: "NVIDIA recently announced that it would offer a free 24-hour test drive of NVIDIA GRID to anyone who wanted to see what the technology could do. It turns out to be pretty impressive. NVIDIA's GRID is a virtual GPU technology that allows for hardware acceleration in a virtual environment. It's designed to run in concert with products from Citrix, VMWare, and Microsoft, and to address some of the weaknesses of these applications. The problem with many conventional Virtual Desktop Interfaces (VDIs) is that they're often either too slow for advanced graphics work or unable to handle 3D workloads at all. Now, with GRID, NVIDIA is claiming that it can offer a vGPU passthrough solution that allows remote users to access a virtualized desktop environment built around a high-end CPU and GPU. The test systems the company is using for these 24-hour test drives all use a GRID K520. That's essentially two GK104 GPUs on a single PCB with 8GB of RAM. The TD program is still in beta, the deployment range is considerable, and the test drives themselves are configured for a 1366x768 display at 30 FPS and a maximum available bandwidth cap of 10Mbit."

Comments

Re:FP(U)

[ArcadeMan]

So we're going to run code on GPUs and let CPUs render the graphics?

OpenStack support?

[buchner.johannes]

The only approach that has been successful for CUDA access from a kvm virtual machine that we know of is gVirtuS.

https://wiki.openstack.org/wik...

Nice, but expensive

[BaronM]

This isn't particularly new. It's nice tech, but each ~$2000 K1 board supports 4 users. 4. The K2 board supports 2 'power users'. (ref: NVIDIA data sheet: http://www.nvidia.com/content/... )

If I cram 4 K1 boards in a server, I can now support 16 virtual desktops with 3D acceleration for an $8k delta over and above the other expenses of VDI.

Unless you ABSOLUTELY MUST have VDI for 3D workloads, I can't see how this makes sense.

Re:Nice, but expensive

[ledow]

It's the old thin-client problem, reinvented with virtual machines.

Of course you can run 16 computers/users off one VM, but they will each get 1/16th of the capabilities of the computer, on average.

Sometimes that scales - e.g. small businesses virtualising their half-idle servers. Sometimes it doesn't - e.g. most thin clients when you want to get towards 3D or anything intensive.

But for power users? It almost always doesn't. If you need that kind of power, you have to spend ridiculous amounts of money, or you have to keep the resources to one-or-more per user (i.e. give them a desktop with a decent 3D card).

It's what killed off OnLive. Sure, if we all played 2D Mario games, it would be fabulous. But we don't. And as soon as the demand on the hardware increases, you can't afford to share it when you could get twice as much power for the same money.

Re:Nice, but expensive

[Shados]

There's 2 big use cases for desktop virtualization. The common one is to run a ton of desktops of off little hardware, with the idea that most people only read emails and use MS Word all day anyway. Big cost saving.

The other is purely to have desktops centralized in a data center so you can have data center admins deal with them instead of needing (as many) on site tech monkeys.

I worked in companies where it was the later. The users still needed 16+ gb of RAM, dedicated powerful hardware, etc, but now if something blew up, you didn't need to send someone at their desk to fix it, and you could still just move the image to a different machine while the first one was being fixed.

This technology seems very well suited toward the later.

Re:Nice, but expensive

[fishybell]

Exactly this. We investigated moving our engineers (running Pro/E / Creo) and our drafters (running Autocad) to this setup because they're the only ones not running a VDI or VDI-like setup. We're a company well suited to this because we already have the entire setup minus the NVidia gear. We ended up skipping it (for now at least) because of one two things: money and productivity. The cost of switching to a virtual environment was significantly more than the cost of getting them all new hardware. We might look at it again in another year or so when they're due for new hardware anyway, but for now it's $40k plus that isn't needed or wanted by anyone other than IT. It makes our jobs easier, but reduces their productivity slightly at the gain of increasing ours slightly. Even with 10+ drafters and 5+ engineers that offset was enough to make us blink.

Bad Scaling Problem Though

[grilled-cheese]

We very recently went through adding Grid cards to our VMware View infrastructure. The Grid K1 & K2 cards are a tradeoff on either more kepler processors or more cuda cores in addition to the quantity of RAM. VMware View can utilize a Grid card in either vSGA or vDGA modes (shared or direct passthrough of a kepler processor). From what I can discern, Dell only officially supports the Grid cards in their R720 server. That particular chassis can only accept 2 Grid cards max. So you can get your choice of 2, 4, 6, or 8 kepler processors. If you're using vDGA mode, you're creating a direct VDI desktop allocation of that core with DirectPath I/O. While this means that one desktop is going to have great performance, it means it isn't available for anyone else and you lose vMotion capability. If you run in vSGA mode, the performance per machine isn't as good as vDGA but more desktops can utilize the hardware. There arn't any good whitepapers I've found yet describing how far you can stretch a Grid K1, but the rule of thumb I got from another company who has ran them through their benchmark lab got around 25 desktops per K1 max. Therefore, assuming you've got a pair of them that means you can run ~50 desktops with a reduced performance when compared to vDGA. The technology still appears to be young to me, but we decided to take a chance and see how far we could take it.

Re:Doesn't VMware and Microsoft already support th

[WilyCoder]

remotefx blows. it only provides a direct3d interface, there is no opengl support (which is what the majority of the scientific visualization community uses).