Интересует вопрос можно ли с работы на домашней тачке поруливать евой? XP Sp3 (Прошу тех кто не пробовал реально это сделать и не добился успеха не затевать спаму) Upd По непроверенным (пока) данным Вариант раз Радмин 2.0 такой же вьюер (16 битный цвет в настройках адаптера, одинаковый резол мониторов, graystyle (глаголять что ХР сп2) Вариант два Дмваре, с отключенными опциями мирор драйвера. тоже ч\б, тоже резолы эквиваленты (успех говорят достингут в висте) Вариант тры Семера на семеру (проверить немогу на работе семку поставить не дадут, если кто может постоните результат) Вариант четыре 3 радмин + виста со стороны сервера. Google 3D graphics acceleration over Remote Desktop A friend of mine tipped me off to an interesting post on DIRECTXDEV about GPU acceleration over Remote Desktop. After some investigation with a couple of machines, I discovered that yes, it is actually true that you can run 3D apps over Remote Desktop (Terminal Server). The key is that the machine you are remoting into must be running Windows Vista with a WDDM driver. Beyond that, it actually works as expected, although a bit slow. Some details: * Again, the machine you are logging into must be running Windows Vista. * The machine you are remoting from (running mstsc.exe) does not have to run Windows Vista. * You do not have to use version 6 of the terminal services client -- version 5 that comes with Windows XP works fine. * This doesn't appear to have anything to do with Avalon remoting, which allows Aero Glass to be shown over RDP. Supposedly you need both machines to be running Vista to do that, and you definitely need at least Ultimate or Enterprise on the target machine do it (I tried it with Business and it didn't work). 3D acceleration works fine with XP to Vista Business. * You do not need any of the "experience" options enabled -- bitmap caching, desktop composition, effects, etc. They can all be disabled. * Both OpenGL and Direct3D 9 work. Regular D3D9 is fine; D3D9Ex is not necessary. * Direct3D 7 does not appear to work. I tried the old "I've got some balls" standby, and the only D3D driver that showed up was the software renderer (RGBRast). * All 3D acceleration takes place on the server; only the image is sent to the client. * Pretty much all D3D9 caps are intact, just as if the app were running locally. Even scanline queries work (!), although I'm not sure what it actually reads. Now, the downside: it's slow. Really slow. So slow that I'd say it's basically unusable unless you're on a LAN, and a fast one at that. It looks like Terminal Services tries to send over the data from every Present(), and it blocks the app until that happens, instead of just skipping frames. It eats a lot of CPU in the process, too, instead of just waiting. I was just barely able to push 640x360 video at 24 fps with VirtualDub's D3D9 display minidriver, which was throwing about 10MB/sec across the gigabit LAN here -- probably about the best that the consumer-level hub can do. Readback doesn't seem to be a problem, at least not on the GeForce 6 and 8 cards I have here, because everything speeds back up if you cover enough of the 3D window. Basically, this means that 3D support is usable with apps that just use it for 2D acceleration or otherwise static rendering, but anything dynamic like a video player or a game is going to be far too slow. It might be more viable if Microsoft had implemented frame dropping, but it looks like VNC may still be better for that. What this is definitely good for, though, is running GPU accelerated apps remotely. On XP, this isn't possible over Remote Desktop because as soon as you log in all your apps are pushed onto the software-only driver. On Vista, though, they could continue to run on the server-side GPU, and performance isn't a problem if the app isn't displaying the result continuously.