Portál AbcLinuxu, 8. srpna 2025 22:12
28.7.2008 13:45
David Watzke | skóre: 74
| blog: Blog...
| Praha
28.7.2008 17:06
xvasek | skóre: 21
| blog:
| Zlín
Teď k původní otázce - dobré bezesporu je, že podpora pro Novelácký prototyp XGL už nebude "strašit" v X.org. Blbé je, že už se pravděpodobně nenajde nikdo, kdo by začal dělat pořádně znovu XGL server, protože je to spousta práce a žádný viditelný výsledek - na monitoru uživatele by zkrátka vypadal stejně, jako X.org s AIGLX. Přitom výhody architektury XGL jsou lákavé - mohli jsme mít jeden mrňavý vykreslovací OpenGL server, v podstatě jenom obal nad ovladači, který by ale byl dostatečně robustní na to, aby zvládl moderní (XGL) aplikace včerně 3D podpory a podpora pro veškerá X rozšíření (včetně těch obskurních a obsolete) by se mohla přesunout do nějaké X compatibility layer, na které by samotný běh serveru nebyl závislý.
Možná se to trochu podobá uvažování nad tím, jestli by nebylo lepší nahradit v distribucích linuxové jádro hurdem, protože hurd je mikrokernel a tudíž je (architektonicky) lepší.
28.7.2008 14:08
freshmouse | skóre: 42
| blog: Bruno Banány
28.7.2008 14:42
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
.
28.7.2008 16:45
pools | skóre: 19
| blog: Svědek Damdogův
| Opava/Praha
28.7.2008 19:59
Pavel Půlpán | skóre: 22
| Trutnov
In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people. --Linus Torvalds
Konečně programovací jazyk, co umí všechno. 
29.7.2008 17:36
mkoubik | skóre: 5
| blog: lorem_ipsum
| Praha 8 - Bohnice
28.7.2008 16:22
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
pres vlastni knihovny (Cairo, Plasma)Nevím, co tam dělá Plasma. Spíš Qt 4, ne? Mám navíc tušení, že Qt 4 OpenGL jako vykreslovací metodu zvládá, ale nejsem si jist.
driver v kernelu ktery poskytuje v userspace API (OpenGL + par funkci na nastaveni rozliseni, uspani apod.) ?To, ze API OpenGL je obludne velke (ve srovnani s rozhranim jinych typu zarizeni) a jeho implementace (ovladac) zahrnuje i takove veci jako kompilator shader jazyka. Reseni, ktere se pouziva v Linuxu, je rozdelit implementaci do dvou casti - minimalni driver v jadre (DRI), ktery se stara o DMA, ring buffery, rizeni pristupu ... a userspace driver (knihovna Mesa) ktera poskytuje OpenGL API a konstruuje sekvence prikazu pro grafickou kartu, ktere pak pomoci jaderneho ovladace preda graficke karte. Zanedbam-li problematiku nastaveni grafickeho rezimu tak to je v podstate vsechno, co je treba ke kresleni grafiky. Nastavit graficky rezim umi FBdev ovladace v jadre (ktery vicemene neumi nic jineho), je treba mozne nastavit pres FBdev graficky rezim a pak pres DRI/Mesa delat akcelerovanou grafiku pres OpenGL, aniz bych vubec mel X server. Vyskytly se snahy sloucit FBdev a DRI ovladace a ziskat tak jeden kerneli ovladac starajici se o grafiku. V posledni dobe v tomto smeru je snaha rozsirit DRI ovladace o moznosti nastavovani rozliseni, tak aby dvojice DRI/Mesa byly plnohodnotne graficke drivery. Z historickych duvodu tu mame obludu X server a X protokol. Tradicni X server predpoklada, ze je jediny, kdo resi grafiku, implementuje jak ovladace pro nastaveni rozliseni, tak ovladace (2D) vykreslovani, to vse sitove transparentnim protokolem. Pokud ale X aplikace vykreslovala pres OpenGL (mesa/DRI), tak vlastne (po domluve) obchazi X server a primo komunikuje s Mesa/DRI. AIGLX neni nic jineho nez mechanismus, ktery zapouzdri OpenGL prikazy do X protokolu (GLX), preda je X serveru, ktery je vykresli pres Mesa/DRI, cimz umozni vzdalenym aplikacim vyuzivat akcelerovane OpenGL a lepe spolupracovat mezi OpenGL a X serverem. Tahle myslenka neni nic noveho, takhle fungovala OpenGL akcelerace v dobach Xfree 3.X (pred DRI), kde hardwarovou implementaci OpenGL delal rovnou X driver sam (a aplikace posilaly OpenGL pres GLX). Protoze tu mame obrovske mnozstvi X aplikaci, ktere bychom chteli nadale spoustet, je treba nad potencialnimi novymi drivery udelat X-vrstvu, ktera vzhledem k povaze X protokolu by se delalal lepe ve forme (hardwarove nezavisleho) serveru nez ve forme knihovny. To byla snaha Xgl/Xegl - udelat X server, ktery je hardwarove nezavisly, nastavuje rozliseni pres FBdev, vykresluje pres Mesa/DRI a nevyuziva vubec puvodni X server. Protoze ale FBdev drivery jsou obecne v horsim stavu nez X drivery co se tyce nastavovani rozliseni, dosazeny mezivysledek fungoval tak, ze v normalnim X serveru (ktery se pouzival pro nastaveni rozliseni) bezel pres fullscreen Xgl server, ktery vykresloval pres Mesu/DRI. Tahle snaha ale nejak usnula.
PS: Ale je mi jasné, že se X serveru nikdy nezbavíme
Ale pořád se například textury budou přenášet po síti.I bez OpenGL remotingu se po síti přenášejí pixmapy a podobné veci (jak v X11, tak v RDP, natožpak v RFB, které je na tom celé založené - proto je to taky jen taková nouzovka.
). Navíc myslím, že třeba v CAD aplikacích se na ty textury při editaci zase až tolik nehraje a požadavek je tam hlavně na výkon při zpracování geometrie, což by OpenGL remoting zvládnout měl.
protože to je všechno na úkor rychlosti lokálních desktop app, které jsou využívání v 99%A byly by pro tohle tvrzení nějaké důkazy? (Ve smyslu "hard science", podotýkám.)
PS: Přenáší se dokonce i písmo, které se načítá na klientu a posílá X serveru
Nepřímý důkaz jsou windowless podoknaV tom případě jsou Windows strašný pomalý šmejd, když Visual Basic musel přejít na windowless podokna už v roce 1998, a Internet Explorer snad ještě dřív.
Přenáší se dokonce i písmo, které se načítá na klientu a posílá X serveru.Tak o tom nic nevím. Vím, že třeba FreeType posílá už vykreslené texty přes XRender, ale o možnosti posílání písem jsem netušil. To umí X.org?
V tom případě jsouV novém Qt byl důvod rychlost, u Visual Basicu nevím a v IE je to myslím jasné (DOM, všichni známe třeba ComboBox bug:) )
...No popravdě nevim co se změnilo, ale asi to nebude jiné než když jsem se na to díval. Renderování vyhlazeného písma by mělo probíhat tak, že klient načte písmo (pomocí fontconfig zjistí cesty k písmu a nastavení pro freetype a pomocí knihovny freetype vyrenderuje písmo) a toto písmo pošle X serveru, který použije zmíněný XRender pro vykreslení. Nevýhoda je ta, že každá aplikace udržuje cache pro vyrederované glyphy a v případě vzdáleného přístupu přenášíte bitmapy písma. Pokud se pletu, opravte mě;) PS: Když jsem začal poprvé programovat pod Xlib, hrozně mi chyběli věci typu DIBSECTION a možnosti HDC (hlavně renderovat text třeba do zmíněné DIBSECTION)
V novém Qt byl důvod rychlost, u Visual Basicu nevímMyslím, že to byla zase rychlost.
a v IE je to myslím jasnéŽe by omezení Ẅindows 9x? Vím, že takové 3DS MAX na Windows 98 sice běželo, alo samo si zabralo 80 % prostředků.
všichni známe třeba ComboBox bug:)Neznáme, nemáme IE.
PS: Když jsem začal poprvé programovat pod Xlib, hrozně mi chyběli věci typu DIBSECTION a možnosti HDC (hlavně renderovat text třeba do zmíněné DIBSECTION)No mně rozdíl v programování Xlibu a Win32 přijde asi tak podobný, jako rozdíl mezi assemblerem a Cčkem.
Vůbec si nejsem jistý, jestli by se tyhle věci měly řešit úrovni Xlibu, a v první řadě by možná bylo možná vůbec nejlepší, kdyby Xlib už konečně vyhnil a někdo ho zašlapal do země.
30.7.2008 02:27
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Těžko hledat důkazy, architektura X serveru je taková jaká je, a nikdo z nás to nezmění, jenže to je právě ten problém, že se X server začne časem obcházet.Nepřipadá mi na ní nic tragického. A X11 forwarding využívám každou chvíli.
Nepřímý důkaz jsou windowless podoknaTo me neprijde jako rozumny argument, pouzivani windowed podoblasti v ramci realnych oken me prijde jako metoda, jak si usetrit trochu sve prace na ukor efektivity implementace (protoze malokdy ma smysl rozlisovat oblasti okna uz na X serveru). Neni divu, ze jednotlive toolkity od toho opousteji.
Osobně mi přijde windowless rychlejší v tom, že se komunikace mezi aplikací omezí jen na úroveň top-level okna <-> aplikace. Všechno ostatní si aplikace (toolkit) řeší sama. Tento přístup je rozhodně těžší na implementaci, to souhlasím (pokud jste to myslel takto).
Asi by byl problém do toho napasovat třeba interakci s Tk canvasem nebo SVG, takže nakonec by stejně v mnoha aplikacích asi existovala hromada duplicitních struktur (vnořené obdélníčky na serveru a k nim nepravidelné tvary v okně aplikace).
29.7.2008 16:33
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Ale pořád se například textury budou přenášet po síti.Já jsem jednou zkoušel přes síť hrát RTCW a jelo to dost dobře, jen to mělo nepříjemný lag.
Ale pořád se například textury budou přenášet po síti. Prostě já osobně moc nerozumím tomu humbuku ohledně vzdáleného přístupu, protože to je všechno na úkor rychlosti lokálních desktop app, které jsou využívání v 99%Tak nevim, ale prave tohle mi prijde velka vyhoda celeho X systemu. Právě tato client-server architektura. Situace - mám výpočetní farmu se servery v serverovně a můj malý desktop se svým X serverem. Servery ve farmě nemusí mít X vůbec nainstalováno a přesto můžou mít X klienty. Nastavím si DISPLAY a aplikace běžící v serverovně na nabušeném stroji se mi zobrazí ne mém tichém desktopu. A nemusím kvůli tomu jít do zoufalství typu RDP nebo VNC. Další příklad - tenké klienty. Mám v práci tenkého klienta, ale stejně bych si rád zahrál nějakou hru - s AIGLX a ovladači to není problém. Zkuste ale něco podobného we Windowsech přes RDP. Chápu že X protokol je již poněkud obstarožní záležitost, a proto s nadějí vzhlížím k NX které mnoho nedostatků klasického X protokolu řeší při zachování funkčnosti (bohužel, zatím ale žádné AIGLX
ale v tomto smyslu není nic nemožného dobastlit by to tam jít mělo a to je hlavní - nevím jestli by šlo do RDP dobastlit něco podobného aby fungovalo třeba Aero nebo tak něco)
?
neflejmovat, stejně by to nikam nedošlo, radši někdy u piva :)
slape to out of the box. X pres sit bezne pouzivam. To, ze je VNC fungujici reseni, bych netvrdil. Zkuste si pres to pustit treba nejaky jednoduchy prohlizec 3d modelu.
Drtivá většina problémů X.org plyne z kdysi nepříliš dobré (nebo nepříliš prozíravé) implementace, ne z toho, "jak to celé funguje".
Ja a dost mych znamych sitovou transparentnost X protokolu casto pouzivame, preci jen neni nic jednodussiho nez 'ssh -X pocitac'.Tedy právě ono ssh -X počítač je sice pěkné a funguje to ihned, ale právě tímhle dosti drsně degradujete rychlost vzdálených X - protože každé "upšouknutí" vzdáleného X klienta musí ssh namáhavě kódovat a na druhé straně zas dekódovat. Zkuste si takto pustit mplayer a uvidíte věci - ssh zabere víc CPU než mplayer s X serverem dohromady. To už mi přijde smysluplnější tomu těch pár minut věnovat a nastavit si DISPLAY + xauth aby to šlapalo přímo. Jestli si tady někdo myslí, že vzdálené X prostředí používá jen hrstka lidí možná - pak patřím já i celá naše firma právě k nim.
.
29.7.2008 09:48
Drom | skóre: 24
| Kdyne
Kez by komunita kolem X pochopila ze FBDev-DRI-Mesa-Cairo(Qt) je opravdu dostatecny pocet layeru mezi uzivatelskym kodem a hardwarem.Ono FBDev-DRI-Mesa jsou sice tri veci, ale maji rozdelene cinnosti, takze kdyby slo o jednu 'FBDRIMesa' vrstvu, ktera by delala vsechno, tak by to nic moc neprineslo. Jinak setrvavani v soucasnem stavu je primarne kvuli nedostatku lidi pro vyraznejsi zmeny nez proto, ze by se vsem vyvojarum okolo X soucasny stav libil. I kdyz odmyslime sitovou transparenost, tak nejaky zastresujici proces bude treba z mnoha jinych duvodu, napriklad tam, kde je treba vyrazna koordinace mezi grafickymi kienty, ci treba proto, ze mnoho grafickych karet neumoznuje dostatecne oddelit pristup od nezavislych grafickych klientu a napriklad omezit daneho klienta jen na nejake okno. A cely okenni system vcetne implementace vsech grafickych operaci v jadre skoro nikdo nechce a ani by takove reseni neprineslo mnoho vyhod oproti novemu lehkemu grafickemu serveru v userspace.
Tahle myslenka neni nic noveho, takhle fungovala OpenGL akcelerace v dobach Xfree 3.X (pred DRI), kde hardwarovou implementaci OpenGL delal rovnou X driver sam (a aplikace posilaly OpenGL pres GLX).Tak jasne ze v XFree to vsechno fungovalo pres DRI, ale je treba si uvedomit, ze v tomto pripade Mesa primo komunikuje s DRI a obchazi tak X server, coz neni moc dobre. Je to sice rychle, ale pokulhava interakce s ostatnimi X klienty a navic pokud pouzivate vzdaleny desktop tak na DRI muzete zapomenout. V tomto smyslu je AIGLX mnohem elegantnejsi pac umozni GLX prikazy (tj. existujici rozsireni X) akcelerovat prostrednictvim X serveru -> nezalezi na tom, jestli mas desktop lokalni k X serveru nebo ne, compiz ti pobezi stale stejne vesele... Prvni skutecnou vlastovkou byly X ovladace pro XFree od nvidie - tam clovek naopak musel DRI extension zakazat a definovat jen GLX - prave proto, ze tyto ovladace uz samy od sebe byly schopny zvladnout HW akceleraci OpenGL prostrednictvim X.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.