If you want to design UIs (several pages, a single page is fine) Inkscape will prove painful.

Here is a guide from some other user: https://github.com/saveriomiroddi/vga-passthrough was really helpful but I needed to give up since my mainboard was too stupid and my graphic card didn't worked as I wanted. I could install the OS but it bootlooped after installing any driver.

I used an asus b350-m mainboard with a AMD Ryzen 5 1500x + a radeon r9 280 (thaiti based basically the same as an hd7970) and it didn't worked since my mainboard only had one pci express 16x which meant that the "better" card needed to be used for the main os. You can use the first slot card for the os but it might not always work (hardly hardware dependant). Having a good mainboard is way more important for it to work.

On consumer hardware, it can be hard to find out if you even have IOMMU support, required for passthrough. It's not necessarily new but a lot of hardware doesn't support it. Unfortunately for me, my i7-3770k did not have it (but the i7-3770 non-K did). I did the hypervisor build on a new enterprise-class workstation with a Supermicro motherboard.

I use libvirt for the config. I started to build a custom kernel to enable some extra features, since I had to compile dev branches anyway to troubleshoot periodic hard locks on kernels 4.12 and 4.13, but the setup should work with a stock kernel.

For me, the biggest hangups on the checklist were:

a) Ensure 100% UEFI everywhere. It's possible to do this with BIOS but as far as I understand, not well tested anymore. It can also be hard because of the way boards are sort of straddling a middle ground between UEFI and BIOS; if you don't set everything to explicit UEFI in the setup, it may init the system with either, or may init the BIOS first for hardware compat, which will make things weird.

If your video card is slightly older and from the time when UEFI was just getting supported by PC mobos and does not have UEFI boot, you may be able to find a UEFI-compatible video BIOS online. I had to do this for my GTX 670 (I use a 1070 most of the time though, and it did not need this).

b) Kernel VGA options, particularly video=efifb:off. In theory you don't need this but it depends on your board, hardware, etc. Ensures that the video device is available for vfio-pci to grab and block out other drivers that may try to grab it later. The downside is no video out after the bootloader so you can't watch the boot process. I use a USB serial port to watch the boot now, but for a long time I just waited until SSH came up, and if it didn't come up, used the systemd emergency console to try to poke it blind. This made things far harder than necessary. Get serial output ASAP, or use a board with a built-in IPMI. Didn't realize it was possible to order the workstation I got without it, or I would've made triple-sure I had it. Would've made things way less aggravating.

Along the same lines, having multiple GPUs helps a lot with this, especially if you can configure your system and/or move things around in their slots so that the one you don't want to passthrough gets initialized first. Then you don't have to worry as much about competing with the system EFI, bootloader, or kernel for raw control over the device. Not strictly necessary, but useful.

c) nvidia Code 43 on passthrough. This is nvidia trying to extort some sort of ridiculous data center license out of you or something. There are various potential fixes that are somewhat easy to find floating around, particularly QEMU flags, but this is another one that you just have to poke around until you find a combination of options that work. For recent drivers, one of these things is setting the initial substring of your mobo name to a recognized consumer vendor in QEMU/libvirt.

d) For good sound in the Windows VM, need to hack the driver ini to use MSI for interrupts, which requires running in Windows "Test Mode", aka unsigned driver mode. This breaks some anti-cheat software and I returned PUBG because it didn't allow the game to start while Windows is in Test Mode. You also have to set / tweak specific custom args on QEMU and the host's PulseAudio to get the timing right. Without this, the audio drifts very noticeably out of sync. Alternately, passthrough your sound card or use HDMI audio.

Obviously there were a bunch of other little hiccups but this is what stands out to me off the top of my head. Best resources are Arch Linux wiki on passthrough, Proxmox forums, and /r/vfio.

All this said, the biggest source of pain was not related to IOMMU or virt at all, but rather LVM2-based thin provisioning and device mirroring before I switched as much as I could to ZFS (still working on the last few pieces). ZFS is somewhat stricter but it works reliably. LVM would frequently make boot hang, fail to reinitialize the volumes correctly, etc.

Happy to help anyone going down the same road. It's really a great setup once it's running and I'm sure there'd be more envy for it if I had the energy to do a big write up that showcased it to everyone. :P

"Gold" and "Platinum" obviously mean different things to different people. If you go strictly, it's hard to call anything "Platinum" because almost everything has some differences in behavior v. native, even if they're only cosmetic. If a tester hasn't run into any, it's more likely that they've just done a superficial check of the program, said "Yep, it launched, looks like everything is here", and submitted "Platinum".

AppDB's moderation perspective and codebase was badly outdated when I was involved (several years ago now). I haven't checked on it recently so maybe they've redone things, but this is why you've seen inconsistent entries in the past.

As for the Windows environment, yes, different programs need different registry settings and other environment hacks. The main company that funds Wine development makes their money by selling software that manages these environments. There is also a free script called winetricks that will help install programs with the correct environment settings.

Despite semi-complex environment management requirements and the outdated AppDB code, Wine remains one of the most impressive pieces of software in production today. It's an extremely ambitious project and it's handled very professionally. It's a great all-around reference point for code quality, standards, and community. Alexandre Julliard is a deeply underappreciated BDFL and IMO his name belongs up there with other open-source luminaries.