xwayland - X server uvnitř Waylandu (diskuse)

[Josef Kufner]

Tak, teď ještě tu síťovou transparentnost a třeba to bude i použitelné.

[w]

a hardwarova narocnost samozrejme roste. Grr

[Josef Kufner]

Co jsem tak koukal na architekturu waylandu, tak by to mělo být stejné nebo lepší než nyní s Xorg. Pokud to teda někdo nezpacká.

[kavol]

můžeš to trošku rozvést?

- pominu-li, že by se kód jistě dal brutálně zoptimalizovat(*), pak si nedovedu příliš představit, jak v tomto případě může přidání další vrstvy, tedy více prováděného kódu, snížit nároky na hardware ...

(*) přičemž ovšem nemám důvod věřit, že to někdo od Waylandu s kódem X udělá, resp. že jej reimplementuje lépe

[kralyk z abclinuxu]

Wayland+X samozřejmě efektivnější není, ale Wayland samotný by by-design měl být. Viz Wayland architecture. Pokud, jak už psal Josef Kufner, to někdo nezdupe.

[kavol]

Wayland+X samozřejmě efektivnější není, ale Wayland samotný by by-design měl být.

aha, a o čem jiném než Wayland+X se tu bavíme, když zprávička je o X pod Waylandem, a thread začal o tom, že by to chtělo doimplementovat ještě jednu vlastnost X?

[pavlix]

+1

[kavol]

hm, tak jsem se podíval na obrázky, když už sis dal práci to linkovat, a pokud tu jejich geniální architektůru chápu správně, tak akorát hodlaj práci X serveru přehodit na klienta - bravo, to se nám to machruje, jak bude mít wokenní systém menší zátěž procesoru, když ta zátěž se teď bude připočítávat aplikacím, namísto tomu wokennímu systému, jako u konkurence

krom toho, ňák jsem asi totálně vypad z obrazu, jak pracuje hardware a co dneska dělá grafická karta, ale hlava mi nebere, jak může bejt lepší, aby si aplikace sama něco kreslila na CPU, a k zobrazení dodala hotovej obraz, namísto toho, aby akorát Xserveru řekla, co chce nakreslit, a on to při troše štěstí dokázal s pomocí svých driverů realizovat akcelerovaně na GPU místo na CPU ... ledaže bychom té aplikaci dali i drivery a přístup ke grafice, aby ji instruovala sama, co chce kreslit - což zase vede na případ výše, a ještě navrch nám přidává kopec práce s oddělením privilegií, aby kdejaký hejhula nemohl páchat prostopášnosti přímo na hardware ...

p.s. když si to tak čtu, tak teprv teď mě to praštilo do očí, jak se historie opakuje, to už tady máme s Qt4 - to na Xka taky pěkně sere a jen posílá hotový obrázky, no a již léta v praxi vidím, jak je to "pekelně rychlé", blé , oproti Qt3

[vlastikroot]

Moderni grafiky maji mnohem vetsi moznosti v akcelerovani 3D nez 2D. V mnoha pripadech (napr. KDE4 a XRender na nvidiich) je akcelerace 2D pomalejsi nez SIMD optimalizovane CPU vykreslovani - proto jsou poloreseni jako napr. raster engine v Qt4. GPU potrebuje okna jako hotovou pripravenou texturu, se kterou dale pracuje pomoci shaderu. Tim se dosahne nejvysiho vykonu (a samozrejme efektu). Kdyby aplikace pouzivaly ciste jen vektorovy X protokol, nebyly by tak hezke ovladaci prvky (vzpomenme na CDE napr.). Klicem k uspechu je tedy mit co nejjednodusi moznost kreslit do bufferu okna, nejlepe pomoci openGL prikazu a pak ten buffer pouzit jako texturu k celkove openGL kompozici. To dela wayland.

[kralyk z abclinuxu]

aha, a o čem jiném než Wayland+X se tu bavíme, když zprávička je o X pod Waylandem, a thread začal o tom, že by to chtělo doimplementovat ještě jednu vlastnost X?

Stačí pozorně sledovat vlákno...

krom toho, ňák jsem asi totálně vypad z obrazu, jak pracuje hardware a co dneska dělá grafická karta, ale hlava mi nebere, jak může bejt lepší, aby si aplikace sama něco kreslila na CPU, a k zobrazení dodala hotovej obraz, namísto toho, aby akorát Xserveru řekla, co chce nakreslit, a on to při troše štěstí dokázal s pomocí svých driverů realizovat akcelerovaně na GPU místo na CPU

Skutečně je X protocol, potažmo Xlib API natolik bohaté, aby mohlo nahradit např. Qt painting systém? A bude to při celé asynchronitě X i stejně tak rychlé? Silně pochybuju o obojím. To, o čem mluvíš, už bylo dávno vyřešeno, viz DRI: Direct Rendering Infrastructure (DRI) is an interface and a free software implementation used in the X Window System to securely allow user applications to access the video hardware without requiring data to be passed through the X server. Proč by měl vykreslovat X server? Akorát by stál v cestě mezi aplikací a grafickou kartou, přičemž by ale nenabízel nic navíc. Koneckonců X je taky jenom userspace proces.

Renderování je v článku popsáno v odstavci nazvaném (překvapivě) rendering.

[pavlix]

Stačí pozorně sledovat vlákno...

Zřejmě asi ne :).

[frEon]

roste, jelikoz aby sitova transparentnost k necemu byla, musi mit clovek sitovou kartu :-P

[bohyn]

virtualni by nestacila? :)

[ovoce]

Hlavně aby to nedopadlo jako audio džungle :)

Ale jinak si myslím, že by mohlo jít o krok správným směrem, tedy pokud se to prosadí místo X, a nevznikne situace, že půlka dister bude mít to, druhá půlka ono, a třetí půlka oboje.

[xkucf03]

Hlavně aby to nedopadlo jako audio džungle :)

Což by nebylo tak špatné – PulseAudio mi umožňuje pouštět zvuk přes síť už pěkných pár let

[pavlix]

A přitom několik let měli na stránkách (či dokonce v FAQ) napsáno, že to k tomu v žádném případě není určené.

[xkucf03]

A na stránkách jádra je, že nejde obnovit smazané soubory z ext4 – přitom to s celkem vysokou mírou úspěšnosti lze

Přijde mi to ale lepší přístup, než dávat nereálné sliby, po kterých jsou pak lidé zklamaní.

[pavlix]

Přijde mi to ale lepší přístup, než dávat nereálné sliby, po kterých jsou pak lidé zklamaní.

U software, jehož tehdy hlavní prezentovanou výhodou byla síťová transparentnost mi to přijde dost zvláštní :).

[xkucf03]

„na stránkách (či dokonce v FAQ) napsáno, že to k tomu v žádném případě není určené“ vs. „jehož tehdy hlavní prezentovanou výhodou byla síťová transparentnost“ – tomu nějak nerozumím.

[pavlix]

Ani já jsem tomu tehdy nerozuměl.

[marek_hb]

Wayland - xserverem to začne - a přes davida to bude pokračovat dál :)