Jaderné noviny – 22. 9. 2011: Budoucnost podpory grafických zařízení v jádře

3. 10. 2011 | Luboš Doležel | Jaderné noviny | 3858×

Aktuální verze jádra: 3.1-rc6. Citáty týdne: Neil Brown, John Waltington, Thomas Gleixner. linux-next na githubu. Kde ten strom najdu? Cesta k jednotnému frameworku ovladačů zobrazovacích zařízení.

Obsah

• Aktuální verze jádra: 3.1-rc6
• Citáty týdne: Neil Brown, John Waltington, Thomas Gleixner
• linux-next na githubu
• Kde ten strom najdu?
• Cesta k jednotnému frameworku ovladačů zobrazovacích zařízení

Aktuální verze jádra: 3.1-rc6

Aktuální vývojová verze jádra je nadále 3.1-rc6; během uplynulého týdne nevyšly žádné nové verze – ani vývojové, ani stabilní.

Citáty týdne: Neil Brown, John Waltington, Thomas Gleixner

Promyšlená vize opravdu není něčím, čeho by si jaderná komunita vážila.

-- Neil Brown

U 1.5 i 1.75 bylo OLPC firmami ujišťováno, že v době, kdy se laptopy dostanou do stádia produkce, tak už bude veřejně k dispozici veškerá dokumentace k procesorům/přidruženým čipům/SoC.

V obou případech společnosti lhaly, aby rozjely návrhy, a to aniž by měly úmysl kritickou dokumentaci mimo NDA někdy uvolnit.

-- John Waltington

Lidé, kteří bez rozmyslu odstraňují možnost laděni, si vysloužili jednosměrnou jízdenku do Oortova oblaku. Už teď je tam naprostý chaos, takže si jich tam ani nikdo nevšimne.

-- Thomas Gleixner

linux-next na githubu

Strom linux-next nebyl od výpadku kernel.org k dispozici; Stephen Rothwell dříve řekl, že jej nemůže zveřejnit na alternativním místě. Tento problém byl evidentně překonán; zájemci mohou aktuální strom linux-next najít na githubu.

Kde ten strom najdu?

V době psaní tohoto textu výpadek kernel.org nadále trvá a není známo, kdy bude opět v provozu. Vývoj jádra ale nikdy neustává a jednou z výhod modelu gitu je to, že kopie repozitářů jsou všude. Řada vývojářů oznámila nová umístění svých stromů; některé z přemístěných repozitářů jsou:

ACPI	https://github.com/lenb/linux.git
ALSA SOC	git://opensource.wolfsonmicro.com/linux-2.6-asoc.git
amd64 EDAC	git://amd64.org/linux/bp.git
APM	git://twin.jikos.cz/jikos/apm
arm-soc	git://git.linaro.org/people/arnd/arm-soc.git
HID	git://twin.jikos.cz/jikos/hid
infiniband	https://github.com/rolandd/infiniband
input	https://github.com/dtor/input
kbuild	http://repo.or.cz/w/linux-kbuild.git
libata	git://github.com/jgarzik/libata-dev.git
mmc	git://dev.laptop.org/users/cjb/mmc mmc-next
pm	git://github.com/rjwysocki/linux-pm.git
regmap	git://opensource.wolfsonmicro.com/regmap.git
SCSI	git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6.git git://bedivere.hansenpartnership.com/git/scsi-misc-2.6.git
slab	git://github.com/penberg/linux.git
tip	git://tesla.tglx.de/git/linux-2.6-tip
trivial	git://twin.jikos.cz/jikos/trivial
wireless	git://git.infradead.org/users/linville/wireless.git git://git.infradead.org/users/linville/wireless-next.git git://git.infradead.org/users/linville/wireless-testing.git
xen	git://oss.oracle.com/git/kwilk/xen.git

Většina z těchto přemístění byla označena jako dočasná. Bude zajímavé sledovat, kolik z nich se vrátí, obzvláště, pokud se kernel.org uchýlí k přísnějším pravidlům přístupu.

