Portál AbcLinuxu, 13. května 2024 21:41
Před pár týdny měli kolegové z Phoronixu možnost vyzpovídat Andy Ritgera ze společnosti Nvidia. Otázky se týkaly převážně vývoje linuxových ovladačů pro grafické karty. Zajímá vás, jaký postoj Nvidia aktuálně zastává k projektu Nouveau, jaké věci plánují pro své vlastní ovladače a jak vůbec v Nvidii s Linuxem a na Linuxu pracují?
Článek původně vyšel na serveru Phoronix.com (Copyright © by Phoronix Media).
1) Jak volí ovladačový tým věci, které budou vyvíjeny pro danou verzi [ovladačů]?
Andy Ritger: Priority jsou voleny kombinací následujících faktorů:
(Pozn: Je pochopitelné, že pro Nvidii na poli linuxových ovladačů představují hlavní pilíře velcí OEM partneři kupující desetitisíce stejných grafik a očekávající maximální podporu, pak profi stanice běžící na *nixových OS, kde Nvidia dodává karty jako Quadro a Tesla. S ohledem na to, co pravil nedávno Jen-Hsun Huang a kam Nvidia hodlá s Fermi směřovat (profi segment), bude mít toto pole prioritu jistě ještě vyšší. Ale samozřejmě nezapomíná ani na majitele běžných desktopů, na různých fórech po internetu jsou lidé jako Andy celkem pravidelně k vidění, takže Nvidia v tomto ohledu i na běžné zákazníky a hráče dbá.)
2) Jakou správu kódu Nvidia používá a je členům týmu dovoleno držet si privátní větve za účelem řešení specifické věci (jako nový kernel či podpora X.Org)?
Používáme Perforce. Velké nové vlastnosti jsou obecně implementovány ve vývojových větvích, poté je tento kód, jakmile projde interní kontrolou kvality, posunut do hlavní větve. Větve vydání jsou vytvářeny z této hlavní linii kódu.
Pro různé hackování a experimenty obvykle používáme soukromé větve v Perforce. Příležitostně mohou jednotliví inženýři sledovat privátní změny pomocí nástrojů quilt nebo git před jejich odesláním do Perforce.
3) jaké textové editory nebo vývojová prostředí linuxoví vývojáři v Nvidii používají?
Většina inženýrů v týmu linuxových ovladačů používá emacs a/nebo vim pro svou každodenní práci.
4) Je vývoj dělán většinou na x86, nebo x86_64 systémech?
To je různé, záleží na osobní preferenci. Pravděpodobně většina linuxového týmu používá jako svoji vývojářskou platformu x86. Nicméně zkoušíme využít v našich testovacích strojích x86_64, protože na ní běží většina našich OEM zákazníků.
5) Jaké aplikace, nástroje a hry vývojáři používají pro testování regresí a rychlosti?
Pro OpenGL máme rozsáhlou interní testovací sadu, která procvičuje OpenGL renderovací cesty velmi dobře. Tato sada je rozšiřována inženýry z týmu OpenGL ovladače, jakmile se objeví nová rozšíření OpenGL či jakmile je ohlášen bug, který do té doby sada nezachytila. Také testujeme soulad ovladačů s OpenGL jako takovým.
Dále používáme OpenGL aplikace jako Maya, Viewperf, Unigine Tropics, ETQW, Doom 3 a samozřejmě posvátný Quake 3. Máme rozmanité interní testovací aplikace pro prověřování OpenGL Quad-buffered stereo a workstation vrstev. Také samozřejmě používáme Compiz.
A ano, občas použijeme glxgears pro rychlou kontrolu.
Pro X rendering používáme rendercheck, část xtestu, jxrendermark a hrst ad-hoc testů zaměřujících se na libovolnou cestu ovladače, na níž zrovna pracujeme.
6) Jak se změnil manažerský pohled na Linux v Nvidii za posledních pár let?
Myslím, že Linux je silný jako nikdy na trhu pracovních stanic, kam je náš linuxový tým primárně zaměřen. Myslím, že náš linuxový tým byl motorem pro řadu dalších nových technologií jako CUDA a naše virtualizační snahy; a Linux na IONu si také získal hodně pozornosti.
Interně linuxový tým vyrostl a dospěl a poslal i mnoho významných příspěvků do základního kódu [ovladačů] v Nvidii.
Jako manažer linuxového týmu Nvidie za posledních několik let vidím daleko více věcí, které bych rád, abychom dělali, ale jsem velmi pyšný na tým a vše, čeho jsme dosáhli.
7) Zhruba kolik procent kódu ovladačů je sdíleno mezi platformami Linux a Windows?
Odhaduji, že více než 90 % linuxového ovladače je multiplatformní. Softwarový GPU tým vyvinul hodně úsilí, aby náš kód byl multiplatformní (pro relevantní části). Snažíme se cokoli specifického pro daný operační systém umísťovat do tenkých vrstev rozhraní. Pár příkladů:
Kernelový modul Nvidia je téměř celý multiplatformní; většina jeho kódu běží na Windows XP, Windows Vista, Windows 7, Mac OS X, Solaris, FreeBSD a Linuxu. Ve skutečnosti, tentýž binární soubor nv-kernel.o může být použit na Solarisu, FreeBSD i Linuxu. Jen kousky specifické pro Linux jsou poskytovány jako zdrojový kód ve vrstvě kernelového rozhraní v Nvidia kernel modulu.
OpenGL ovladač Nvidie je z většiny multiplatformní; jediné kousky, které nejsou, jsou abstrahovány do vrstvy jako GLX a WGL.
Ovladač X je více unixový. Sdílí nějaký kód s Nvidia ovladači displeje pro ostatní operační systémy, ale kvůli odlišnostem v systémech zobrazování oken zde nemá smysl sdílet příliš mnoho kódu.
Ovladač VDPAU je ovlivněn řadou nízkoúrovňových algoritmů pro dekódování videa z ovladače pro Windows.
Nemohli bychom poskytovat tak dobrý linuxový produkt, kdybychom neměli tolik základního multiplatformního kódu.
8) Kolik lidí pracuje na linuxovém ovladači v Nvidii? Pokud nemůžete zveřejnit přesné číslo, jaký je poměr mezi týmem ovladače pro Linux a Windows?
Lidé kolem GPU softwaru jsou organizováni do týmů zaměřených na vývoj multiplatformního kódového základu, týmů zaměřených na přidávání podpory nových GPU do tohoto základu a „řešitelských týmů“ zaměřených na úpravy velké části tohoto kódu. Také jej přivádějí na jednotlivé trhy (notebooky, Apple, atd.). Linuxový tým je jedním z těchto řešitelských týmů. S takovou strukturou kódu, čipů a řešení není možné porovnávat velikost „linuxového“ a „windowsového“ týmu.
9) Jsou nějaké plány na nový instalátor ovladačů Nvidia? Třeba takový, který by šlo spouštět přímo z běžícího X sezení a který by měl GTK/Qt rozhraní?
Ano, já vím, že tento dotaz se objevuje často. Myslím, že je toho více, co by mohlo vylepšit zkušenost uživatelů s instalací. Měli jsme o tom několik brainstormingových sezení, ale zatím nemáme konkrétní plán. Také bychom chtěli lépe spolupracovat s balíčkovacími systémy distribucí. Instalovat ovladače spolehlivě ve všech distribucích je problematické, takže k tomu chceme přistupovat opatrně. Zatím jsme nebyli schopni tomu nastavit příliš vysokou prioritu.
10) co dělá Nvidia ohledně marketingu/evangelizace linuxového ovladače u vývojářů a vydavatelů?
Hlavní závazek Nvidie je Visual Computing, nezávisle na konkrétním operačním systému nebo grafickém API. Celkově vývojáři znají svoji cílovou skupinu velmi dobře, takže není nutné, abychom nějak marketingově pracovali. Oni obecně vědí, co od nás chtějí, a naše role je dokumentovat naše API a poskytovat ukázkové kódy, whitepapery a takové věci na http://developer.nvidia.com.
Začíná Nvidia pozorovat větší zájem o ten ovladač mezi společnostmi či vydavateli?
Vždy tady byl a nadále bude významný zájem o Linux na pracovních stanicích v rozličných segmentech (např. ropa a plyn, automobilový průmysl, film a televize atd.). Pracovní stanice jsou oblast, kde má Linux největší obchodní dopad pro Nvidii.
Na velkých vícemonitorových instalacích je Linux velmi populární a nabízí silné a zřetelné výhody oproti jiným operačním systémům.
CUDA na Linuxu se těší velkému zájmu mnoha High Performance Computing (HPC) zákazníků.
Stejně tak Linux na zařízeních Tegra, zájem je i o Linux na IONu.
11) Máte nějaké plány na poskytnutí nových vlastností v ovladači xf86-video-nv nebo lepší spolupráci s vývojáři Nouveau na nějaké podpoře open source?
V rámci nv ovladače se vždy snažíme poskytnout něco minimálního, co samo o sobě funguje a vyžaduje co nejmenší údržbu. Z toho důvodu zůstane množství vlastností v nv ovladači velmi omezené.
Chlapi pracující na Nouveau až dosud odvádějí opravdu neuvěřitelnou práci. Nicméně naše politika zůstává stejná: Nebudeme bránit jejich úsilí, ale nemáme žádné plány jim pomoci.
12) AMD byla schopna otevřít kód nebo poskytnout dokumentaci k mnoha věcem oddělením částí, které nemohli legálně uvolnit. Podobné problémy byly uváděny jako překážky, které brání Nvidii v otevření zdrojového kódu (licencované části třetích stran atd.) nebo dokumentace. Mohla by Nvidia použít stejnou taktiku?
Podobná strategie může být technicky možná pro Nvidii, ale buď jak buď, nemyslím si, že se to stane. Je k tomu několik důvodů:
13) Myslíte si, že se hraní pod Linuxem nějak drasticky změní v budoucnu?
Z hlediska komerčního publikování her pro Linux je to těžká otázka. Zpráva Johna Carmacka z nedávné doby o nedostatku podnětů pro linuxový port Rage se dotkla některých hlavních problémů: Nedostatečná kvalita ovladačů, nedostatečně velký trh. Byl jsem potěšen posledním TTimovým blogovým zápiskem, kde naznačuje, že se hodlá o linuxový port pokusit bokem.
Vidím několik paralel mezi týmem linuxového ovladače v Nvidii a TTimovou situací: PC a konzole Id Softu vydělávají, ale Timo se o hraní na Linuxu stará a dělá co může pro Linux ve svém volnu. Podobně linuxová grafika v Nvidii: Pracovní stanice jsou to, kde má linuxový ovladač největší finanční dopad pro Nvidii. Ale jako týmu linuxových nadšenců nám také záleží na uživatelské linuxové grafice a snažíme se pokrýt více záležitostí kolem běžných uživatelů, kdykoli můžeme.
Každopádně, bez přesvědčivé základny linuxových hráčů je těžké si představit mnoho komerčních herních vývojářů, kteří by podporovali linuxový port svých her. Jak zmínil John ve svém komentáři, více hráčů platících za existující linuxové tituly jako Quake Live by statistiky více naklonilo budoucím linuxovým portům.
Také bych dodal, že je potřeba udělat mnohem více s linuxovým desktopem, aby byl atraktivnější pro vývoj a portování her: Lepší grafické debuggovací nástroje, přesvědčivé zvukové API a lepší nakládání se vstupy (slibně vypadá XI2).
Myslím, že další zajímavé možnosti pro linuxové hraní zahrnují:
14) Jsou nějaké záměry na portování budoucích technologických dem Nvidie pod Linux?
Rozhodně doufám, že ano, ale já na našich technologických demech nepracuji.
15) Povzbuzuje Nvidia své AIB/OEM/ODM partnery (add-in-board; original equipment manufacturer; original design manufacturer) k propagování podpory Linuxu na jejich produktech nebo k používání loga s Tuxem?
Od tohoto jsem opravdu odstřižen, takže nemohu říci.
16) Distribuují nějací AIB/OEM/ODM partneři linuxové ovladače na přiložených CD s ovladači?
Ano, několik velkých OEM partnerů dodává Nvidia linuxové ovladače jako součást svých pracovních stanic.
17) Kolik procent zákazníků myslíte používá Linux?
Neznám žádná konkrétní procenta. Hi-end pracovní stanice pro vizualizace budou tak z poloviny na Linuxu a Digital Content Creation (DCC) je z většiny na Linuxu. Grafiky Nvidia pod Linuxem pohánějí solidní část 3D pracovních stanic, také základna uživatelů CUDA má velký linuxový kontingent.
Nicméně počet stažení linuxového ovladače z nvidia.com je pouze 0,5 % toho, kolik se stahuje windowsových ovladačů. Samozřejmě, mnoho linuxových uživatelů získává naše ovladače přes distribuční balíčky a jinde, což znamená, že to nemůžeme dobře měřit.
Zjišťovat velikost linuxové uživatelské základny byl pro nás vždy problém.
18) Věříte, že celkový tržní podíl Linuxu poroste?
Ano, věřím. Dokud bude náš linuxový tým v Nvidii dělat svoji práci dobře, budeme mít v pracovních stanicích solidní pozici.
Je zde rostoucí zájem o Linux v netboocích a handheldech. Také se objevuje použití v IPTV u produktů jako Boxee.
Desktop zůstane pro Linux těžko dosažitelný, ale distribuce jako Ubuntu Linux více zpřístupnily běžným uživatelům.
19) Čeho myslíte, že dosáhne linuxový ovladač z hlediska vlastností, novinek a podpory v příštích 12 měsících?
Během příštího roku zde bude hodně podpory nového hardwaru a měli bychom též vyřešit bufferové problémy s prezentací/synchronizací na kompozitních X desktopech (1, 2). Očekávám také interoperabilitu VDPAU s OpenGL a CUDA/OpenCL.
Díky současnému vývoji v komunitě FreeBSD, která se zaměřuje na naše dlouhodobé problémy na této platformě, bychom měli být schopni konečně poskytnout x86_64 ovladač pro FreeBSD.
Určitě toho ale bude daleko více. Některé otázky v tomto rozhovoru mohou ovlivnit naše budoucí priority.
20) Jak se dívají linuxoví inženýři v Nvidii na architekturu ovladače Gallium3D?
Architektura je celkem dobrá. Z důvodů, které jsem zmínil dříve, není žádná příležitost pro ovladač Nvidie, jak toho využít. Ale kluci z Gallium3D dělají skvělou práci.
21) Jak pokračuje úsilí Nvidie v podpoře RandR 1.2/1.3 v ovladači?
Musím se skutečně omluvit, že podpora RandR 1.2+ u Nvidie tak vázne. Když se to poprvé objevilo, nevypadalo to moc naléhavě, protože jsme již měli naši vlastní podporu pro dynamické TwinView. Potom se ale objevila řada dalších projektů a dostaly přednost. Od té doby RandR trpěl tím, že se pohyboval akorát „pod čarou“. Opravdu věřím, že se k němu brzy vrátíme.
22) Hodlá Nvidia poskytnout podporu Kernel Mode-Setting?
Nic definitivního, ale dostáváme řady žádostí a je to něco, čm se doufám budeme v budoucnu zabývat.
23) Jaká byla motivace Nvidie pro vytvoření VDPAU?
Cílem VDPAU je jednoduše zpřístupnit schopnosti moderních GPU v dekódování a prezentaci videa linuxovým uživatelům. Naštěstí jsme mohli použít mnoho kódu z video ovladačů od ostatních týmů uvnitř Nvidie.
Návrh API se mi líbí a myslím, že naše implementace je docela dobrá.
Bylo bezva, že se VDPAU dostalo tak dobrého přijetí v linuxové komunitě.
24) Jsou nějaké plány na podporu zobrazení informací o VDPAU v rámci panelu nvidia-settings?
Ano, máme již nějakou dobu požadavek s nízkou prioritou na zahrnutí informací ve stylu vdpinfo do nvidia-settings.
25) Jsou nějaké plány na zahrnutí podpory SLI profilů do panelu nvidia-settings?
Aplikační profily jsou jednou z těch byla-by-fajn věcí, které jsou na radaru už dlouhou dobu, ale nikdy se nedostaly dostatečně vysoko na seznamu priorit.
36) Nějaké plány ohledně podpory ESA pod Linuxem?
V tuto chvíli žádné.
37) Jsou nějaké plány na přidání měření vytíženosti GPU do linuxového ovladače?
Nic definitivního, ale pravidelně se to objevuje, částečně v kontextu s CUDA, a je to něco, na co bychom se rádi podívali.
38) Nějaké plány na podporu PhysX na GPU?
V tuto chvíli nemáme žádné plány ohledně podpory GPU akcelerovaného PhysX pod Linuxem.
39) Kdy je v plánu vypuštění PerfKit/PerfHUD pro Linux?
Ano, to je další oblast, která se v poslední době nedostávalo dostatečné pozornosti. Náš konečný cíl je poskytnout ovladač perfkit společně s každým vydáním linuxového ovladače, ale nejprve musíme vylepšit několik interních procesních záležitostí.
40) Jak dlouho ještě Nvidia plánuje podporovat legacy linuxové ovladače.
Plánujeme podporovat legacy ovladače napořád, dokud bude objem práce v rozumných mezích: Backportujeme podporu pro nové linuxové kernely a nové X.Org servery (jedinou výjimkou je, že neplánujeme backportovat podporu nových X serverů do ovladačů řady 71.86.xx). Obecně do legacy GPU ovladačů nebackportujeme nové vlastnosti.
41) Program Nvidie "The way it's meant to be played" je velmi populární na Windows. Jsou nějaké plány pro jeho rozšíření i na Linux?
Momentálně žádné takové plány.
42) Pokud by měli vývojáři linuxového ovladače Nvidia nějaký seznam přání pro změny v Linuxu a doprovodných knihovnách a softwaru, co by bylo v seznamu navrchu?
Nejsem si jistý, ale počítám, že by zde šlo použít několik odpovědí na příští otázku.
43) Která část Linuxu/X.Org je nejvíce problémová?
Nejtěžší věcí na distribuci proprietárního ovladače pro Linux je sestavování binárky, která má běžet na co nejvíce linuxových distribucích. Problémy jsou následující:
Chybějící stabilní API v linuxovém kernelu. Pro nás to není velká překážka, vrstva jaderného rozhraní jaderného modulu NVIDIA je distribuována jako zdrojový kód a kompilována při instalaci pro daný kernel a jeho konfiguraci, která je na počítači používána. To vyžaduje občasnou údržbu v rámci aktualizací pro změny v jaderných rozhraních, obecně to ale není zas tak moc práce.
Přesto se to velké množství změn jaderného API zdá nešťastné: V některých případech jsou fungující rozhraní v kernelu rozbita nebo nahrazena rozbitými bez jakéhokoli zjevného dobrého důvodu. V dalších případech API, která pro nás byla dříve dostupná, se změní na nepoužitelná.
Současné velmi rychlé změny v ABI v X.Org DDX. Jako v bodě 1), ani toto není pro nás velká překážka: V současných větvích ovladače jsme schopni celkem snadno přidávat podporu pro více verzí X server ABI.
Nutnost být velmi opatrný ohledně závislostí knihoven a symbolů v každé binárce, kterou dodáváme. Klasické začátečnické chyby jsou zhruba takovéto:
undefined reference to `regexec@@GLIBC_2.3.4' undefined reference to `__ctype_b'
Linkování proti runtime knihovně C++ (libstdc++), ale potom má jiné distro jinou verzi libstdc++.
libstdc++.so.6: cannot open shared object file: No such file or directory
Těmto problémům se vyhýbáme a) explicitním linkováním proti velmi staré glibc a b) vyhýbáním se použití C++ runtime. Nicméně to vyžaduje pečlivou pozornost.
Body 1 a 2 jsou naší vlastní chybou za snahu produkovat pouze binární linuxový ovladač (beru to jako cenu, kterou platíme za to, že používáme tolik multiplatformního kódu v linuxovém ovladači).
Nicméně viděl jsem, že bod 3 dělal problémy spoustě jiných lidí, kteří jen chtěli poskytnout nějakou aplikaci pod Linuxem. Mnoho lidí to nakonec vzdá a prostě certifikují své komerční aplikace pro malou kontrolovanou skupinku linuxových distribucí, které mají stejné verze glibc a libstdc++, nebo přebuildují své aplikace na jiné cílové distribuce.
Myslím, že by uživatelskému prostoru Linuxu prospělo, kdyby poskytoval konzistentnější runtime prostředí pro aplikace. Abych byl fér, moje zkušenosti s problémem v bodě 3 jsou už trochu postarší, takže s DSO (Dynamic Shared Objects) rozhraními už je možná v současnosti méně nepříjemností. A měl bych dodat, že aktuální linuxové jaderné ABI pro uživatelský prostor je skutečně robustní – poznámka je převážně jen o DSO, proti kterým aplikace linkují. Také bych měl zmínit, že DSO How To Ulricha Dreppera je vynikající zdroj pro kohokoli, kdo se snaží o portabilitu.
44) Který balíček (X.Org, jádro atd.) má nejvíce prostoru pro zlepšení, aby lépe doplňoval video ovladače, např. od Nvidie, pro 3D akceleraci, desktopové efekty, přehrávání videa atd. a v jakém směru?
Linuxový ovladač Nvidie je velmi komplexní a zatěžuje téměř všechny části celého systému, s nimiž pracuje, v daleko větší míře než většina jiných ovladačů. Podobně jako hardware, který ovládá, je vysoce optimalizovaný a závisí na mnoha vlastnostech v klíčových částech systému (jako je linuxový kernel), aby pracoval bezvadně. Nedostatečné zkoušení některých těchto cest v linuxovém kernelu, stejně jako ignorování ovladačů mimo hlavní strom, mívá pravidelně za následek mírné regrese v linuxovém kernelu a jeho interakci s kernelovým modulem Nvidia. Také utrpěla stabilita kvůli tomu, že změny ve vývojovém modelu hlavní větve jádra přesunuly více odpovědnosti za ladění na distributory.
Nicméně, co se týče linuxového jádra, tak se jen zřídka stává, že bychom měli potíže kvůli základním architektonickým nedostatkům. Problémy jsou obvykle způsobeny běžnými chybami.
Ohledně budoucího růstu: Věřím, že největší příležitosti jsou v X Window System. Ne proto, že by X byly špatné (mnoho základních architekturálních rozhodnutí je opravdu dobrých: Např. oddělení politiky do okenních správců a kompozitních správců), ale budoucí evoluce linuxového kompozitního desktopu se nevyhnutelně odehraje v primárních desktopových částech: X serveru, X ovladačích, správcích oken a kompozitních správcích.
Naštěstí, z mého pohledu, je X Window System (implementovaný s použitím XFree86/X.Org Loadable Driver Frameworku) dostatečně flexibilní a rozšiřitelný, aby mohl být použit při řešení moderních výzev linuxového desktopu.
Poděkování za rozhovor patří Andy Ritgerovi z Nvidie a také serveru Phoronix, který jej vedl.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.