This is pretty boring stuff. I mean the projectors ont eh curved screens were cool but what about gaming? anything about Nvidia's next gen? they are really falling far behind and are not really competing when it comes to price. I for one cannot wait for the debut of AMD's 6000 series. CUDA and PhysX are stupid proprietary BS.
I was about the post Rendering on Server is fundamentally, but the more i think about it the more it makes sense.
However defining a codec takes months, actually refining and implementing a codec takes YEARS.
I wonder what the client would consist of, Do we need a CPU to do any work at all? Or would EVERYTHING be done on server other then booting up an acquiring an IP.
If that is the case may be an ARM A9 SoC would be enough to do the job.
And x264 can already encode at sub 10ms latency!. I can imagine IT management would be like trillion times easier with centrally managed VM like RemoteFX. No longer upgrade every clients computer. Stuff a few HDSL Revo Drive and let everyone enjoy the benefit of SSD.
I have question of how it will scale, with over 500 machines you have effectively used up all your bandwidth...
I've been looking forward to this technology since I heard about it some time ago. Will be interesting to test how well it works with the CAD/CAM software I use, most of which is proprietary machine builder specific software... There was no mention of OpenGL in this article but from what I've read that is what it is supposed to support (OpenGL rendering offload) Atleast that's what like 100% of the CAD/CAM software out there use so it better be if MS wants it to be successful :)
Someone asked about OpenGL during the presentation and I'm kicking myself for not writing down the answer, but I seem to recall that OpenGL would not be supported. Don't hold me to that, though.
"For support for apps that require OpenGL, they're supporting apps that use OpenGL v1.4 and below to work in the VM, but they don't expect that apps that use a higher version of OpenGL will work (unless of course they have a DirectX or CPU fallback mode)."
"While NVIDIA has VDPAU and also has parties like S3 use it, AMD and Intel are backing the rival Video Acceleration API (VA API)."
Ummm wrong, AMD is using XvBA for it's video acceleration API. VAAPI provides a wrapper library to XvBA much like there is VAAPI wrapper for VDPAU. Also VDPAU is not proprietary, it is part of Freedesktop and the open source library package contains a wrapper library and a debugging library allowing other manufacturers to implement VDPAU support into their device drivers. In short every device manufacturer out there is free to include VDPAU support and it is up to the driver developer to add that support to a free and truly open API.
AMD is using XvBA, but it's mostly an issue of semantics. They already had the XvBA backend written, so they merely wrote a shim for VA API to get it in there. In practice XvBA appears to be dead, and developers should use VA API and let AMD and the others work on the backend. So in that sense, AMD are backing VA API.
As for NVIDIA, proprietary or not doesn't really come in to play. NVIDIA is not going to give up VAPAU (or write a VA API shim) and AMD/Intel don't want to settle on using VAPAU. That's the stalemate that's been going on for a couple of years now, and it doesn't look like there's any incentive on either side to come together.
It's software developers that lose out; they're the ones that have to write in support for both APIs in their products.
Deanjo, that is incorrect. VA API is not a wrapper. It is the main API from freedesktop.org. It is created by Intel unfortunately, but they help extend the staled XvMC project to a more flexible API. VDPAU and XvBA came later to provide their own way to do about the same thing. They also include a backward compatibility to VA API. VDPAU is not open source. It is just provides structs to be able to use VDPAU, so this means VDPAU can not be changed by the open source community to implement new features.
Good coverage. Always good to read new info. Often looking at graphics card reviews can get boring as I tend to sometimes just glance at the graphs and that is it. I sure wish Adobe would use GPU more for photography software. Lightroom is one software that works alright on desktops but too slow for my taste on laptops.
I'm sort of disappointed with RemoteFX. It sounds like it won't be usable remotely by consumers or small businesses who are on broadband-class connections; with these types of connections, you can probably count on half a megabit of throughput, and that's probably not enough to be streaming full-screen MJPEG (or whatever they end up using) over the net.
So, sure, works great over a LAN, but as soon as you try to, say, telecommute to your office PC via a VPN, that's not going to fly.
Even if you're working for a company with a fat pipe, many consumers (around here, at least) are on DSL lines that will get them 3 or 4 megabits per second; that might be enough for lossy motion-compensated compression like h.264, but is that enough for whatever Microsoft is planning? You lose a lot of efficiency by throwing away iframes and mocomp.
Yeah, it also makes no sense from an economic perspective. Now you have to buy a farm of GPUs to go with your servers? And the video capability now and soon being built in to every Intel CPU just goes for nothing? More great ideas from Microsoft.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
19 Comments
Back to Article
adonn78 - Sunday, October 10, 2010 - link
This is pretty boring stuff. I mean the projectors ont eh curved screens were cool but what about gaming? anything about Nvidia's next gen? they are really falling far behind and are not really competing when it comes to price. I for one cannot wait for the debut of AMD's 6000 series. CUDA and PhysX are stupid proprietary BS.iwodo - Sunday, October 10, 2010 - link
What? This is GTC, it is all about the Workstation and HPC side of things. Gaming is not the focus of this conference.bumble12 - Sunday, October 10, 2010 - link
Sounds like you don't understand what CUDA is, by a long mile.B3an - Sunday, October 10, 2010 - link
"teh pr0ject0rz are kool but i dun understand anyting else lolz"Stupid kid.
iwodo - Sunday, October 10, 2010 - link
I was about the post Rendering on Server is fundamentally, but the more i think about it the more it makes sense.However defining a codec takes months, actually refining and implementing a codec takes YEARS.
I wonder what the client would consist of, Do we need a CPU to do any work at all? Or would EVERYTHING be done on server other then booting up an acquiring an IP.
If that is the case may be an ARM A9 SoC would be enough to do the job.
iwodo - Sunday, October 10, 2010 - link
Just started digging around. LG has a Network Monitor that allows you to RemoteFX with just an Ethernet Cable!.http://networkmonitor.lge.com/us/index.jsp
And x264 can already encode at sub 10ms latency!. I can imagine IT management would be like trillion times easier with centrally managed VM like RemoteFX. No longer upgrade every clients computer. Stuff a few HDSL Revo Drive and let everyone enjoy the benefit of SSD.
I have question of how it will scale, with over 500 machines you have effectively used up all your bandwidth...
Per Hansson - Sunday, October 10, 2010 - link
I've been looking forward to this technology since I heard about it some time ago.Will be interesting to test how well it works with the CAD/CAM software I use, most of which is proprietary machine builder specific software...
There was no mention of OpenGL in this article but from what I've read that is what it is supposed to support (OpenGL rendering offload)
Atleast that's what like 100% of the CAD/CAM software out there use so it better be if MS wants it to be successful :)
Ryan Smith - Sunday, October 10, 2010 - link
Someone asked about OpenGL during the presentation and I'm kicking myself for not writing down the answer, but I seem to recall that OpenGL would not be supported. Don't hold me to that, though.Per Hansson - Monday, October 11, 2010 - link
Well I hope OpenGL will be supported, otherwise this is pretty much a dead tech as far as enterprise industries are concerned.This article has a reply by the author Brian Madden in the comments regrading support for OpenGL; http://www.brianmadden.com/blogs/brianmadden/archi...
"For support for apps that require OpenGL, they're supporting apps that use OpenGL v1.4 and below to work in the VM, but they don't expect that apps that use a higher version of OpenGL will work (unless of course they have a DirectX or CPU fallback mode)."
Sebec - Sunday, October 10, 2010 - link
Page 5 -"... and the two companies are current the titans of GPU computing in consumer applications."Current the titans?
"Tom believes that ultimately the company will ultimately end up using..."
dtdw - Sunday, October 10, 2010 - link
we had a chance to Adobe, Microsoft, Cyberlink, and others about where they see GPU computing going in the next couple of years.shouldnt you add 'the' before adobe ?
and adding 'is' after computing ?
tipoo - Sunday, October 10, 2010 - link
" we had a chance to Adobe, Microsoft, Cyberlink, and others about where they see GPU computing going "Great article, but I think you accidentally the whole sentence :-P
Deanjo - Sunday, October 10, 2010 - link
"While NVIDIA has VDPAU and also has parties like S3 use it, AMD and Intel are backing the rival Video Acceleration API (VA API)."Ummm wrong, AMD is using XvBA for it's video acceleration API. VAAPI provides a wrapper library to XvBA much like there is VAAPI wrapper for VDPAU. Also VDPAU is not proprietary, it is part of Freedesktop and the open source library package contains a wrapper library and a debugging library allowing other manufacturers to implement VDPAU support into their device drivers. In short every device manufacturer out there is free to include VDPAU support and it is up to the driver developer to add that support to a free and truly open API.
Ryan Smith - Sunday, October 10, 2010 - link
AMD is using XvBA, but it's mostly an issue of semantics. They already had the XvBA backend written, so they merely wrote a shim for VA API to get it in there. In practice XvBA appears to be dead, and developers should use VA API and let AMD and the others work on the backend. So in that sense, AMD are backing VA API.As for NVIDIA, proprietary or not doesn't really come in to play. NVIDIA is not going to give up VAPAU (or write a VA API shim) and AMD/Intel don't want to settle on using VAPAU. That's the stalemate that's been going on for a couple of years now, and it doesn't look like there's any incentive on either side to come together.
It's software developers that lose out; they're the ones that have to write in support for both APIs in their products.
electroju - Monday, October 11, 2010 - link
Deanjo, that is incorrect. VA API is not a wrapper. It is the main API from freedesktop.org. It is created by Intel unfortunately, but they help extend the staled XvMC project to a more flexible API. VDPAU and XvBA came later to provide their own way to do about the same thing. They also include a backward compatibility to VA API. VDPAU is not open source. It is just provides structs to be able to use VDPAU, so this means VDPAU can not be changed by the open source community to implement new features.AmdInside - Sunday, October 10, 2010 - link
Good coverage. Always good to read new info. Often looking at graphics card reviews can get boring as I tend to sometimes just glance at the graphs and that is it. I sure wish Adobe would use GPU more for photography software. Lightroom is one software that works alright on desktops but too slow for my taste on laptops.AnnonymousCoward - Monday, October 11, 2010 - link
Holodeck? Cmon. It's a 3D display. You can't create a couch and then lay on it.Guspaz - Tuesday, October 12, 2010 - link
I'm sort of disappointed with RemoteFX. It sounds like it won't be usable remotely by consumers or small businesses who are on broadband-class connections; with these types of connections, you can probably count on half a megabit of throughput, and that's probably not enough to be streaming full-screen MJPEG (or whatever they end up using) over the net.So, sure, works great over a LAN, but as soon as you try to, say, telecommute to your office PC via a VPN, that's not going to fly.
Even if you're working for a company with a fat pipe, many consumers (around here, at least) are on DSL lines that will get them 3 or 4 megabits per second; that might be enough for lossy motion-compensated compression like h.264, but is that enough for whatever Microsoft is planning? You lose a lot of efficiency by throwing away iframes and mocomp.
ABR - Tuesday, October 19, 2010 - link
Yeah, it also makes no sense from an economic perspective. Now you have to buy a farm of GPUs to go with your servers? And the video capability now and soon being built in to every Intel CPU just goes for nothing? More great ideas from Microsoft.