Vlákno názorů k článku Pozor na Microsoft, nakonec nás o svobodný Linux připraví od xyz - Autor vubec nevi o cem mluvi. Kdyby si...

Jenže userspace ve Windows se nevyvíjí, jen udržuje. Kvůli zachování plné zpětné kompatibility, kterou Linux nezná. Mimochodem zkoušel jsem např Windows GDI (původní GUI toolkit) naportovaný do MacOS Classic. Jel nad tím Microsoft Office 95 pro Mac.

A k té virtualizaci? Vždyť on tak Windows by default jede už teď! A jaky by byl důvod mého řešení? Kernel, který vyvíjet hlavně pro moderní servery a už i workstationy zvládá Microsoft stále hůře (např podpora více jader, škálování výkonu, výkon I/O, ...).

> A k té virtualizaci? Vždyť on tak Windows by default jede už teď!

Opravdu? Pamatuju si, že Windows ten hypervizor zapínaly například při instalaci WSL.

> Kernel, který vyvíjet hlavně pro moderní servery a už i workstationy zvládá Microsoft stále hůře (např podpora více jader, škálování výkonu, výkon I/O, ...).

A jak by si tím pomohli? Tyto věci musí nějak typicky řešit i hypervizor.

Ono to asi ani nedává smysl dávat GPU do hypervizoru. Co by s tím pak hypervizoru dělal? Měl vlastní GUI?

A praktická věc: Jak zajistíme implementaci něčeho tak komplexního jako jsou ovladače GPU? Teoreticky je možné je přepsat, ale to by mohlo být moc velké sousto j pro MŠ něco takového prosadit – i kdyby měli velkou motivaci.

Ovladače GPU se právě pro Windows dělají nejsnadněji ze všech OS. Je to jen tenká kernelová vrstva pod DirectX 12. Userspace DirectX 12 a wrappery na starší DirectX, OpenGL, OpenCL a Vulkan dodává Microsoft. Podobně v Linuxu stačí Vulkan a OpenGL je přes Zink. Nebo ve Windows 9x stačilo pro OpenGL driver implementovat jen rasterizaci a vše nad ní dodával Microsoft (vertexy, osvětlení, ... - Mini-Client Driver; v Linuxu zas bylo běžné zkopírovat softwarovou Mesu a přepsat kód rasterizace). Proto taky mohl Intel vydat dedikované grafiky s úplně novým ovladačem, podobně máme grafiku v procesoru Qualcomm. A obráceně, DirectX 12 je teď implementován přímo v Linuxu (binární ovladač ve WSL2).

16. 5. 2026, 18:15 editováno autorem komentáře

To nie je celkom tak pravda; preto mal Intel problem s kompatibilitou ked prisiel s diskretnymi ARC grafikami (najprv sa spolahol na MS implementaciu, co im bolo dane vyzrat, takze to museli riesit klasicky), AMD sustavne nieco fixuje a Nvidia si ziarlivo strazila svoj naskok v DX/OGL.

Na Linuxovej strane sa ziadne kopirovanie swrast nekonalo. Ovladace mali na vyber, bud si implementovat cely svoj stack, alebo pouzit Gallium. Stary i965 Intel driver pouzival pristup a), novsi iris pouziva pristup b). AMD islo cez Gallium vzdy.

No a samozrejme zostavaju shader compilery, co je pomerne velka cast ovladaca. Kazdy vendor si ho musi urobit sam, kedze si tiez definuje ISA sam. Niektori viac, niektori menej kompatibilne medzi generaciami.

16. 5. 2026, 19:09 editováno autorem komentáře

Passthrough jedneho zariadenia do dvoch (alebo viacerych) virtualok samozrejme ide, v pripade sietovych kariet sa to bezne pouziva.

V pripade GPU sa to pouziva menej, ale existuje. AMD aj Nvidia samozrejme za tuto moznost pytaju extra, takze to vyuzivaju len ti, co su ochotni za to priplacat, Intel to na niektorych produktoch dovoluje zdarma, ale ovladace ma len pre klientske windows a linux. Nazyva sa to SR-IOV a iste, samotna karta to musi podporovat.

A ano, kazda vm potrebuje svoj ovladac. Ved predsa vidi PCIe zariadenie, musi s nim nejako komunikovat.

Intel měl problém s kompatibilitou s DirectX 9, nakonec ho implementoval místo použití wrapperu od Microsoftu (mimochodem na GitHubu). U dedikované GPU chtějí uživatelé kompatibilitu dekády zpět, u integrované ne. Dale měl problém s výkonem (např ReBAR).

