I understood, and just because I understood I suggested you to proceed by steps First use RemoteFX, learn to configure it, look if it meets your needs and so on. THEN Start to evaluate if it's worth for you to mod a current build Rome wasn't built all in a day. No, I purposely never make ready meal. Like I wrote I spent days experimenting and testing to get the result that is detailed on the first post. I mean that is MORE detailed than I wish. Learning implies fatigue, implies errors, implies failures. More detailed tutorials are good just to reach the end result taking shortcuts, and not learning anything. So, if you really want to learn something about dism, imaging, package extraction and so on, just ask about doubts on single points aren't unclear to you and I'll be glad to help
I agree, losing RemoteFX was a pain, however, I had no issues running with GPU-P following the link I gave, the adapter appears in the guest OS, no error 43 or anything, whether it actually improves anything is hard to same, it was more of an experiment than anything, given I only have the integrated GPU to play with on the server.
As an update after having a play around, I can assign things like MPC or VLC to the AMD graphics adapter in the graphics properties, so it is certainly recognised in the guests
Agreed. We need to be able to have confidence in design decisions for the long term. Not to mention live migrating rich VMs for no reason will never get old. @acer-5100 thank you again for your efforts. I've decided to go and stick with GPU-PV for now, as it's easy with WDDM 2.5+ GPUs, all APIs are intact including hardware encoders/decoders and a brief restart to migrate a VM is a small price to pay. Who knows, Microsoft could easily shut down the WDDM interfaces for GPU-PV if a devastating vulnerability emerges. Although the stakes are higher with containers and WSL now.
@acer-5100 indeed, m$ should have been sued hard and i have had a good time reading your posts trying to motivate
@RogerUK @uultimaa Sorry for missing the last replies, in this thread but when they were posted I was sick.... So I would spend a couple of words about GPU-P that I had finally the chance to test (albeit in a underpowered machine). Given it's poorly documented and there is a lot of confusion about it I summarize below what I discovered. #1 It works starting from 1803 #2 It works out of the box on clients only. Servers (theorectically) needs GPUs specifically made for Servers, but that's can be worked around using the following registry entries Code: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\HyperV] "RequireSupportedDeviceAssignment"=dword:00000000 "RequireSecureDeviceAssignmen"=dword:00000000 "RequireSecureDeviceAssignment"=dword:00000000 #3 Yes, If you have a Remote FX enabled installation from 17134 (1803 April 2018 Update) to 1904x.926 (2004/20H2) or any supported system until March 2021, or a patched system following the tutorial I shared in this very thread, you can use both Remote FX and GPU-P working at the same time. #4 In 1803, to get GPU-P working the guest must be a 1803 machine as well (including my unofficial Server 2018). Starting from 1809 you can mix hosts and guests: say Win 11/Server 11 as host, Win 10 1809/Server2019 as guest, and viceversa (and everything in between) #5 The GPU must support DirectX 12 (or newer) level (Remote FX requires DX11 starting from Win8, or DX9 in Server 2008R2) #6 Unlike Remote FX there is no support for 32bit machines #7 Although the scope of GPU-P and Remote FX may look similar it's not the same: RemoreFX was (is) aimed at underpowered/older clients allowing them to use the server's power to run applications and games otherwise forbidden to them. GPU-P is more a way to play something installed remotely (possibly on a Azure server), but requires a reasonably powerful client to manage the graphic load. It's also a way to have the GPU capabilities on a local Hyper-V machine, something that VMware does well since the dawn of time, but was once impossible for Hyper-V. Given the above comparing the two is basically pointless, they overlaps only partially, but assuming you can run both of them there are some notable differences in their usage.... RemoteFX wins hands down looking at input responsivity/lag, and wins hands down if compared to anything else including VMware and it's long standing DirextX support. RemoteFX wins also hands down when playing older DX8/9/10 games (the mileage obviously vary depending the application), while GPU-P given it uses the real GPU driver may not play many of them at all, just like the physical machine, unless you use wrappers like DGvodoo. GPU-P likely plays better with recent games/apps, also it may expose some non graphical features like accelerated video decoding/encoding and alike Like I wrote above GPU-P has no 32 bit support, which is a big con if you care about resources, RAM usage, disk usage. Speaking of disk usage, having to copy all your physical GPU driver manually TWICE in the guest, that means that for recent GPUs you are going to "waste" more than 1GB of space for each GPU-P VM you want to use. Perhaps the same driver may take more space in the VM than in the host, given the files are copied TWICE rather than being copied once then hardlinked in the system directory like happens in the physical machine. RemoteFX drivers, are small, and they are already there in anything from server 2008R2 to Server 2022, so practically no additional space is used. (yes server 2022 lacks the Remote FX feature as host, but can be used as Remote FX guest, out of the box. Last but not least RemoteFX is pretty simple to configure, especially on 1803 and earlier, or if you install my patch to have the graphical configuration. GPU-P requires a lot of manual steps both powershell commands and files copied manually, and can be frustrating when you start with it the first time. #8 You can switch the same VM from RemoteFX to GPU-P and viceversa, but in my experience going from GPU-P ro remote FX always work, while the opposite direction sometimes breaks things. For now I think it's enough.
Seems I missed this topic, when it was active, please allow me to ask few brief questions: 1) If I add GPU to RemoteFX, it can't be used on host? (meaning I need two GPUs, for example a built-in Intel HD for RemoteFX and external for host OS)? 2) Can that be repeated on 26100 (assume, no) 3) For 1904x, is there available a package/script already created, - set of CABs and batches? Where to get the following files from (Microsoft.Virtualization.Client.dll v 1836x.1237, Microsoft.Virtualization.Client.Management.dll v 1836x.693, Microsoft.Virtualization.Client.Settings.dll v 17134.1 & Microsoft.Virtualization.Client.Settings.resources.dll v 17134.1610) 4) For GPU-P the site lists server models of GPUs, like nVidia A and L series only. No support for client GPUs? Intel Arc? Thanks!
Tried 19041.1 - RemoteFX is view-only in VM properties. If I replace DLLs from older (Microsoft.Virtualization.Client.dll v 1836x.1237, Microsoft.Virtualization.Client.Management.dll v 1836x.693, Microsoft.Virtualization.Client.Settings.dll v 17134.1 & Microsoft.Virtualization.Client.Settings.resources.dll v 17134.1610) Hyper-V Manager MMC fails to start
Unfortunately no. That would require replacing the whole Hyper-V package with old, and that isn't possible. Can you help me to make it work on modern 1904x? So that I can add/configure it?