Vlákno názorů k článku Revoluce: Microsoft vydává DirectX pro Linux (ale jen pro Windows 10) od LarryLin - V článku se uvádí, že aplikace v Linuxu...

V článku se uvádí, že aplikace v Linuxu "může dostat 100 % zdrojů/výkonu GPU.". Předpokládám, že těch 100% není myšleno doslova, protože tam bude nějaká režie ovladačů, které se starají o to kolik výkonu dostane která aplikace. Předpokládám, že toho výkonu bude max. 95%, ale spíš výrazně míň (70-80%).

No a pak je druhá věc latence, tzn. prodleva mezi "výpočtem" na fyzické GPU, přes přenos obrazu přes mezivrstvy hlavně přes ovladač dxgkrnl až po samotné vykreslení grafiky v subsystému Linuxu. Odhaduji to na desítky ms čímž to nebude vhodné pro realtimové aplikace.

To co píšu jsem zatím nikde nezjišťoval a neověřoval (v této rané fázi stejně benchtesty nebudou), ale píšu to ze zkušenosti s vga-passthrough na Linuxu. Pokud k výkonu a latencím někdo má nějaké bližší info nebo má nějaký důvod si myslet, že bude výkon a latence jiný než co píšu, rád se nechám poučit.

Toho by som sa nebal.

Aj pri nativnom stacku je driver zlozeny z dvoch casti - userspace dll, ktora pripravuje buffery na spracovanie a uklada ich do fronty a kernel space driver, ktory ma na starosti alokaciu zdrojov a pripravene buffery vo fronte posle na hardware.

Hyperv vie sockety medzi virtualnymi strojmi, ktore su vykonovo na tom rovnako ako nativne sokety v operacnom systeme. Takze ked budu mat userspace cast ovladaca nativnu linuxovu, ktora posle svoje data cez tenky shim v jadre a ten to posle rovno kernelovemu driveru v druhej wm cez hyperv socket, tak vykon bude velmi blizko nativnemu.

Když v Hyper-V nainstaluješ Windows 10 jako guesta, tak není žádná možnost jak by mohl guest i hostitel využívat stejnou GPU a přitom se přiblížit nativnímu výkonu. RemoteFX má velké výkonostní propady a o jiné technologie sdílení jedné GPU mezi guestem a hostitelem nevím. Profesionální Nvidia karty Quadro, které to umí vynechme.

Opravdu si myslíš, že když se neumí nativnímu výkonu přiblížit guest vyvíjený přímo Microsoftem (Windows) na hypervizoru vyjíjený přímo Microsoftem (Hyper-V), tak že to bude umět lépe za použítí kernelu Linuxu?

Pochybuji.

Nie je tam taka moznost, pretoze neexistuje driver, ktory by robil to, co v linuxe robi shim pre /dev/dxg. Teoreticky by Microsoft mohol pripravit takyto driver aj pre Windows, je tu zopar ale:

- ten driver funguje iba v ramci hosta. Ak ho virtualka pouziva, neexistuje moznost premigrovat ju na ineho hosta,

- tym padom Microsoft nema motivaciu spristupnovat to pre genericke virtualky, ale iba pre specificke, ktore vzdy budu lokalne - ako je prave WSL2 alebo Windows Sandbox.

RemoteFX je nieco uplne ine.

Virtuálky používají spoustu funkcionalit, které znemožňují migraci, přesto to není důvod, aby daná funkcionalita nebyla implementovaná. Např. virtuálka na Hyper-V umí VGA-pass, která taky znesnadňuje migraci. Nevím jestli to umí Hyper-V, ale na linuxu v Qemu můžeš virtuálce nastavit "Host passthrough" CPU, která také není doporučována pro migraci. Takových věcí znemožnujích migraci bychom určitě našli více, takže to není příliš pádný argument, proč by to nemohlo fungovat ve virtuálce Windowsu pod Hyper-V.

Ano RemoteFX funguje jinak než implementace popisovaná v článku, ale cíl je stejný - poskytnout virtuálce 3D akceleraci a MS nic lepšího než RemoteFX nemá. Kdyby to bylo jen o těch "rychlých" soketech, tak už by to měl. Poptávka podle mě je.

Existuje sdílení iGPU Intelu přímo na úrovni grafického ovladače, a uvádí se, že dosahuje cca 80% nativního výkonu. Proto jsem skeptický k tomu, že by se Microsoftu podařilo dostat se na úroveň téměř 100%. Na takovou hodnotu se nedostaneš ani s VGA-pass a to je ta nejvýkonější metoda na sdílení, přesněji předání GPU mezi guestem a hostitelem.

Vsadím svoje boty, že nad 90% nativního výkonu se nemají v MS šanci dostat.