Kopírování MesaGL mluvím o dobách grafik jako SiS 6326. To ještě Linux neměl framework pro psaní GPU ovladačů.

Práce s GPU funguje ve WSL2 s různými GPU. Tam nejsou omezeni jako v bare metal Linuxu. Nemluvím o zabugovaném PCIe Passthrough, tam byste ani neměl možnost zobrazit si obraz dohromady s GPU, co kreslí desktop.

Pointa bola, ze wrappery su nedostatocne... ReBAR s nimi nic nema; a s vykonom pomaha, pretoze netreba na hostovi strankovat pamat PCIe zariadenia, je vidno cela naraz a DMA engine sa da vyuzit efektivnejsie. Problemom pre Intel bolo, ze vela dosiek vo volnej prirode ReBAR nezvladalo.

V casoch grafik ako SiS 6326 nemal framework na 3d ovladace ani Windows. Vtedy svetu vladlo Glide. Nie, minidriver v NT nepomahal, on bol dovod, preco ho IHV obchadzali (uz ked bolo treba akcelerovat T&L, co vedeli prve Nvidie Riva, tak to bola prekazka, nie pomoc).

GPU vo WSL2 funguju len preto, ze linuxove ovladace mesa (alebo compute runtime) nevolaju linuxove jadro, ako to robia v normalnej virtualke/fyzickom stroji, ale tuneluju tieto volania cez hyperv socket na hosta, kde to obsluzi windows ovladac. Je to svojim sposobom proprietarna obdoba virGL a preto aj nefungovala hned, ale az postupne, ako bola zapracovane do ovladacov na oboch stranach. AMD-ckovy librocdxg (passthough pre rocm) je v podstate verejne oznameny len par tyzdnov. No a inak PCIe passthrough, ci uz pre cele zariadenie, alebo pre VF na kartach co vedia SR-IOV, funguje velmi dobre. Mozno nie na zeleze, co ma problem aj sam so sebou alebo s ReBAR, ale na normalnom ano.

Btw, ste si vedomi, ze WSLg tuneluje vystup svojho wayland kompozitora cez RAIL? (Remote Application Integrated Locally, v podstate RDP jednotlivych okien, v tomto pripade cez lokalny socket) Nejde o priamy scanout. 3D akceleracia cez RDP ma, nazvime to, svoje uskalia (a tie sa tykaju rovnako aj virtualok s passthough a pristupom cez rdp).

Wrappery jsou nutnost, stará API jsou podporována stále hůře. Problém Intelu s chybějícím ReBARem je, že neumí pracovat skrz okno, protože na integrovaných grafikách to řešit nemusel.

OpenGL Mini-Client Driver byl ve Windows 9x, ne ve Windows NT. A měl jsem vícero grafik, které ho používaly. V té době Linux neměl hardwarové OpenGL vůbec.

Ano, řešení přenosu GPU z Guest do Host je více. Některá nejsou závislá na výrobci GPU. Řešení ve WSL2 funguje s minimální režií: Linux kreslí svůj Wayland přes DirectX, ten se posílá ven do Hosta, kde se nijak nezpracovává, rovnou se vykoná.

A prave preto bolo WSL1 opustene, niektore veci sa tam nikdy nepodarilo rozbehat, alebo neboli spolahlive -- napriklad postgresql vedel zhucat na fsync() -- pretoze aj ked syscally teoreticky odemulovane boli, semantika bola mierne ina.

Rovnako preto v linuxovom jadre pribudaju syscally s nt semantikou. Napriklad v prednedavnom vydanej Fedore 44 pribudla podpora NTSYNC.

WSL1 furt funguje. Některé věci tam jdou lépe než ve WSL2. A protože procesy ve WSL1 jedou v kontextu Windows a ne VM, tak ten PostgreSQL můžete pustit verzi pro Windows a linuxový program ho uvidí lokálně.

WSL1 je v podstate subsystem, ako bol svojho casu OS/2 subsystem pre NT. Ano, niektore veci tam funguju, zvycajne tie jednoduchsie; ak v historickom WINE, ked zacinal, jednoduche veci nemali problem.

A to ze PostgreSQL existuje aj pre Windows som nijako neporozporoval; pointa bola, ze WSL1 nie je dost dobry, aby tam bezne linuxove aplikacie - napriklad take, co pouzivaju shared memory - behali.

No a vidi ho lokalne, pretoze maju spolocne sietove rozhranie. WSL2 je virtualka, tak ma samostane sietove rozhrania. To je cele.

Přesně tak. WSL1 neměl za cíl podporovat všechny aplikace, to jde jen ve virtuálce, už z principu (potřebujete i kernel, ne jen userspace).