Zpravodaj o Víně – 357

13. 8. 2009 | Luboš Doležel | Různé | 3166×

Vydávání obnoveno. Funkční DIB Engine. Budoucnost Maxova DIB Enginu. Stefan Dösinger: Rozhovor o DirectX 10.

Obsah

• Funkční DIB Engine
• Budoucnost Maxova DIB Enginu
• Rozhovor o DirectX 10

Vydávání Zpravodaje o Víně bylo obnoveno. Autor původní anglické verze je souběžně studentem a zaměstnancem na plný úvazek, což mu nedává moc času na další aktivity. Teď by snad měl mít času víc, takže by Zpravodaj měl vycházet častěji.

Od posledního vydání vyšla celá řada nových verzí Wine – toto číslo se týká verzí 1.1.15 až 1.1.22. Jde v nich hlavně o práci na Wine64, přípravy na podporu DirectX 10, spousty oprav, vylepšení OLE/GDI+ a RPC přes HTTP.

Funkční DIB Engine

Massimo Del Fedele dostal engine DIB do stádia, kdy s ním všechny testy ze sady testů procházejí. To znamená, že mnoho aplikací, které závisí na DIB Enginu (jmenujme MSN Messenger nebo Autocad), by mělo být rychlejší/mít méně chyb a měly by s ním být testovány.

Je důležité podotknout, že se DIB Engine v současné podobě pravděpodobně nedostane do hlavního stromu WineHQ. Sestavení Wine s Massimovou prací by měly být brzy k dispozici. V příštím vydání Zpravodaje se můžete těšit na hlubší analýzu situace.

Nuže, po mnoha opravách a přídavcích je všemocný DIB Engine skoro 100% funkční. U jedné z testovaných aplikací (MSN Messenger) se chová dokonce lépe než originál :-)

Ti z vás, kteří to chtějí otestovat, mohou jít na stránku bugu #421.

V dalším e-mailu píše o testovací sadě Wine:

Začal jsem opravovat selhání, která se vyskytují v testovací sadě. Většina z těch, co se týkají bitmap, je opravena, zbývající jsou hlavně kvůli nenaprogramovaným funkcím. Problémem je teď to, že to rovněž opravilo většinu todo_wine v bitmapové sadě.

O několik dnů později přichází s dalším e-mailem:

Zbývající chyby se týkají 1) Nějakých barev u monochromatických bitmap… tady hádám, že nikdo neví, jak to udělat správně. Opravil jsem nějaká todo_wine (většinu), ale mám dvě selhání, která Wine dělá správně. Ale stejně se to málo používá a děje se to jen u podivných palet. Řekl bych, že ani v Microsoftu neví, co v téhle situaci dělají.

2) volání AlphaBlend(), které by mělo selhat a neselhává. Tady vážně nechápu, proč by to mělo selhat. Stejně na tom nesejde.

3) GETDIBits na zdrojovém DIBu s BPP menším než 8 selže při získávání původní palety a namísto toho vytvoří paletu novou. Zatím jsem nenašel žádný snadný způsob, jak získat paletu z vnitřku GetDIBits bez udržování spojového seznamu HBITMAP k interním bitmapám. Stejně to teď nestojí za námahu. Pokud si kvůli tomu někdo všimne divných barev, pokusím se to opravit…

Ještě jsou tam nějaké chybějící/chybné málokdy používané funkce, které testovací sada neodchytí; zatím jsem neměl čas je opravit a stejně na ně zatím nikdo nenarazil. Austine, mohl bys prosím znovu vyzkoušet testovací sadu?

Jiný e-mail. Zde jde o to, že DIB Engine prochází všemi testy.

K bugu 421 jsem (jako obvykle) připojil poslední aktualizaci mého enginu. Měl by projít všemi testy z testovací sady… také všemi bitmapovými todo_wine, takže očekávejte nějaká mylná hlášení o chybě. Austine, mohl bys to prosím znovu spustit na tvých testovacích strojích?

Budoucnost Maxova DIB Enginu

O tom, zda by se Maxův DIB Engine měl dostat do oficiálního stromu Wine HQ, se hodně debatuje. Shrnutí: Alexandre stále není spokojen se základy návrhu a přijde mu, že je lepší nápad, aby v CodeWeavers případně zaúkolovali Huwa Davise, aby dokončil svůj engine.

Nyní nějaké podrobnosti. Roderick Colenbrander má velmi dobrý způsob, jak se dívat na tuto práci na DIB Enginu, i když neskončí v hlavním stromu.

