Vlákno názorů k článku Jaký je Radeon HD 7970 víc než 14 let od uvedení na trh od Jan Hrach - Jak to je s ovladačema a zejména podporou...

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=ra­deonsi
RUSTICL_FEATU­RES=fp64
OCL_ICD_VENDOR­S=/usr/share/O­penCL/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/ven­dors, 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).