Cesta k jednotnému frameworku ovladačů zobrazovacích zařízení

V jednom z článků se LWN podívalo na to, jak by ovladače zobrazovacích zařízení [display drivers] měly být spravovány X serverem; jednou z věcí, na které tam bylo upozorněno, je to, že přesun velké části logiky ovladačů do jádra snížilo objem změn na straně uživatelského prostoru. Prakticky v ten moment se v jaderné komunitě rozpoutala debata o tom, jak by ovladače zobrazovacích zařízení měly být v rámci jádra spravovány. Zde komplexnost současného hardwaru pravděpodobně rozjede konsolidaci i rozšiřování jaderných rozhraní.

Vše to začalo docela nevinně, když Tomi Valkeinen popsal výzvy kladené zobrazovacím systémem, který lze najít v procesorech OMAP. Architektury System-on-chip jako OMAP nemají tendenci se obtěžovat s hezkým rozdělením zařízení, jež můžeme najít na desktopově a serverově orientovaných architekturách. Takže, namísto toho, abychom měli „videokartu“, OMAP má na jednu stranu akcelerační engine, který může vykreslovat pixely do hlavní paměti, a na druhou stranu má „zobrazovací subsystém“, který tuto paměť propojuje s displejem. Subsystém se skládá z řady překryvných procesorů [overlay processors], z nichž každý může vykreslit okno z paměti; výstup všech překryvných procesorů je pak hardwarem složen dohromady a odeslán k displeji. Nebo, pro upřesnění, je výstup těchto procesorů předán řadiči panelu, který může být kusem komplexního hardwaru sám o sobě.

Takže grafika na OMAPu závisí na sadě propojených komponent. Naplnění videopaměti lze udělat přes rozhraní framebufferu, skrze rozhraní DRM (přímého vykreslování), nebo, v případě videa zachyceného z kamery, skrze překryvné rozhraní Video4Linux2. Pro tato rozhraní musí být spravována videopaměť, následně je předána zobrazovacím procesorům, která zase musí komunikovat s řadičem panelu. Toto všechno funguje, ale jak Tomi poznamenal, vypadá to, že mezi těmito všemi rozhraními dochází k značné duplikaci kódu a v jádře neexistuje žádný obecný způsob, jak věci na všech těchto úrovních spravovat. Nebylo by hezčí, zeptal se, vytvořit nízkoúrovňový framework pro zobrazovací zařízení, který by se o tyto úkoly postaral?

Není prvním, kdo tuto otázku položil; vývojáři grafických věcí na tomto problému pracují už několik let a větší část řešení je jasná. Kód DRM je místem, kde valná část této práce byla v posledních pár letech odvedena; je to jediný zobrazovací subsystém, který se dostává blízko k tomu, aby dokázal popsat a pohánět současný hardware. Jak se problémy spojené se správou grafické paměti stávají komplexnějšími, je čím dál více nezbytné používat frameworky pro správu jako GEM, což znamená používat DRM. Následkem dědictví po X serveru také obsahuje zkušenosti v podobě fíglů potřebných pro různý hardware ze skutečného světa kolem nás sesbírané za několik dekád. Proto většina vývojářů věří, že časem se DRM stane tím jediným rozhraním pro nastavování a správu paměti, zatímco staré rozhraní framebufferu by se mělo stát rozhraním pro kompatibilitu nad DRM, dokud zcela nevymizí.

Navzdory tomu má Florian Tobias Schandinat, který nedávno převzal správu nad kódem pro framebuffer, odlišný názor. Pro Floriana je vrstva framebufferu stále živá a v dobré kondici, má více uživatelů než DRM a v dohledné době nezmizí. Jeho největší námitkou vůči DRM se zdá být to, že 1) je podstatně komplikovanější, což komplikuje ovladače a 2) zveřejňování akceleračních schopností hardwaru usnadňuje aplikacím způsobení pádu systému. Fakt, že API framebufferu neposkytuje žádné akcelerační mechanismy, je podle něj výhoda.