Bohužel skutečně není možné dostat tento kód do Wine (Alexandre by byl rád, kdyby Huw dokončil návrh a veškerou práci, ale na to mu nebyl přidělen žádný čas), ALE myslím si, že čas strávený na tomto DIB Enginu není promrhaný, i když se to do Wine nedostane. Tento DIB Engine, ačkoliv není udělaný správně, nám ukazuje, jaké aplikace z toho profitují a jak moc (do té doby jsme jen hádali). Pokud je Photoshop pod Wine s DIB Enginem znatelně rychlejší (mohlo by být užitečné to otestovat, na Photoshop existují benchmarky), Codeweavers se může pustit do práce na této věci.

Roderick pokračuje v jiném e-mailu:

Podle Alexandrových slov je Huwův design správnou cestou, po které by se mělo jít (Jeremy říkal, že na tom dělal 4-5 měsíců), ale i Huwovi by trvalo stejně dlouho to dokončit. Moc nevěděli, zda by pokračování v práci stálo za ty aplikace, co museli rozchodit, a během diskuze na Wineconf si ani nebyli jistí, kterým aplikacím by to pomohlo a hlavně o kolik (čas totiž také pomáhá řešit mnoho problémů, protože procesory se neustále zrychlují). S tvými patchi (i když nejsou čisté a nebudou fungovat na 100 %) vidíme, jak hodně může (i neoptimalizovaný) DIB engine pomoci. V zásadě by to mělo hodně uživatelů otestovat na různých programech. Potřebujeme výsledky benchmarků, např. z Photoshopu a jiných.

Pokud se bude zdát, že DIB Engine dělá zázraky pro mnoho aplikací (např. Photoshop, Office, …) tak možná nějaká firma zasponzoruje Codeweavers, aby na tom zapracovalo.

Jeden z nápadů, původně od Joerga Mayera, je pro správce balíčků, aby přibalovali DIB Engine:

Zdravím (hlavně správce balíčků), abychom tento problém vyřešili z pohledu koncového uživatele, vidím dva přístupy:

1. Alexandre je ochoten vpustit tento kód do repozitáře Wine, aby mohl být udržován spolu s existujícím kódem Wine (pokud to chápu správně, tak úpravy existujícího kódu jsou celkem malé) a nechat na uživateli, aby si vybral, jaký kód chce.
2. Použijeme stejné řešení jako vývojáři linuxového jádra: Nechat původní kód čistý, ale přidávat libovolné (velmi žádané/nutné) funkce jako součást distribučního jádra.

Protože si myslím, že Alexandre dal najevo, co preferuje (a z dlouhodobého hlediska mu rozumím), chtěl bych se zeptat správců balíčků: Bylo by pro vás přijatelné, abyste přidali do kódu, který distribuujete, potřebný patch? Osobně tím mám na mysli Marcuse a balíčky Wine v openSUSE.

Austing English s jiným návrhem:

Co takhle větev wine-experimental se souvisejícími upozorněními? Kdyby to parta lidí začala testovat, mohli bychom získat dobré informace o tom, jak hodně to pomáhá, což nám nyní schází.

Ačkoliv se tyto nápady zdají být slibné, Marcus Meissner má pochyby:

Dnešní distribuce přijímají jen věci, které mají šanci dostat se do upstreamu. Když to napořád necháme v paralelním repozitáři, nikam to nepovede.

Scott Ritchie, správce balíčků Ubuntu:

Distribuce ve skutečnosti nijak Wine „nepodporují“. My tak maximálně uděláme občas nějaký ten nový balíček.

Jako správce balíčků jsem ochoten patch zahrnout, pokud bude Massimo ochoten udržovat patch funkční s poslední verzí a uživatelským přepínačem pro povolení. Obvykle mám averzi k udržování patchů oproti Alexandrově hlavnímu stromu (jiných než backportů), ale tenhle konkrétní je napsán právě tak, aby nedělal nic, pokud se ručně nepovolí.

Henri Verbeet s jiným důvodem, proč být s nápadem ohledně distribucí opatrný:

Ano, ale jde tu o to, že chyby zadané proti takovému balíčku jsou potenciálně neplatné. (Lidé by před zadáváním chyb měli použít git, ale ne každý to dělá.)

Scott Ritchie:

Už nyní od uživatelů očekáváme, aby při hlášení chyb sdělili, jestli udělali nějaké ruční zásahy do registru. Tohle se zdá být obdobné.

Ben Klien:

Ale obvykle to nedělají. Jako správce balíčku pro Debian nebudu připojovat DIB Engine, pokud se nedostane do vydávaných zdrojáků Wine. Mám stejná pravidla pro všechny ostatní patche (včetně mých jednoduchých vlastních patchů typu „určitě ničemu neublíží, ale jen věci vylepší“), abych pomohl v udržování čistoty v bugzille *a v AppDB*. Opravdu chcete, aby uživatelé dávali do AppDB věci, které závisejí na tom, kdo binárky zabalil?

