Keith Packard az Intel video driver jelenéről, jövőjéről

Címkék

Keith Packard blogjában összefoglalta mindazt, amit érdemes tudni a nyílt forrású linuxos Intel video driver jelenéről és közeljövőjéről. A fejlesztők a héten befejezték a driver 2009Q1-es kiadását. A negyedév leginkább az új dolgok stabilizálása, a komoly bugok javítása és a minél szélesebb kombinációk tesztelése jegyében zajlott.

Az elmúlt kb. egy évben a fejlesztők azzal voltak elfoglalva, hogy újraépítsék a drivert. A munka eredményeként számos új szolgáltatás jelent meg. Többször felmerülnek olyan kérdések, hogy mi az a GEM, a KMS, az EXA vagy éppen az UXA. Keith összefoglalta írásában a válaszokat ezekre a kérdésekre.

A fejlesztő elmondta, hogy a végső cél elérése - KMS/GEM/DRI2 - felé vezető úton kötelességüknek érezték, hogy ne távolítsanak el opciókat mindaddig, amíg a célként kitűzött dolgok nem működnek a lehető legtöbb ember számára. Így ahelyett, hogy rákényszerítették volna az embereket arra, hogy váltsanak a teljesen stabil és gyors új kódra, megpróbálták biztosítani, hogy a driver minden egyes kiadása működjön a régi opciókkal is.

Mindazonáltal, a meghozott változások egy része regressziókat hozott a régebbi opciók használata esetén és ez nem az a dolog, amitől az emberek boldogabbak lennének -- a régi kód lassan fut, az új kód pedig még nem egészen kész az éles felhasználásra. Persze - mint írja - az is opció lett volna, hogy nem adnak ki kódot, hanem üldögélnek a "tökéletes" driveren dolgozva, amely megjelenik majd nem sokkal a világ vége után.

Ehelyett inkább úgy döntöttek - bevallva, hogy sokat nem rágódtak rajta -, hogy folyamatosan adják ki az anyagot, olyan állapotban, hogy az a lehetőségekhez képest valamennyire működjön és a közösség segítségét igénybe vegyék a ennek jelentősnek mondható átalakulásnak során.

Az összefoglalót Keith azzal zárja, hogy látszik már a fény az alagút végén. A driver újratervezése befejeződött és már a helyén van az az architektúra, amelyet a fejlesztők szerettek volna (global graphics memory management, kernel mode setting, per-window 3D buffers). Ezzel a projekthez hozzáadott új kód mennyisége drámaian lecsökkent, közelít a nullához. A felhasználók várhatóan az idő előrehaladtával ezt úgy fogják érzékelni, hogy a driver megbízhatóbb, gyorsabb és jobb lesz.

A részletek itt olvashatók.

Hozzászólások

Már várom azt a bizonyos fényt és remélem azt is, hogy nem kell ehhez féléveket várni. A maximális felbontást is korrigálhatnák, ugyanis az x4500MHD tud 2048-nál magasabbat is (az engem nem érdekel, hogy a 965 nem tud).

Remélem a Karmic-ba sikerül összeheggeszteni a DRI2/GEM/KMS triót. Jobban örülnék, ha ezek dolgoznának, mint a bootidőn (2-3-4 hetente rebootolok, akkor is kernelfrissítés miatt) :(

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Ez a Keith Packard mindig is egy szimpatikus figura volt. Nem trollkodik, nem akarja megváltoztatni a felhasználók szokásait, amíg nincs kész az új, addig a régit is támogatják stb.
Meg hát úgy eleve egyáltalán azóta van valamilyen szinten is használható driver az Intel grafikus vezérlőihez, amióta ő lett ráállítva a témára.

Viszont ha jól értettem, akkor a GEM kifejezetten kihasználja, hogy a grafikus vezérlő a CPU-val közös memóriaterületen garázdálkodik és dinamikusan lehet lapokat ide-oda allokálni a kettő között. Magyarán lehet, hogy ez az egész cucc csak az integrált grafikus vezérlőknél fog bármit is számítani, saját framebuffert használó kártyáknál marad a (lassú) CPU által vezérelt másolgatás?
---
Linux is bad juju.

Igen, csak hogy kerül át az alkalmazás pixmapje a video memóriába? Az egyik esetben simán laptábla babrálással, másik esetben egy lassú copy-val uncachable memóriaterületre. Vagy van valami GART DMA mechanizmus támogatás is a GEM-ben? Mert akkor elvileg a grafkártya maga veszi ki a zoxigént pixmapet a rendszermemóriából, ami akár gyors is lehet.
---
Linux is bad juju.

Csak en hianyoltam a "Intel driver" kifejezesbol a "grafikus" szot. Vagy az "Intel driver"-bol nem lehet a wireless-re vagy sok mas dologra asszocialnom? Na, jo, jo tenyleg errol van legtobbet szo mostanaban es a linkrol is egybol kiderult mi van, de akkor is...

subscribe

--
Keep it simple, stupid.