Před nějakou dobou jsem do svého retro stroje koupil Asus Radeon R9 280X, což není nic jiného než přeznačený Radeon HD 7970 a také to nejlepší co moje sestava zvládne. Pod Windows XP to trhá asfalt a všechny dobové hry běží na max. Teď ještě čekám, až mi naběhne možnost upgradu na Kubuntu 26.04 s novým kernelem, ať můžu konečně rozjet amdgpu driver. Jen je škoda, že na svých Opteronech 180 už nespustím Steam, takže pod Linuxem jsem s hrami dost limitovaný.
Měl jsem HD 7850 v dnes již retro desktopu, i kvůli podpoře XPček. Mám tam quad boot Windows XP, 7, 10 a Linux. Ta GPU už pak blbla, takže je vyměněná za myslím 270, z té zmiňované další generace, identická architektura. Tu jsem v Linuxu nezkoušel, ale předpokládám, že to bude stejné. Tu HD 7850 jsem zkoušel naposled před necelými 2 lety a byla to tragédie: standardní ovladač měl staré OpenGL a žádný Vulkan. Experimentální driver měl nové OpenGL, ale to je mi na Steam stejně k ničemu. Dnes se hry emulují přes Vulkan, a v tom experimentálním ovladači není dokončený. Některé hry jely stejně jako ve Windows, některé stejně ale do pár minut zamrzly, některé se ani nespustily - v konzoli vypsal názvy chybějících funkcí v ovladači GPU. Prý nedávno dostaly tyhle historické AMD GPU nějaký nový ovladač, už to zkoušet nebudu. Procesor tam je Xeon od prvního Core i, takže splňuje i požadavky Windows 11 (SSE4.2), v tomhle problém nemám.
O tom, co píšeš, je celá ta podstat věci. Tyhle staré Radeony až po GCN 1.0 a HD 7970 konkrétně už od Linuxu 6.18 jedou s ovladačem AMDGPU, jak ukazuje tento můj článek. S ním můžeš normálně hrát, co chceš, v mezích toho, co to železo reálně utáhne. Mám tu btw třeba ještě Radeon HD 7790, což je prozměnu první model z "GCN2" generace. Taky no problemo.
Tak jsem upgradu na Kubuntu 26.04, nové jádro s podporou amdgpu pro HD7970 a je to jako magic, grafika teď trhá asfalt. Minecraft šlape jako z praku, Amnesia: A Machine for Pigs, která se na starém driveru skoro nehýbala běží jako z praku. Dodám, že nové Kubuntu běží na Waylandu, takže fachá nejnovější desktop na čerstvém distru. Víc jsem toho zatím zkusit nestihl, ale obrovská spokojenost. Tady byl odvedený obrovský kus skvělé práce.
Tam pokud se nepletu je problém v architektuře. Jde ještě o TeraScale, tedy pre-GCN. Není pro to ofiko Vulkan ovladač, jsou snad nějaké komunitní pokusy, ale nic spolehlivě fungujícího. A portovat RADV / AMDGPU s ohledem na velmi odlišnou architekturu je taky asi v podstatě nemožné. Takže buď jet hry přes "WineD3D" a OpenGL, což často znamená třetinový výkon oprotu Vulkanu na stejném GPU, nebo smolík pacholík.
Skvělé. Něco podobného jsem měl v driveru pro ATI Rage Pro 4 MB. OpenGL driver použil hack a odswapoval všechna data X11 (např nacachované bitmapy fontů) z VRAM, abyste měli všechnu VRAM pro hru. Tedy přesněji mínus plocha Linuxu, protože narozdíl od Direct3D nemůže hra vzít celé GPU exkluzivně pro sebe. To se částečně obcházelo nastavením o jedno menšího rozlišení než ve Windows (menší front-, back- a z-buffer plus plocha, aby na textury zbylo stejně). Taky si pamatuju na trik, že jak v OpenGL nešlo nastavit jinou barevnou hloubku než na ploše a hra si mohla změnit jednoduše rozlišení, ale ne hloubku, tak v X11 conf byl parametr "OpenGL v 16bit barvách na 24/32bit ploše". To mělo vliv hlavně na výkon, protože v TrueColor byly GPU až polovičně rychlé.
1. 5. 2026, 13:39 editováno autorem komentáře
Jak to je s ovladačema a zejména podporou OpenCL? Já jsem to tehdy používal, nejdřív byly proprietární, ty pak nějak přestaly fungovat s novým kernelem/X.org, a v otevřených se mi OpenCL nikdy rozchodit nepodařilo. Všichni tehdy psali, jak AMD má nejlepší ovladače a frčelo Linusovo "fuck you nVidia", a já měl zkušenosti přesně opačné, nVidia proprietární mi vždy fungoval na první pokus, ale tohle AMD byl porod.
Nepoužívám teď sice žádnou z takhle starých Southern Islands (SI) karet jako je 7970, ale základní OpenCL by tam mělo jít rozběhnout přes knihovnu RustiCL, co je součástí Mesy.
Ten stack je OpenCL klient -> rusticl -> radeonsi (gallium3d ovladač v Mesa) -> amdgpu (kernelový ovladač).
Možná bude chtít ještě doladit systémové proměnné, aby to OpenCL klient našel a případně zkusit povolit fíčury, jestli to bude podporovat.
RUSTICL_ENABLE=radeonsi
RUSTICL_FEATURES=fp64
OCL_ICD_VENDORS=/usr/share/OpenCL/vendors
To poslední je adresář, kde jsou vendor .icd soubory (texťáky s názvem knihovny).
U ROCm a většiny proprietárních ovladačů je to v /etc/OpenCL/vendors, Mesa to z nějakého důvodu cpe do zmíněného /usr/share, ale možná se to bude lišit podle distribuce a balíčku.
Přes RUSTICL_FEATURES se dá povolit double precision, jestliže to hardware umí, aplikace využije a nepadá to ;).
https://docs.mesa3d.org/envvars.html#rusticl-environment-variables
A teď ta problematická část okolo AMD a OpenCL přesně v duchu toho, co jste zmínil.
Mesa implementace - Rusticl zdaleka nemá všechny fíčury jako ROCm od AMD. Takže např. základní počítání, možná i Darktable může fungovat, ale např. komerční aplikace, kodeky atp., co jsou napsané a odladěné na ty proprietární stacky se nejspíš s Rusticl buď nerozjedou nebo budou padat.
Pokud máte podporovaný hardware (což tedy není generace SI), tak se dá nainstalovat AMD ROCm i s otevřeným AMD ovladačem (jádro, Mesa). To pro spousty čistě výpočetních úkolů bude výrazně lepší, ale většinou to selže v dalším momentu - OpenCL / OpenGL interop. Tzn. použití cl_khr_gl_sharing OpenCL rozšíření, které umožňuje sdílet prostředky např. mezi zobrazovacím a výpočetním částí programu.
Což prakticky používá například DaVinci Resolve (a spousta podobných programů).
V momentě, kdy to běží celé na proprietárním amdgpu-pro stacku (ROCm a všechny další ovladače z jednoho vydání), tak to funguje. Ale u té kombinované varianty - ROCm a k tomu otevřené ovladače a knihovny s Mesy, je tohle problém a v podstatě trochu věcí náhody.
Mě to třeba do určité doby chodilo na jedné stanici s RDNA2 kartou do určité verze Mesa (myslím 24.něco) a ROCm a pak se to rozbilo. Vzhledem k tomu, že už to bylo po několikáté, tak abych dodělal nějaké věci v Resolve a strávil spousty času debugováním, tak jsem rozdělil disk, nainstaloval RHEL, kde šel nainstalovat proprietární ovladač, kde to chodí.
Ale samozřejmě pokud si můžu vybrat, tak přesně z těchhle důvodů bych na cokoliv souvisícího s počítáním, video akcelerací atp. použil Nvidia kartu s proprietárním ovladačem (ideálně RTX a dál, aby tam fungoval aspoň Open Driver do jádra).
Teaser na "recenzi" nove verze Ježkově oblíbené distribuce Mageia.
Navíc můžeš ocenit Ježkovu zručnost a kreativitu v řešení problému se studenými spoji na PCB 14 let staré karty.
To není o kreativitě a zručnosti, ani o tom, že se mi tady snažíte tak trochu vysmívat. Věřte, že moje zručnost sahá podstatně dál, než tahle legrácka v textu, na který narážíte. PCB jsem spravoval 75W trafopájkou už v 90. letech a ano, vím, že SMD věci a bezolovnaté pájky nás technologicky posunuly jinam. Kdybych chtěl HD 79790 jako trvale provozovanou kartu, řešil bych její úpravu zručněji. Takže rejpanec je zde poněkud na špatném místě, že.
Ano, text je opravdu o tom, že HD 7970 jede. Ono to totiž není samozřejmé a plně to stojí na práci komunity, kterou máte za 0Kč.Sama AMD už HD 79790 dávno přestala podporovat. Jak jsem psal, její poslední ovladač pro Win je z roku 2022 a není pro Windows 11. Takže ano, článek je opravdu o tom, o čem je.