V tento moment se na Slashdot dostal poněkud flamewarový příspěvek poukazující na to, že Wine je kvůli DIB Enginu „frustrované“ a „bude se forkovat“. Kdokoliv, kdo sleduje komunitu, viděl, že tato prohlášení jsou poněkud pochybná. Tak jako tak to haló, které kvůli tomu vzniklo, přinutilo Alexandra otevřeně mluvit v DIB vlákně o přijetí do stromu.

Psaní DIB enginu není cvičením typu „zaplňujeme prázdná místa“. Velkou částí práce je vytvoření dobrého návrhu, ověření na prototypu a následné přesvědčení lidí (hlavně Huwa a mě), že váš návrh je dobrý, že víte, co děláte, že jste očekával nejčastější námitky a máte na ně dobré odpovědi, že jste ochoten udělat požadované změny, že máte dobré testovací sady apod. Ukázat, že víceméně fungují v několika programech nebo že to projde těmi (velice málo) existujícími testy gdi32, je samozřejmě nezbytné, ale rozhodně ne dostačující. Pokud toto chcete vyřešit, musíte mít také dobrou historii, co se dostávání vlastních malých patchů do Wine týče.

Jakmile je tohle všechno hotové a ve stromu je zařazen řádný design, pak zde můžeme mít řadu úkolů typu „zaplňujeme prázdná místa“, které dokončí méně obvyklá grafická volání, která by v první verzi pravděpodobně byla prázdná. Ale tak daleko ani zdaleka nesjme.

V ten moment byla položena očekávatelná otázka:

Myslíš si Alexandre, že jsme se do tohoto bodu dostali? Tedy že je Massimův design pravděpodobně dobrým návrhem, ale že jen ještě nepřesvědčil tebe/Huwa a ještě „neočekává běžné námitky“ apod.?

Alexandrova odpověď:

No, prototyp zrovna nevykazuje známky dobrého návrhu. Možná že Massimo v hlavě nějaký dobrý má, ale doposud jej nevysvětlil.

Massimova odpověď:

No, stále si myslím, že „dobrost“ návrhu je věcí vkusu. Můj design je *designem*, který byl vytvořen z důvodu osobní potřeby a rozvinut *mým* osobním vkusem, což je jediný způsob, jaký jsem měl, bez řádné roadmapy.

Mimochodem, myslel jsem, že jsem dostatečně vysvětlil důvody vybraného designu, ale možná se pletu… takže tu opět uvedu kýžené cíle:

1. Aby to bylo použitelné. To znamená, aby to nefungovalo „jen pro pár programů“, ale něco, co obecně funguje alespoň jako současný ovladač. Podle mě je tento cíl tak na 90 % splněn. Během pár měsíců to bude 100 %, pokud mi mé zaměstnání ponechá dostatek času.
2. Aby to bylo volitelné. Podle mě nemá smysl udělat ovladač, který rozbije třeba jen jedinou věc, bez možnosti vrátit se k původnímu gdi32/winex11. Cíl na 100 % splněn.
3. Připravit funkční engine, který umožní hloubkové testování výkonnostního rozdílu. Víme, že *některé* aplikace z toho profitují (opět zmiňme AutoCAD, kde je u TrueType fontů zrychlení 50-100násobné), ale viděl jsem, že poslední myšlenky se točily kolem omezeného zrychlení… No, myslím si, že mnoho důležitých aplikací by z toho mohlo mít prospěch. Cíl na 80 % dosažen, neboť mixovaný blitting je o něco pomalejší než u původního ovladače. Není jednoduchý způsob, jak to napravit, aniž by se sahalo na winex11.drv.
4. „Připravit cestu“ pro definitivní přechod na to, co si myslím, že by měl být „správný konečný návrh“, takže DIBy ošetřované v gdi32 dvojitě bufferované v DDB uvnitř winex11.drv; míchaný blitting prováděný uvnitř winex11. Myslím si, že toto je jediný proveditelný způsob, pokud chceme mít rychlý blitting *a* vykreslování DIB. Můj ovladač provádí potřebné oddělení těchto 2 procesů. Jakmile to bude hotové, jejich přesun do gdi32/winex11.drv by měl být celkem snadný a mohl by být udělán po krocích.
5. Pro zábavu. Ups, tohle mělo být číslo 1

