Názory k článku
Nadějné emulátory terminálu
-
robotron (neregistrovaný)
Tenhle clanek na me hluboce zapusobil a to v mnoha smerech: od vazneho zamysleni az po ruzne odstiny humoru. Patrim k lidem, co terminaly hodne trapi a predevsim me zajima zatez CPU a vubec, kolik toho muzu do terminalu pustit, aniz by zdrzoval || varil pocitac. Mam totiz ve zvyku poustet spoustu ruznejch numerickejch a RT ridicich uloh, kde se hrnou spousty vetsinou cisel ale i jinejch podobnejch hovadin v mnoha terminalech. Zda se to (nekterejm lidem) jako desna pitomost, mit na pocitaci bezici Matrix, ale vetsinou oko-mozek celkem zvlada vyzobavat podstatny veci, jako "jak moc signal sumi", "kolik desetinnejch mist je stabilnich", "jak casto se objevi v pravidelnem vzoru poryv" apod. Bezne na 100Hz vzorkovacky/1 radek o 120 znacich treba. Tolik k uvodni motivaci.
Zatim pouzivam xterm a rxvt. Zatez je nekdy nechutna. Podeziram je (do zdrojaku jsem ale nekoukal), ze se snazi vsechno, co prijde, vykreslit. Opravte me, pokud se pletu a je i v techto dinosaurech nejaka VNC/fps logika. (Pozn.: pouzivam X11 s vypnutym AA u fontu, pro vsechny aplikace, nejen terminaly.)
Co me velmi udivuje, je: pro uživatele, co potřebují vypsat rychle spoustu znaků. Je akcelerován na GPU; kouknul jsem na uvodni stranku a tam to veru zduraznuji. Chapete nekdo, k cemu muze bejt takova akcelerace dobra? Ja ne.
Dle meho -- zcela laickeho a cetbou zdrojaku terminalu nezatizeneho -- nazoru je otazka svizneho terminalu dvoji: zvladat pozirat vstup a pocitat z toho, jak vypada aktualni obraz (tj. umisteni znaku a ruzna rolovani); dale pak, aktualni obraz vykreslit. Pozirani vstupu je podmnozinou ulohy textoveho editoru, vyhoda je, ze pracuje s 1B/1znak. Nevyhoda, ze v extremnich pripadech meho typu to naky prase muze zahlcovat i >10KB/s (porad ale na dnesni dobu celkem snesitelny toky). Myslim, ze v tehle uloze se ten hlavni vypocetni vykon nepali.
Druha uloha je: zname matici znaku v danem okamziku a chceme ji nakreslit. Tahle uloha z principu nemusi/nemuze fungovat na snimkove frekvenci vyssi, nez je snimkova frekvence monitoru. Pri rozmerech 150x100 @75fps jsme na 1MB/s (prakticka rychlost nepretaktovany ISA sbernice, pro srovnani). Postarsi X11 terminal vzdalene pres 10Mb/s Ethernet uz se nechyta.
Jak to vykreslit? V klasicky logice ne-AA fontu podle me nemuze bejt lepsi cesty, nez klasicka 2D akcelerace se spritama nahranejma v karte. U AA fontu a subpixel renderingu zdanlive zacina uplne jina hra -- ale je opravdu o tolik jina? Pro obecnej proporcni text, umistenej na libovolne x,y souradnici a treba jeste s kerningem, skutecne problem. Ale terminal z principu ma znaky v pevnem sachovnicovem rastru, bez kerningu a i kdyby doslo na RGB subpixel rendering, tak zbyvaji pouze 3 mozne posuvy okna terminalu vuci RGB masce -- procez jsem presvedcen, ze predpocitat AA znaku, od kazdeho 3 varianty podle posuvu vuci RGB a je hotovo, zbytek se muze sazet primo blitterem.
Je tato uvaha zcestna? Opomnel jsem neco?
-
Palo (neregistrovaný)
Zbytocne to analyzujes. Vygeneruj si dostatocne velky subor (napr 'ls -lR / > /tmp/QQ& sleep 10; kill $!') a daj si 'time cat /tmp/QQ' a uvidis. Napriklad
Gnome Terminal:
real 0m1.067s
user 0m0.000s
sys 0m0.124svs CoolRetroTerm
real 0m0.759s
user 0m0.000s
sys 0m0.116svs Gnome Terminal + TMUX:
real 0m5.318s
user 0m0.000s
sys 0m0.124svs CoolRetroTerm + TMUX:
real 0m5.340s
user 0m0.004s
sys 0m0.148sVymalovane, najviac to aj tak brzdi TMUX.
-
K> (neregistrovaný)
ne ze bych chapal GPU pro terminal. Ale zkusil jsi to? Je Allacrity v tvem pripade rychlejsi?
Me mate ze na strankach Allacrity je tohle:
" In the terminals I've benchmarked against, alacritty is either faster, WAY faster, or at least neutral."
To znamena, ze existuje alespon jeden terminal, ktery je stejne rychly jako allacrity. Cimz tak nejak ta vyjimecnost GPU akcelerace mizi? -
Ondra (neregistrovaný)
No. GPU je staveno tak, ze se mu dobre delaji velke ulohy. Co to znamena pro ten terminal a jak s tim nejspis pracuji (takze hadam). Pri vypisu par radku na obrozavku, se musi pro GPU slozit cela uloha a vzhledem k mnozstvi dat, ktera se kresli, je to slozeni te ulohy drazsi nez jeji vykonani. Takze v tomhle pripade, ten terminal muze (a hadam, ze i je) pomalejsi nez softwarovy terminal. Ale kdyz se toho kresli vic, stovky az tisice znaku, tak to kresleni je mnohem rychlejsi. Nic vic za tim nehledejte.
-
Karel (neregistrovaný)
Alacritty při změně obsahu nic nevykresluje, jen si nastaví příznak, že se něco změnilo. V přerušení pak reaguje na vsync, koukne, zda je nastaven příznak změny a pokud ano, tak vykreslí novou obrazovku. Takže pokud vám monitor běží na 60 snímcích za sekundu, tak se překreslí obsah obrazovky nejvýše 60x. Další úspora je v tom, že nepřekresluje všechno. A dost ušetří i tím, že si jednotlivé znaky (glyph) udržuje v paměti grafické karty a jen je vkládá do display listu. To už je dost významná úspora oproti "klasickému" přístupu, kdy se znaky vykreslují vždy znova jeden po druhém do framebufferu. Navíc tam můžete mít "zdarma" průhlednost, antialiasing apod. A vlastně to celé funguje pořád stejně bez ohledu na rozlišení. Že má při 4K rozlišení bitmapa znaku 4x více pixelů než na FullHD nemá vliv na rychlost vašeho terminálu. Tedy pokud má vaše grafická karta dostatek výkonu. A na tohle má dostatek snad každá.
Každopádně Alacritty má ještě jeden trik v rukávu, kromě OpenGL. Má trochu jinak dělaný Parser. Viz http://blog.jwilm.io/announcing-alacritty/
-
robotron (neregistrovaný)
Diky za odpoved k veci.
Alacritty při změně obsahu nic nevykresluje, jen si nastaví příznak, že se něco změnilo. V přerušení pak reaguje na vsync, koukne, zda je nastaven příznak změny a pokud ano, tak vykreslí novou obrazovku. Takže pokud vám monitor běží na 60 snímcích za sekundu, tak se překreslí obsah obrazovky nejvýše 60x. Další úspora je v tom, že nepřekresluje všechno. A dost ušetří i tím, že si jednotlivé znaky (glyph) udržuje v paměti grafické karty a jen je vkládá do display listu.
Ano, takhle by to melo byt presne udelano.
To už je dost významná úspora oproti "klasickému" přístupu, kdy se znaky vykreslují vždy znova jeden po druhém do framebufferu.
Tohle je klasickej pristup tak mozna na ZX-Spectru a u smazbicek pod DOSem. Naopak "jednotlivé znaky (glyph) udržuje v paměti grafické karty a jen je vkládá do display listu" je presne klasickej Xlib pristup -- sam jsem to pouzival a bylo to skvele rychly i v truecoloru, s 1-bit pruhlednosti a na ruznejch sunkoznich a obskurnich X serverech, typu rany verze Cygwin/X pod NT 4.0.
Co mi stale unika, kde se tam muze uplatnit ta GPU -- vidim samy jednoduchy blitterovy operace pro 2D akceleraci.
-
robotron (neregistrovaný)
Precetl jsem si popis Alacritty od autora. Vsechno (az na to OpenGL) tam 1:1 sedi k moji predstave rozumnyho terminalu. Opevuje tam tabulkovy parsery, moc nechapu, ty se prece v unixu pouzivaj odpradavna. I fonty vykresluje bokem do spritu. OpenGL je tam jen a pouze v roli 2D blitteru, placa tam obdelnicky pismenek.
Skutecne, moc nechapu duvod. Urcite to bude energeticky narocnejsi, nez klasicka 2D akcelerace. Jedinej duvod me napada, snad multiplatformnost. (Ovsem za cenu vetsi spotreby grafarny.)
Mimochodem, autor zminuje dobry existujici terminaly: st (to se dalo cekat) a urxvt (to me jako dlouholeteho uzivatele rxvt tesi). Vytyka jim pouze malou prenositelnost mimo X11.
-
s (neregistrovaný)
Mne zadny existujici terminal nevyhovoval. Nakonec jsem presel na toto:
https://github.com/volca02/mypixels
je v pythonu na par radek, dal se snadno ohnout k me spokojenosti.
