Názory k článku
Linux na Steamu pod 1% podílem, AMD ukrajuje Intelu
-
Právě kvůli hrám jsme se doma před časem vrátili k dual bootu. Kvůli grafice jsme pořídili grafickou kartu, ke které jsme si museli stáhnout deb balíčky a po jejich nainstalování jsme skončili u jakési chybové hlášky a nižíšho výkonu.
Tak jsme koupili druhý harddisk, Windows... Pak se grafika nainstalovala bez problémů a po dlouhých letech opět rebootujeme do Windows.
To nižší procento je tedy i kvůli nám. Nebo neschopnosti výrobců grafických karet dělat kvalitní balíčky pro Linux.
Přesně tohle se psalo už před 20 lety... :)
-
J ouda (neregistrovaný)
Taky jsem jeden z těch, proč je to méně než jedno procento - když jsem zjistil, že SteamOS (který počítají pod Linux) funguje s VR, zaradoval jsem se, strčil do stroje další SSD a začal stahovat. A když jsem zjistil, co na něm v téhle kombinaci funguje (prakticky nula), zase jsem stahování přerušil :-(.
Možná jsem naivní, ale čekal jsem aspoň pokus o wine nebo tak něco. -
Jako jde se navazet do steamu za spoustu veci, ale zrovna wine nadstavbu proton si celkem odladili a jde s tim hrat dost veci. https://www.protondb.com/
-
k3dARStříbrný podporovatelano, dle tohoto: https://www.phoronix.com/scan.php?page=news_item&px=Proton-Work-Back-In-Wine-4.2
navic se zda ze na Proton pracuji (placeni od Valve) zamestnanci CodeWeavers, ktere jinak stoji za CrossOver, ktere take neco vraci do upstreamu...
-
Já jsem zdědil licenci na Windows, tak jsem si řekl, že si kvůli hrám udělám dualboot, a skončilo to tak, že všechny hry, které hraju, už začaly chodit ve Steamu pod Protonem a mě přestalo bavit přepínání mezi systémy kvůli hraní. Výsledkem je, že mám sice dualboot, ale do Windows jsem nenabootoval už asi půl roku. :-)
-
Inu já jsem to "vyřešil" tak, že že prostě nehraju co mi nefunguje na intelu. Mám sice ještě druhou kartu AMD Radeon RX 640 2GB, ale je to zatím natolik exotická kombinace že se mi jí pod debianem nedaří nahodit. Na Sida se necítím, tak počkám až příští rok upgradnu na bullseye a nechám se překvapit jestli mi
DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
napíše něco jiného než teď. -
AMD GPU drivery jsou součástí kernelu, v posledních letech mi cokoliv od AMD přijde pod linuxem mnohem funkčnější než cokoliv od nVidie. Ale je fakt, že nemám zkušenost s těmito mobilními čipy. Ale vzhledem k tomu, co píšeš o tom Debianu, je dost pravděpodobné, že by to na něčem novějším fungovalo líp.
-
No, jak...
Stálo mě to hromadu času vybíráním HW, abych mohl udělat pohodlný a funkční PCI-passthrough, bez nějakých extra patchů, overridů apod.Tenhle soupis, vysvětluje vše:
OS:
Host: Ubuntu 18.04, dm-crypt, zfs, kvm, libvirt + qemu 5.1.0
Guest: Windows Server 2019 on q35-5.1
Host Specs:
MSI X470 Gaming Pro
Ryzen 2600, 6x core, 12 threads(only 1 dedicated core(2 threads) is accessible for Ubuntu)
32GB DDR4 2666MHz
AMD Sapphire RX580 8GB
Some shitty nVidia for host graphics
Samsung 950 Pro 500GB
Samsung 960 Evo 500GB
2x WD Raid Edition 2TB
2x WD Green 2TB
Guest Specs:
Host-model libvirt setting with 5x dedicated core(10 threads), pinned, isolcpus used
20GB RAM allocated via hugepages
120GB mirror on SSD
1,7TB mirror on HDD with SSD boost(2x 120GB ZFS L2ARC cache)
3,4TB stripped HDD with SSD boost(2x 120GB ZFS L2ARC cache)
AMD Sapphire RX580 8GB via pci-passthrough, vfio-pciMohu poskytnout i funkční konfiguraci libvirtu, kterou používám, podporuje kde co, od funkčního trimu pro prolínání volného místa na ZFS datasetu(na Ubuntu 18.04 mám extrémně špatnou zkušenost s blokovými vdevy ZFSka, nakonec je to v rawu souboru v datasetu(možná vyřešeno, jsem línej to zjišťovat)), po poslední hyper-v featury qemu, pro pohodlný běh Windows Server 2019.
Možná by tak fungovaly i Windows 10, ale nedávno mi poslední insider-build shazoval qemu, tak jsem dále nepátral, Windows Server mám kvůli pozvolnějším aktualizacím(předpokládám méně problémů v KVM) a pohodlnosti souběžných RDP přístupů.
Jen jsem tedy nečekal, že v systému od Microsoftu, nepůjde Xbox One gamepad bez obskurní instalace ovladačů na Xbox 360 gamepad z Windows Vista. A i tak, funguje jen po USB kabelu, přes bluetooth mám kompletně smůlu.Asi nejobskurnější případ mě potkal s Red Dead Redemption 2, kdy mi hra po Naturalist Update, hned po hlavním menu padala na 0x000005 status_access_violation.
Náhodou jsem narazil na někoho na Redditu, co poradil rekompilovat qemu, kde se nahradí stringy BXPC a BOCHS třeba na FCKS "RCKS " a upravit veškeré možné sm-bios informace, kde se nahradí string QEMU, za cokoli jiného..
Bum, ono to začalo fungovat, nevěřil jsem vlastním očím.2. 12. 2020, 20:05 editováno autorem komentáře
-
Mam celkem vyhodu, ze spolupracuji s firmou, co mi tohle licencne dokaze pokryt.
Ono je to vcelku hodne primitivni https://git.my-web.xyz/milan/qemu-builds-mm/src/branch/stable-5.1.0-rdr2-fix
Nasel jsem, ze diky unikatnosti vyskytu techto stringu, by to slo udelat bez rekompilace i takto:
hexdump -ve '1/1 "%.2x"' qemu-system-x86_64 |
sed -e 's/424f4348/434f4348/g' -e 's/42585043/44585043/g' |
xxd -r -p > qemu-system-x86_64.new -
Uprimne, v hlave jsem to mel hodne dlouho, ani si nedokazu vzpomenout, kdy se mi v hlave zrodila myslenka o podobnem setupu.
Myslim ze prvni verze, byla hotova za tyden od koupi HW, ale delal jsem na tom jen ve volnem case. Za 6 mesicu pouzivani jako Gaming/Work station jsem zjistil par veci, ktere kdyz jsem v konfigu libvirtu zmenil, Windows pri urcitych operacich chciply, ale po reinstallu na ten a samej nove konfigurovanej virtualni HW, funguji uz skoro.rok skvele.
Ja ti nevim, on sel lag sem, lag tam, radek v konfigu sem, radek tam. Na vse jsem prisel postupnym pouzivanim.
Ted vim jen o jedne veci, co zpusobuje micro-lagy a to jsou CCX ve starsich Ryzenech nez rada 5000(ktery ma alespon 8 jader per CCX).
Ja totiz na CPU setril a mam 2x CCX po 3 jadrech.. No a zatim nevim, jak libvirt donutit, postavit si CCX dle sebe a predstavit to systemu tak, jak chci ja.
Druha moznost je mit ve virtualu jen 3 jadra, aby nedochazelo k cache-missum na L3, ale... To uz mam radeji microlagy, nez v pripade nutnosti rebootovat Win(ale nemam pokoumane pridavani/odebirani vCPU za behu systemu, treba to taky jde). -
Threadrippery inzerujú svoju topológiu vrátane NUMA cells, práve kvôli CCX. Predpokladám, že Ryzeny to robia tiež.
virsh nodeinfona TR1900X vypíše niečo takéto:CPU model: x86_64 CPU(s): 16 CPU frequency: 2066 MHz CPU socket(s): 1 Core(s) per socket: 4 Thread(s) per core: 2 NUMA cell(s): 2
každý vCPU je proces v host systéme, ktorý podlieha scheduleru hosta. Pre vCPU nie je alokovaný celý procesor! No a keďže je to proces, tým pádom nástroje ako numad môžu udržiavať afinitu v rámci CCX.
Pokiaľ by to nestačilo, možno by stálo za to vyskúšať nakonfigurovať guestovi numa topológiu explicitne
<numa><cell cpus="..."></numa>. -
Bohužel, Ryzen 2600 se tváří takto:
root@ryzen-main:~# virsh nodeinfo
CPU model: x86_64
CPU(s): 12
CPU frequency: 3643 MHz
CPU socket(s): 1
Core(s) per socket: 6
Thread(s) per core: 2
NUMA cell(s): 1
Memory size: 32886000 KiBZkusím si pohrát s tou topologií, je možné, že to nějak půjde. :-)
Mít virtuál jen na jednom CCX je řešením, nicméně příjdu o 2 jádra(4 thready), které se v době, kdy potřebuji výkon, dost hodí.
Něco o tom načtu, možná libvirt přesvědčím, aby CCX pro guesta rozdělil tak, že 3 jádra je jedno CCX, dvě jádra druhé CCX, každé má svou L3 a micro-lagy pominou..
Pokud se mi to povede, dám vědět. Asi je pravděpodobnější, že si pořídím Ryzen 5800x, kde je jen jedno CCX s osmi jádry a vůbec to nebudu muset řešit.
-
Je realita, že z hlediska her Linux nenabízí proti Windows v podstatě žádnou výhodu. Osobně Steam na Linuxu používám, protože na hlavním pracovním počítači mám Ubuntu, hraju občas, abych se odreagoval a dual boot se mi nechce muset řešit (navíc by to byl opruz). Kdybych byl obsedantní gamer nebo měl počítač vyhrazený na hry, pak fakt nevidím důvod, proč tam nemít windows, kde je katalog her mnohem větší a problémy s podporou hw mnohem menší.
-
Po létech boje s wine/protonem/lutrisem/GPU passthrough/.... a kdy se s každou novou verzi jádra/ovladače grafiky/wine/... něco rozbilo, jsem taktéž uznal, že sebemrskačství bylo dost. Spočítal jsem si, že strávený čas*hodinová taxa už několikrát překročilo cenu separátního herního PC. Takže jsem postavil čistě herní PC s windows. Nemusím řešit kompromisy, že herní mechanická klávesnice mi moc nesedí na práci (o myši nemluvě), že na hry chci 144Hz a na práci zase raději 4k atd. Na herním PC si mě může MS špehovat od rána do večera, nemám s tím problém. Reinstall trva 15 minut a steam library je na separátním disku takže ani případný fail (zatím se mi nestalo) při velké aktualizaci Windows nevadí. Maximální spokojenost. Doporučuji.
-
Anebo to proste pod wine spustite, a teprve pokud to nejede tak resite proc. Bud se tomu chcete venovat, a hrabat se v tom ktera knihovna potrebuje nahradit, nebo se spolehnete na automatizace jako je PlayOnLinux nebo Lutris (nebo jine).
Obvykle pomaha se nejprve podivat na https://appdb.winehq.org - pokud ma hra dobre hodnoceni, neni potreba nic resit a jen se to spusti.
-
Co poradíte?
Řeším problém s virtualizovanými WinXP na Ubutnu.
Mám je ve VMware Playeru a aktuálně řeším problém s tím, že když se uvnitř okna spustí program, který změní rozlišení, tak se velikost okna virtuálu změní a po skončení programu se nevrátí rozlišení, ani velikost okna zpět.Potřeboval bych zajistit, aby okno s virtuálem mělo pevnou šířku výšku a neměnilo se podle rozlišení, které si přepne program uvnitř něj.
Je nějaký způsob, jak ve správci oken zafixovat velikost okna?
Nebo jiný způsob jak to řešit?----- Pozadí toho co řeším. --------------
Správcuji kompy pro školy se staršími kompíky, na kterých běhají rozumně jen WinXP (Pod tím si představte něco jako 1,8 GHz CPU 1x Core, 1GB RAM, integrovaná grafika která má skoro podporu OpenGL 2.) Nepředstavujte si nějaké výchozí krabicové nastavení XPček, jsou to hodně vytuněná XPčka.
Je to odladěné, fungující, v rámci možností zabezpečené, ale problém je s prohlížeči, které už XP hodily přes palubu a KMeleon to asi nezachrání.
Na serveru je Linux se Sambou.V těch XPčkách běhá cca 250 výukových programů, 350 vybraných her, cca 100 ks dalších programů typu GIMP, Inkcape, LIbreOffice, editorů, a dalšího SW vybavení.
Teď se ke mě dostávají "novější" kompíky se 4GB RAM a já hledám cestu jak to "obrovské množství" RAM a výkonu využít k vybudování systému, na kterém to všechno poběží stabilně dalších 10 a více let.
Plácnout tam Win10 nejde, protože v nich neběhá významná část výukových programů a něco jako spouštění v režimu kompatibility má pozitivní efekt tak u < 10% z těch co nefungují.
Zkoušel jsem i Win98 virtualizované přes virtualbox, ve kterých běhalo cca 80% výukových programů a stačilo by jim nepoměrně méně HW zdrojů, ale tam jsme narazil na to, že Win98 už nejsou u Virtualboxu moc dobře podporované. Především oblast podpory 3D grafiky je bídná.
Takže prošlapávám cestu mít tam Linux a provozovat ty odladěná XPčka, ve kterých všechny ty programy fungují, virtualizované.
Pomocí nástroje "VMware vCenter Converter" se mi to po menším zápase podařilo zvirtualizovat a rozběhat v nich i 20let staré, SW náročné programy, takže je to asi schůdná cesta.
Aktuálně mi dělá problém to resizování okna po vypnutí starých programů, které třeba jedou v rozlišení 640x480.Zkoušel jsem ty výukové programy rozběhnou ve Wine / PlayOnLinux, ale úspěšnost je víc než bídná.
Paradoxně ty nejstarší, dělané pro dos běhají v DOSBoxu převážně pohodově.Za případné postřehy a tipy budu rád.
PS: Opravdu se nechci na ty staré programy vykašlat a hodit je přes palubu. Učitelé je znají a ví, co z nich kde použít a za některé dodnes není adekvátní náhrada.
-
Přehazuji dotaz do poradny:
https://forum.root.cz/index.php?topic=23993.0
ČLÁNKY DO MAILU