Co se bodu 4 týče, který je tuším pro tebe nejdůležitější, dalším krokem by bylo vytvoření winex11-2.drv, ve kterém by zpracovávání DIB bylo vyřazeno, ale s přidaným DDB bufferováním DIBů a míchanými blit operacemi. Tento ovladač by mohl být napojen (a testován spolu s) winediv.drv, vždy přes volitelný přepínač v proměnném prostředí/registru.

Jakmile by to bylo hotové a dostatečně stabilní, mělo by to být trvale povolené a zbývající část winedib.drv by mohla být zařazena do gdi32; to by se také mohlo udělat postupně. Samozřejmě by tento design způsobil nějakou duplikaci kódu v gdi32 a winex11.drv, alespoň pokud nechceme nic měnit ve funkčních tabulkách ovladače… což by bylo nejlepší řešení, pokud zde nejsme omezeni chováním Microsoftu (neověřoval jsem to a nemám to teď v plánu).

Jednoduchý GetLine() * PutLine(), který dělá převod mezi 32bit RGBA <--> DDB uvnitř winex11.driv a volatelný z gdi32 by nás samozřejmě zbavil nutnosti duplikace kódu pro míchaný blitting a zachoval by potřebnou rychlost. Tato změna by byla triviální.

Řekl bych, že můj design má přednosti a na druhé straně zase nevýhody, ale je z výše uvedených důvodů lepší než dříve přijatý „přístup dvojitých ukazatelů“. Největší „nevýhodou“, možná jedinou, je mít ve Wine po nějakou dobu dva ovladače… ale na druhou stranu to umožní hloubkové testování, aniž by se cokoliv rozbilo.

Doufám, že jsem to dostatečně vysvětlil. Technické detaily jsou v (možná až přílišných…) komentářích v kódu.

Alexandrova odpověď (s přidaným číslováním):

1. Jeden z hlavních problémů, které vidím, je to, že tvůj design je založen na předpokladu, že je tu jen jeden jediný grafický ovladač, a to X11. Toto jednoznačně není naše situace, DIBy mohou být používány s libovolným ovladačem (a vícero ovladači najednou). Toto je také důvod, proč ovladač DIB nemůže rozhodovat o tom, kdy něco předávat/nepředávat ovladači X11, rozhodování by mělo probíhat obráceným směrem.
2. Jsem také velmi skeptický ohledně zrcadlení DIBů pomocí DDB. Ale i když to uděláš, což by mělo být čistě vnitřní rozhodnutí X11drv, DIB Engine by o tom neměl mít vůbec žádné ponětí. To znamená, že nemůžeš vystavovat žádné rutiny pro převod DIB->DDB, DDB plně závisí na grafickém ovladači.

A nakonec zase Max:

Asi jsem se nevyjádřil přesně. [Ohledně 1.] Můj engine načítá winex11 přesně jako gdi32. To znamená, že to nemusí být winex11, může to být jakýkoliv ovladač, který by gdi32 načetlo. Načítání probíhá takto:

GDI32 <-- načíst libovolný ovladač a získat ukazatele na funkce pro DC a bitmapy (PŮVODNÍ).

GDI32 <-- načíst winedib.drv <-- načíst libovolný ovladač (apod.) (MŮJ ZPŮSOB).

Mechanismus načítání ovladačů v gdi32 duplikoval ten ve winediv.drv. winedib.drv jen zachytává volání DIB a přesměrovává je na *libovolný* jiný ovladač. Jak už jsem říkal, tohle je podle mých plánů přechodná fáze a nakonec by veškeré zpracovávání DIBů mělo jít do gdi32.

No, to byl jen nápad. Myslím si, že udržování zrcadlené kopie DDB by jen o trochu zpomalilo vykreslovací operace, ale o hodně urychlilo blitting. Ale není to nutné.

Měl jsem na mysli vyexportování „zjednodušené-rozšířené“ verze GetDIBits a SetDIBits, které by umožnilo částečné přesuny obrázků. Ani zde nejde o potřebnou věc, jen bychom se vyhnuli duplicitnímu kódu v gdi32 a winex11. To by gdi32 umožnilo číst a zapisovat části DDB přes volání winex11.

Stejně jako nyní potřebujete znalost odlišných formátů DIB ve winex11 i v gdi32; existence této funkce by umožnila přesunout věci související s míchaným blittingem téměř úplně do gdi32. Ale je to jen návrh.

V mém enginu je hromada PutLineXXX a GetLineXXX, které dělají konverzi z libovolného formátu do 32bit RGBA a naopak; funkce, o kterých jsem hovořil, jsou jen jejich rozšířením pro zajišťování konverze z/do 32bit RGBA a měly by samozřejmě být uvnitř winex11.

