Slashdot Mirror
NVIDIA Targeting Real-Time Cloud Rendering
MojoKid writes "To date, the majority of cloud computing applications have emphasized storage, group collaboration, or the ability to share information and applications with large groups of people. So far, there's been no push to make GPU power available in a cloud computing environment — but that's something NVIDIA hopes to change. The company announced version 3.0 of its RealityServer today. The new revision sports hardware-level 3D acceleration, a new rendering engine (iray), and the ability to create 'images of photorealistic scenes at rates approaching an interactive gaming experience.' NVIDIA claims that the combination of RealityServer and its Tesla hardware can deliver those photorealistic scenes on your workstation or your cell phone, with no difference in speed or quality. Instead of relying on a client PC to handle the task of 3D rendering, NVIDIA wants to move the capability into the cloud, where the task of rendering an image or scene is handed off to a specialized Tesla server. Then that server performs the necessary calculations and fires back the finished product to the client."
Please stop talking about "cloud" computing -- it is one of the dumbest buzzwords I have ever heard in my entire life -- not to mention the fact that it is a totally meaningless term.
To the haters: You can't win. If you mod me down, I shall become more powerful than you could possibly imagine
The last thing I want to see why I'm playing a FPS is buffering.... 32%
Idiot. "Real-time" means that you can draw clouds at the screen refresh rate, not every 5 minutes.
Awesome! So instead of buying a video card, I will now have an option to pay yet another monthly fee to play games? Im so excited!
you know you can fry stuff putting things into things that dont like the things you put into it...
Maybe those patients don't want you to know anything about themselves?
The rendering of clouds in the cloud computing will stop.
With 31% chances of rain.
NVidia's offering performs full scene raytracing/pathtracing, with effects ranging from reflections and refractions to global illumination and caustics all the way through to sub-surface scattering and participating media.
Some of these things can be done in proper realtime (say, at least, 30fps at 720p) on existing GPUs, but typically by using hacks that look 'good enough', but aren't actually correct. Which is fine for gaming (where refresh rates matter), but not fine for product visualization, architectural visualization or to go to an extreme.. materials and lighting analysis, where you don't care if it's not 30fps, but are more than happy to wait 10 seconds for something that used to take 15 minutes.
That said... if the cards keep getting faster, then eventually 30fps@720p will be possible and there's no reason, in the time inbetween, that games couldn't add the more fancy effects and have the GPGPU solutions take care of those on a 'cloud' platform.
The gaming industry has been trying to jump start the flight simulator market again.
this is the "whoops" of cloud computing and why it doesn't work for these purposes. Render farms do what they do well, and so does distributed computing. Neither of these are cloud.
Can we please stop the marketing hype for everything cloud?
Well, the new name is supposed to be for the specific case of moving traditionally local computing tasks off to farms. Doing a movie on a remote render-farm is hardly cloud computing, but re-encoding your holiday video is.
Latency aside, my worry is that you're buying a gaming timeshare. It's cheaper to pay for the computing time you actually use, in principle. However online game communities depend on lots of people playing at the same time, which is exactly the sort of thing that would make online gaming uneconomical. Example:
Somebody's got to pay for the shedloads of hardware.
If you have six users, and their usage is distributed over the whole day so each is on for 4 hours with no overlap, then you only have to invest in one "virtual games PC" worth of hardware for those six users. You've got six paying customers for an investment in one games PC! Charge them each a quarter of the cost of an up-to-date games machine over a year, and there's your profit margin (you get back 1.5 times the cost of the hardware), and the value for the end user (they only have to pay 0.25 the cost of the hardware).
If you have six users, and four of them are online at the same time because they're in the US and Western Europe and playing against each other, then you need four "virtual games PCs" worth of hardware to handle that peak demand. The rest of the day, you have two users, sharing the four computers. So over the day you're bringing in an average of three users over four "virtual games PCs" that you've invested in. It's hard to find a way to make that profitable, except having off-peak discounts to try to smooth out the usage patterns.
I guess what I'm saying is that when it comes to gaming, computing power isn't fungible.
No kidding!!! What do you say at this point?
I would if I had mod points. Parent is spot on, we've transitioned away from "cloud computing" when we moved from mainframe terminals to desktop workstations, why would we want to go backwards?
GENERATION 25: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
It's that time in the cycle where we talk about thin clients and the mainframe again. Own nothing, rent everything, submit to central control. You know what, just like the last few times, I'll pass.
Um, arent they discontinuing their high-end products because they overheat and explode? :P
So like, are they gonna use ATI cards for this or something? LOL
So if the GPU become a glorified web client how will they keep soaking everyone for a (bi)yearly card upgrade? If all of the most complex tasks are handed off to a remote server that's where the upgrades should be handled.
Also if part of the secret sauce is being handled remotely NVidia has no further excuses for keeping it's linux drivers closed.
There is still this thing called "bandwidth quota" where you get overcharged to death if you go over it. As an example, say 40$/month for 50GB, then 10$ per additional GB.
And please no stupid "change ISP" comments, a lot of people aren't lucky enough to even have a choice of high-speed providers. It's either high-speed cable/DSL, or dial-up. Sometimes from the same ISP, even.
Hell, an average of less than 3 users. If those four are online for only four hours, and your system is only loaded with two users the other eight hours, then you're only getting an average of one and a third users over four computers. How do you get one and one third users to pay for four games machines?
No kidding!!! What do you say at this point?
There's one big reason - latency. 30 FPS is one frame every 33.333ms. What's your ping time? Add the rendering time to that, and that's what your interactivity is going to look like. Remember that many games have ways of hiding the latency between client and server - in particular they know the players POV and the static environment, so those things can be handled very well.
As someone else said, cloud rendering is fine for making movies. It's not viable for games. And besides, if a GPU can do this stuff in real time, why do we need to push it into the cloud? This sounds like OTOY all over again.
BTW, CPUs will be doing realtime ray tracing soon anyway - give me a bunch of bulldozer cores and a frame buffer.
Now you can get tele-fragged by a n00b even faster, thereby enabling greater synergies for e-presence and brand recognition!
C|N>K
So, even if I had the the bandwidth to upload graphic data (geometry, textures, etc) and download 1080p video in realtime without any buffering, my 5ms Monitor would now have to deal with at least 30ms in video latency?
It happens in the sky:
http://www.penny-arcade.com/comic/2009/3/25/
Dewey, you fool! Your decimal system has played right into my hands!
A big-ass binary hairball to further clog the tubes.
How much additional traffic is this going to add to all the other interactive high-bandwidth stuff transiting the infrastructure?
--- Asking inconvenient questions for over 30 years...
I take it you don't have a render farm. If you're closer to delivery your render farm is probably completely occupied rendering final frames. If you are in the middle of a project it's probably running at quarter or half capacity. A render farm is often either over burdened or under burdened. That's a situation that's perfect for cloud computing. Instead of wasting thousands and thousands of dollars in idle machines you simply pay for the time when you need processing power. And since most of the world won't be rendering simultaneously a shared farm better distributes the investment. The only challenge now will be asset management and synchronizing a couple of GBs of scene data back and forth.
I manage and maintain a 200+ dual quad VFX render farm at the moment...I'll go get my coat. In all seriousness I've been expecting this for quite a while, ever since Nvidia brought mental images. But I cant help remembering that Intel were the ones shouting about ray-tracing cards , Nvidia was all about what ever works even if its a cheat... so ill hold fire on looking for a new job till I see some real world results.. Buttons aren't toys.
Backbone and last-mile providers are already crying about filesharers overburdening the infrastructure, especially here in the U.S.. ISPs in the U.S. typically devote well more than 95% of capacity to downstream traffic to try and cope. The modern graphics card works on a bandwidth spoken in terms of GB/s. There's no way a 50 FPS+ 1080p or better video feed from a rendering farm could be supported for every console user. While not needing as high of resolution, mobile devices communicate off of cellular networks that make in-ground network capacity problems seem petty. Even if these could be remedied, the latency involved in even a same city rendering farm would still make for a lack-luster experience.
Two of my imaginary friends reproduced once
Doing graphics work in real-time is OnLive's department. I wonder what the patent status of this will be - OnLive filed a fair few - although I don't know which specific bits they cover. Should be interesting to see which company can deliver.
OK, so you've been modded offtopic.
But I'm curious why you thought a question about publically available datasets had anything to do with cloud computing? It doesn't look as if you were trolling. So what was it you were misunderstanding?
Yes for example if my records are opened, it will be discovered my IQ is only 90, and I may lose my engineering job. Shhh.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Which makes me wonder what the point is here really. OnLive is in testing already. TFA doesn't compare to OL so I don't know why Nvidia's offering is so much better.
Nvidia and OnLive are partners: http://www.onlive.com/partners.html
These announcements are probably related to OnLive.
You realise that those restrictions are the only reason that the data could be gathered in the first place, right? People won't allow their information to be disclosed at all unless there's some reassurance about what will be done with it. Maybe you should collaborate with somebody who can get access instead of trying to work around it, if only for your own good. It's not good for your career to be known as "the guy who stole all that private medical data and wrote a paper with it". The journals frown upon ethics violations.
No kidding!!! What do you say at this point?
Ok, it's time everybody! Break those old Sun SparcStation ELC's and SLC's out of storage!
Oh, wait, you don't have one? How about all those SunRays you've got in the garage?
No?
Right.
Managing for capacity will certainly be the difficult part of running a cloud server farm.
It's fairly obvious, that if you build your farm to cope with the peaks, there will be spare capacity during the troughs.
But there are strategies to deal with this. For a start you can soften the peaks with pricing strategies. You could even offer discounts for off-peak gaming.
Plus, you could sell your off-peak capacity for other purposes. For example, a Hollywood animation could be rendered using the spare off-peak capacity on a gaming server farm. Substitute your own favourite long-running parallelisable data processing job.
Appropriately enough, given cloud computing's previous buzzword - grid computing - it's not all that different to the way power companies handle fluctuations in demand.
I suppose that's nVidia's idea with the new platform, then: to make graphics rendering genuinely fungible.
No kidding!!! What do you say at this point?
Such a hurry to post you didn't even read the summary, not even the first sentence.
Its about cloud computing, not rendering cloud images.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Apparently you work for a company who only works on one project at a time and only has one team.
If a company isn't partway into its next project by the time the current one project is done, I wouldn't want to work there - too unstable.
This is marketoid-think at its worst.
Graphic rendering requires very low latency.
Of all the things that might be done in the "cloud", realtime graphics is the silliest.
But, the marketoids have been convinced that the "cloud" is the future, so they invent nonsense scenarios where their products can be used.
1) We all had free, unrestricted and unlimited fast Internet links...
2) Our GPU could pull on the idle processing power of all GPUs in the world...
3) Everyone in the world got on with each other...(ok ok, off-topic here)...
Seriously though, there is no way that one could support the network requirements of this...How many Nvidia GPUs are sold a year? F***ing eh...multiply that by the bandwidth require for 25-50fps for a 1080p image...the number is frightening.
When all is said and done, nothing changes...
With multiple teams and multiple projects you tend to just increase the frequency of the spikes in demand not even them out. Yesterday our farm was at capacity and queued up for an excess of 5 hours. Right now there is no wait to start rendering. Yesterday we needed a farm 4x our size. Today we need a farm a quarter. But even that isn't really the way it works either. Yesterday we would prefer to have had a farm 100x our size for 30 minutes. Today we would want to have a farm 100x our size for 1 minute. It's always going to be a balance when you own your farm between potential speed and idle time. The faster your farm is the more your machines will sit idle. So if you invest in a huge farm you'll get your sequences back instantly but then your farm sits idle most of the time. If you have a really small farm you might have to wait a day but they'll always be working.
I can't fathom, though, why nVidia -- a graphics chipset maker which has nothing to do with the ray tracing you're describing -- would be interested in this.
The bandwidth between the CPU and the graphics chipset is a frequent bottleneck. This is why the graphics adapter often has a special slot (VLB vs. ISA; AGP vs. PCI; PCI-e x16 vs. PCI-e x1) and why we're starting to see the marriage of the CPU and graphics chipset (AMD buying ATI, nVidia talking about making their own CPU, Intel making graphics chips, etc.). Put this on the cloud, and your bandwidth is shot, and suddenly latency is a huge issue.
uh, do you not understand the disingenuous statement of misunderstanding what a render farm *is* versus cloud computing?
If you have a render farm, synchronizing GB's back and forth is obviously not an issue already.
People have rented out their computing for many many years, just because it's "cloud" doesn't mean it's new or creative.
If you don't want to wait for the power of their GPU servers, check out a recent project I did with NVIDIA for ray tracing realistic illumination on today's desktops:
http://graphics.cs.williams.edu/papers/PhotonHPG09/
From the abstract, "Image Space Photon Mapping (ISPM) rasterizes a light-space bounce map of emitted photons surviving initial-bounce Russian roulette sampling on a GPU. It then traces photons conventionally on the CPU. Traditional photon mapping estimates final radiance by gathering photons from a k-d tree. ISPM instead scatters indirect illumination by rasterizing an array of photon volumes. Each volume bounds a filter kernel based on the a priori probability density of each photon path. These two steps exploit the fact that initial path segments from point lights and final ones into a pinhole camera each have a common center of projection. An optional step uses joint bilateral upsampling of irradiance to reduce the fill requirements of rasterizing photon volumes. ISPM preserves the accurate and physically-based nature of photon mapping, supports arbitrary BSDFs, and captures both high- and low-frequency illumination effects such as caustics and diffuse color interreflection. "