Nicméně hlas Floriana se zdá být hlasem minority; většina vývojářů to vidí tak, že bez schopností, které vrstva DRM nabízí, bude čím dál náročnější spravovat soudobý hardware. Přítomnost chyb v ovladačích DRM, které mohou vést k pádu systému – především, pokud je použita akcelerace – nikdo nepopírá, ale bylo poukázáno na to, že DRM užívání akcelerace nevyžaduje. Hardware se také napravuje v tom, že je pro operační systém snazší převzít nad GPU dle potřeby kontrolu. Tak či tak, pády a chyby jsou vnímány jako něco, co se musí opravit, nikoliv jako důvod pro vyhýbání se DRM.

To ponechává otázku, jak ošetřit funkci překryvů Video4Linux2. Překryvy byly značeny více méně jako zastaralé a už několik let nejsou zrovna oblíbené, ačkoliv nadále zůstávají oficiální součástí rozhraní; byly navrženy pro dřívější, jednodušší dobu. Jakmile se CPU dostaly do stavu, kdy dokázaly zpracovat proud videa z kamery, motivace používat překryvy odezněla – na chvíli. O něco blíže současnosti došlo k tomu, že se rozlišení proudů videa značně zvýšilo a náročnost na výkon se stala mnohem důležitějším aspektem. I když CPU na mobilních zařízeních dokáže zpracovat proud videa v reálném čase, baterie vydrží déle, pokud bude CPU spát a proud půjde přímo do videopaměti. To znamená, že schopnost překrývat proudy videa na displej, aniž by docházelo ke kopírování, se opět stalo zajímavým.

Vzhledem k tomu, že staré rozhraní pro překryvy je vnímáno jako neadekvátní, je jednoznačně nutné přijít s novým. Jessie Bernas předložil návrh na nové API pro překryvy už v dubnu; návrh na sdílení bufferů DMA zaslaný o něco později taktéž zohledňuje tento požadavek. Říká se, že toto téma bylo diskutováno na X Developers Conference a nový návrh se objeví brzy.

Náznakem toho, kam by věci mohly v dlouhém horizontu mířit, je tato zpráva od Laurenta Pincharta, autora subsystému řadiče médií V4L2. Komplexnost zařízení pro zachycování obrazu se dostala do stádia, kdy je již nelze dobře vnímat jako jako samostatná zařízení; proto je tu řadič médií, který umožňuje uživatelskému prostoru získávat informace a měnit propojení v řetězu zařízení. Problém se zobrazováním je v podstatě stejný, jak říká; navrhl, že by řadič médií mohl být užitečný i pro řízení řetězce zobrazovacích zařízení. Tento nápad hned všechny nenadchl, ale může být náznakem toho, kam věci budou muset nakonec v budoucnu směřovat.

V posledních několika letech jsme byli v jádře svědky konsolidace velké řady kódu orientovaného na zobrazovací zařízení; tento kód čím dál více využívá obecnou infrastrukturu jako správce paměti GEM. Není těžké si představit, že tato konsolidace bude pokračovat až do bodu, kdy se subsystém DRM stane jediným podporovaným způsobem pro řízení displejů, zatímco ostatní rozhraní budou něco jako vrstva kompatibility. Komplexnost kódu DRM je nakonec hnána komplexností hardwaru, který je tímto poháněn, a nezdá se, že by se hardware v blízké době začal zjednodušovat.

       

Komentáře

[Petr Ježek]

Je vidět, že bez systémového myšlení se může vývoj linuxu zarazit na zacyklení se u permanentních oprav a adaptací na nový grafický HW. DRM je vzhledem ke svým vlastnostem ideální způsob, jak z toho ven. Staré bugy schopné přes DRM shazovat systém už měly být opravené, nejsou-li, musí se to stát prioritou. Jinak vývoj zařízení s grafickými subsystémy začne možnostem linuxu rychle utíkat.