[Ohledně 2.] Souhlasím s tebou, že DDB cachování DIBů by mělo být věcí winex11 a mělo být plně transparentní vůči gdi32.

Rozhovor o DirectX 10

Poslal jsem několik otázek přímo k jednomu z několika expertů Wine na DirectX Stefanu Dösingerovi, který byl tak hodný, že odpověděl a osvětlil nám nějaké věci. (Vizte článek DirectX ve Wine.)

Potřebujeme pro DirectX 10 nějaké nové věci?

Například kompilátor HLSL, ačkoliv tento jazyk se velmi podobá GLSL. Microsoft přesunul svůj shader kompilátor mimo jádro d3d10, takže nepotřebujeme kompilátor pro d3d10. Nicméně nám běží GSoC projekt, který se má kompilátoru HLSL podívat na zoubek.

Existují nějaké věci z infrastruktury WineD3D, které mohou být znovu využity?

Využili jsme existující kód wined3d. Bylo třeba udělat nějaké změny pro podporu parsování bajtkódu SM 4.0, mergování bufferů. Henri na tom odvedl hodně práce, on vám k tomu může říct podrobnosti.

Našli jste nějaké opravdu dobré aplikace, které potřebují dx10?

Ne, ale dx11 vyjde za několik měsíců a dříve či později se dx10 aplikace objeví. Neměli bychom se moc opožďovat.

Když už přemýšlíme o budoucnosti wined3d, co z dx9 chybí? Jde jen o nějaké okrajové případy/opravy, abychom mohli prohlásit, že máme skutečně 100% funkční podporu dx9, nebo jsou ve funkčnosti/API nějaké velké mezery?

Jde především o okrajové případy a řešení omezení ovladačů. To může být docela zákeřné – například instrukce texIdd. Na kartách ATI je pro ni rozšíření GLSL. Ale na kartách nVidia podobná funkce existuje jen v GL_NV_fragment_program. Takže abychom toto korektně ošetřili, musíme nastartovat náš ARB shader backend na shader model 3.0 za použití rozšíření specifických pro nVidii. To je spousta práce na jednu drobnou instrukci. Mezi ostatní věci patří ujišťování, že fungujeme správně na více ovladačích než jen nVidia. Například sleduji přepis mesa ovladače radeon na bázi memory manageru, abych to otestoval, odeslal hlášení o chybách apod. Cílem je to, abychom jednoho dne mohli říci „dx9 programy fungují“ a ne „dx9 programy fungují, pokud použijete grafickou kartu X s ovladačem Y na operačním systému Z“.

       

Komentáře

[Jardík]

Jde v nich hlavně o práci na Wine64

A kdy už to bude?

[vain]

Asi je malá poptávka, tak je to netrápí Musíš vytvořit alespoň umělou poptávku =)

[Jardík]

Asi nahodím SPAM robota, aby to zařídil

[Václav HFechs Švirga]

Ale ne na tomhle serveru .

[Radovan Suchánek]

Tento komentár je len názor čitaťela:

Samotné wine pracuje spolahlivo,kde sa javí problém je vyvolávanie emulovaných inštrukcií ktoré majú za následok pomalú prácu s programom,mala by to riešiť alternatíva DIB enginu. Je v tom však háčik a tím celý postup skvalitnovania wine pribrzdený,ak sa začne začlenovať DIB do wine mohlo by to mať dobrý vplyv,avšak tu nevidím dovod použiť tento postup. Myslím že by bolo lepšie zapracovať a zlepšovať jadro wine a rýchlosť enginu a dať tomuto prednosť pred DIB enginom. Autor s tím mal bezpochýb vela práce ale ešťe pred začatím by som premýšlal aj nad tím,či by nebolo vhodné zapracovať a pomoc wine jadru na rýchlosti. Už vo svete linux distier sa rozšírila choroba ktorej následkom je vytvorenie a ponúkanie vlastného distra ktoré stavia na osvedčených základov iných hlavných vetiev linu,nebolo by lepšie keby všetci tí,ktorý vytvárajú distrá pomáhali hlavným vetviam? výber software je bod mrazu,vela sa nanúti ale nebolo by vhodnejšie pri inštalácii linu pridať možnosť výberu balíčkov? Cesta DIB enginu sa snaží ísť svojou cestou,akoby v pozadí konkurovala samému wine. Ak už by sa tak stalo samotný výber enginov by bolo vhodnejšie ponúknúť pre spustením emulácie win programu. Obávam sa však že integrácia bude mať za následok spomalenia vývoja wine,tá hlavná sila by sa mala viacej orientovať na optimalizácii wine.