Vlákno názorů k článku Grafické karty a grafické akcelerátory (31) od Petr Stehlik - Falcon030 má grafiku ve skutečnosti mnohem pružnější než...
-
Petr Stehlik (neregistrovaný)Falcon030 má grafiku ve skutečnosti mnohem pružnější než jakýkoliv předchozí model. Stará se o to obvod VIDEL (místo Shiftera použitého v ostatních 16/32bit Atari počítačích) a tento VIDEL má mnoho registrů pro v podstatě volné naprogramování jakéhokoliv rozlišení při jakékoliv obnovovací frekvenci v daných barevných hloubkách (1,2,4,8 bitů bitplany a 15/16 bitů packed pixel). Vlastně to trochu připomíná např. Modeline u XFree86/X.org. Maximální rozlišení je dané pouze rychlostí datové sběrnice, po které proudí grafická data ze systémové RAM přes VIDEL na obrazovku. Původní takt 16 MHz umožnil rozlišení např. 800x600 na VGA (nebo i 1600x600 na televizi! :-), ale po urychlení sběrnice různými akcelerátory až na 25 MHz je možné vytáhnout z VIDELu rozlišení blížící se 1024x768.
Je zajímavé, že čím větší velikost takto definované videoram, a čím větší obnovovací frekvence, tím užší hrdlo má CPU do RAM, protože většinu šířky pásma zabral VIDEL. Takže náročná grafika v podstatě zpomaluje běh programů. Proto vedlejším efektem spořičů obrazovky, které přeprogramují VIDEL tak, aby nevysílal horizontální či vertikální obnovovací pulzy a tak vlastně přiměl VESA VGA monitor, aby přešel do proud šetřícího spánku, zároveň urychlí i běh programů, protože VIDEL vůbec nezdržuje na sběrnici. -
Pavel TišnovskýZlatý podporovatelJeste doplnim, ze programovani registru lze (i kdyz v omezene mire) provadet i v prubehu zobrazovani a mit tak obrazovku rozdelenou na vic grafickych rezimu. To se trosku podoba Display Listum z osmibitovych Atarek nebo prepinani rezimu na Amize.
Prave diky rapidnimu zahlceni pametove sbernice se dnes vyrobci uchyluji k oddeleni RAM a video RAM (nejenom u PC), pro staticke sceny je to idealni, u dynamickych scen naopak vykon ztraci. -
Pavel TišnovskýZlatý podporovatelOno v dobe, kdy se rozhodovalo o oddeleni pameti neslo o 3D a dnesni graficke akceleratory. Totiz i takova "primitivni" operace, jako je scroll teto stranky o par pixelu nahoru vlastne znamena prenos nekolika MB dat.
-
Pavel TišnovskýZlatý podporovatelFirefox by to snad mel zvladat, ostatne to neni jeho starost, ale knihoven "pod nim". Ale chce se mi brecet, kdyz si na notebooku pustim konzolu ve framebufferu (treba abych mel nativni rozliseni) a razem se rychlostne ocitnu tak o deset let zpatky.
-
Pavel TišnovskýZlatý podporovatelJasne dlouhou dobu mi taky stacil klasicky rezim 80x25 (presneji 720x400 pixelu se znaky 9x16) - ten je velmi citelny a po zkouseni ruznych tweakovanych rezimu a VESA rezimu jsem se k nemu vzdycky vratil. Ted vsak mam notebook (firemni) a je trosku blby se divat na ruzne rozmazana pismenka, tak jsem se snazil pracovat v nativnim framebufferu (1024x768), ale ta rychlost je otresna - to uz i osmibitove Atarko scrollovalo rychleji :-)
Kdyby tam aspon byla dodelana takova ta skoro zapomenuta featurka z T602: pri male rychlosti graficke karty se prekreslovala pouze vrchni a spodni cast obrazu, tak bych si zvykl. Ale pri pitomem skrollu o jeden radek prenest cca 2 MB dat - to je dost velke plytvani vykonem, mymi nervy a baterkami :-) -
Pavel TišnovskýZlatý podporovatelAno, v X-kach taky kupodivu pouzivam mnohem mensi fonty. Mozna je to tim, ze v textovem rezimu jsou znaky udelany tak, ze maji v horizontalnim smeru vzdycky obsazene dva pixely (maji tedy sirsi tahy) a pri vetsim rozliseni (SVGATextMode 0x..) se to zacina slivat. V X-kach mam font s jednopixelovymi tahy a tak to zvladnu precist i v mensi velikosti. (kdyz rikam "zvladnu precist", myslim tim dlouhodobou praci, jednorazove precist jde i sestibodove pismo. A prave pri dlouhodobe praci mi VESA rezimy nesedi).
-
RayeR (neregistrovaný)>Ale pri pitomem skrollu o jeden radek prenest cca 2 MB dat - to je dost velke plytvani vykonem, mymi >nervy a baterkami :-)
A co to je za masinu? Vdyt i u neakcelerovanyho rezimu by mela bejt prenosova rychlost RAM-LFB par desitek MB/s u PCI grafiky a par set MB/s u AGP grafiky. Sou spravne naprogramovany MTRR registry? Nevim jesi to linux defaultne zapne uz pri bootu nebo az Xka. Napr. v DOSu to nikdo nepreprogramuje a tak bezi VESA grafika nekolikrat pomalejs nez by mela, na to sem si napsal jednoduchou utilitu. Windowsy to obvykle zapnou, tam neni problem. -
V mem pripade to byl tusim Duron 600 a Celeron 500. Ale myslenka je to dobra, az/kdyz to budu zkouset priste, zkontroluju jestli jsou MTRR spravne naprogramovane ... mam ovsem pocit, ze minimalne na Duronu byly.
A nemeni to nic na tom, ze nepouzit alespon zakladni akceleraci framebuffer dost poskozuje. -
RayeR (neregistrovaný)Samozrejme, to ale zas vyzaduje uzpusobeni pro jednotlivy cipy, pac akceleraci uz nikdo nestih standartizovat, velika skoda :(
Jen sem chtel rict, ze se da bez problemu naprogramovat plynulej scrolling i bez akcelerace, jen pristupem pres LFB. Dyk treba takovej Duke Nukem 3 taky bezel ve VESA a nijak necukal a to i na pomalejsich strojich....
Jen pro poradek dodavam, ze MTRR maj byt naprogramovany do rezimu write-combining (misto defaultniho uncached) pro danej rozsah adres framebufferu. Pak se pouziva nakej burst zapis/cteni LFB kery je mnohem rychlejsi. -
Pavel TišnovskýZlatý podporovatelJde jeste o to, jakym zpusobem je scrolling implementovany. Bud se muze opravdu provadet scrolling, tj. prenos dat VideoRAM-VideoRAM (coz invaliduje celou cache, takze je dobre ji vypnout, stejne tak to neumozni burst prenosy) nebo rendering textu a jeho jednosmerny prenos do VideoRAM. Sice jsem to nemeril, ale citim, ze druhy zpusob bude paradoxne rychlejsi.
-
Pavel TišnovskýZlatý podporovatelNo jestli se ta data prenasi klasicky (a z tohoto hlediska pekne mizerne) pomoci mov, rep movsd atd. (vsak to znate), tak se teoreticke prenosove rychlosti sbernice ani pameti v zadnem pripade nedosahne - prakticky vyzkouseno na jinem projektu, u ktereho jsem naopak data sosal z karty do RAM.
Pokud je to napsany spravne a vyuziva se napriklad prenos bus-master, tak si vlastne procesor odpocine a nezacne se "probouzet", jak to na notasu (zbytecne) dela prave pri scrollingu.
Abych pravdu rekl, tak nevim, jak je naprogramovany framebuffer pro Linux, ale podle praktickych zkusenosti to vidim prave na ty "rep movsd" :-) Podotykam, ze se porad bavim o konzolovem framebufferu, X-ka s timto nemaji zadny problem (teda krome alfa blendingu, ale to jsme na vyssim levelu :-) -
RayeR (neregistrovaný)Za sebe muzu jen rict, ze ten rozdil mezi MTRR uncached a write-combining dela u me (na iBX, AGP karte)
62 MB/s vs 315 MB/s pri zapisu dat z RAM do LFB. Nevim jakou instrukci se to provadi, pouzivam ceckovou movedata(), typuju MOVSD.
Podle me je i tech 62 MB/s dostatecnych na rozumne rychly scrolling. Ja v linuxu framebufer nepouzivam, tak ani nevim jesi skroluje jako po pixelech (hladce) nebo po celych radcich. No takze treba pro 1024/768/32 by bylo potreba ~50ms na precteni LFB, dalsich ~50ms na zapis LFB na novou pozici, takze by se to melo porad hybat nakych 10FPS... -
Pavel TišnovskýZlatý podporovatelA muzu se zeptat, jak to zatezuje system a procesor? Protoze presouvat data procesorem je sice nejjednodussi, ale precejen se pouzivalo tak pred petadvaceti lety (uz pro i8080 existoval radic DMA, bylo to tusim 8257). To mozna bude prave ten problem Linuxoveho framebufferu, protoze pri praci na notebooku procesor vecne spi (co by taky pri psani ve Vimu a par ssh pripojenich mel delat?) a ten scrolling ho asi nestaci dostatecne rychle probudit a vznikaji tak ty pomale odezvy.
-
RayeR (neregistrovaný)No asi dost... A btw hry jako duke pouzivaly na kopirovani FB DMA?
No je to mozny, asi to zalezi jak ma ACPI dlouhy ty timeslicy, na mojom desktopu to je v radu jednotek milisekund. Urcuje se pomer kolik slicu to bude spat a kolik to bude vzhuru. Ale nejsem zadnej expert na PM, jen sem si hral sn akou utilitou co to umoznuje nastavovat. -
Pavel TišnovskýZlatý podporovatelDost pochybuju, ze DMA DOSove hry pouzivaly, sice je to pomerne jednoduche, ale musi se spravne nainicializovat druha strana, tj. radic sbernice na graficke karte. Tady bych to spis sazel na klasicke "rep movsd" apod. s vyuzitim VBE 2.0 (mam dojem, ze predchozi standardy neumoznovaly mapovani celeho framebufferu do hornich oblasti pameti a musel se pouzivat strasne pitomy a pomaly rezim oken).
-
RayeR (neregistrovaný)No ja si taky myslim. Ano, mapovani LFB pridalo az VBE 2.0
Sice se to dalo naemulovat pres UniVBE, ale pokud to karta proste neumela, tak se pozuival bankswitch a narust rychlosti byl nulovej. VBE 3.0 nepridava nic zasadniho, za zminku stoji moznost naprogramovani refresh rate pres standartizovany CRTC, takze pak neni problem si nastavit nakou ergonomickou frekvenci. -
Pavel TišnovskýZlatý podporovatelTed si prestavam byt tim vyuzitim akcelerace ve Firefoxu jistej :-) Ne ze by to scrollovalo pomalu, ale pri prepinani mezi taby se mi (nekdy) na chvili zobrazi jakoby nahodna cast pameti (znas to, proste rozsypany vsebarevny obraz). Nedela to vzdycky, takze se ani nechystam se na to podivat vic do hloubky, ale mozna to o necem vypovida :-)
-
Mikuláš Patočka (neregistrovaný)Firefox akceleraci scrollování má, ale pro kreslení nového
textu používá double-buffering --- nejřív si stránku
překreslí do paměti a pak paměť naráz zkopíruje do videoram.
Je to proto, aby stránka neblikala.
(asi kvůli nějakému bugu na chvíli překreslil nesmyl)
Netscape tohle neměl a aby to neblikalo, řešil to tak, že
začal zobrazovat, až když bylo přesně dáno, na kterou pozici
co přijde --- t.j. např. tabulku zobrazil, až když ji měl
celou; pokud byl v textu obrázek neznámé velikosti, počkal
se zobrazováním textu, dokud tento obrázek nenatáhl.
V grafickém linksu double-buffer nepoužívám (kvůli
pomalosti), tam jsem problém s blikáním vyřešil tak, že
vykreslovací rutina vykreslí každý pixel právě jednou. -
Mikuláš Patočka (neregistrovaný)Určitě akceleraci používá --- mám tak pomalý počítač, že
překreslování bez akcelerace je na něm dost pomalé a firefox
a mozilla scrollují rychle.
Gtk nemá s akcelerací co dělat, gtk používá xlib, xlib
posílá požadavky xserveru a xserver dělá akceleraci. Takže
záleží na tom, jaký máte xserver, případně jak je nastavený. -
Pavel TišnovskýZlatý podporovatelOno se to smeti nezobrazilo pri scrollovani, ale pri prepnuti tabu. Tj. na tabove liste se vizualne provedlo prepnuti a textova cast se proste rozpadla a po chvili se vykreslila stranka (spravne).
Ono to scrollovani neni tak jednoduche, jak se na prvni pohled zda (ale to urcite vis). K dispozici jsou ruzne strategie, ktere se lisi rychlosti a kapacitou alokovane pameti. Pokud je dost pameti, tak je nejrychlejsi vyrendrovat celou stranku a potom ji jenom blitovat na obrazovku (nebo se posouvat ve Video RAM). Tolik pameti vsak vetsinou neni k dispozici, proto se musi vyrenderovane casti vhodne kesovat, aby to pri scrollingu porad nemuselo prekreslovat ty stejne casti.
Pekne je to videt na GhostScriptu/GhostView, a to diky tomu, ze je extremne pomaly :-) -
Pavel TišnovskýZlatý podporovatelTim si nejsem tak jistej, i kdyz znam mnohem rychlejsi jazyky nez interpretovany PostScript (ktery ma i dalsi problemy, napriklad ten, ze se musi v pameti uchovavat cela stranka).
Napriklad PostScriptove tiskarny nedelaji celou dobu nic jineho a to v mnohem vyssim rozliseni nez je pitome CRT. Zatimco GhostScript musi vyrenderovat cca 1024x768 pixelu, tj. necely milion (dobre at nezeru, tak dva miliony, kdyz to renderuje i spodni pulku), tak si tiskarny musi poradit napriklad s 600x8x600x10=cca 29 miliony pixelu a dneska je to vlastne jeste ctyrikrat vic (u 1200 DPI). A nerekl bych, ze tam maji nejak extra rychle procesory.
PDF je taky zalozene na PostScriptu a renderuje se neskonale rychleji, takze tady to spis bude problem pomaleho interpreteru nebo renderovace v GhostScriptu. -
Nerikam, ze interpret v ghostscriptu je nejrychlejsi mozny, ale IMHO ho dost zpomaluje dodrzovani norem - v ghostscriptu by melo fungovat KAZDE ps, tiskarny na nekterych vecech vytuhavaji (pravda, nejcasteji jim proste dojde pamet ...). Krome toho, nejsem si jisty jestli nekresli do vetsiho rozliseni nez ma CRT (a to i kdyz neantialiasuje).
PDF je sice zalozene na postscriptu, ale je v mnoha smerech zjednodusene (v jinych naopak rozsirene, pravda). Myslim, ze nektera z tech zjednoduseni byla za ucelem zrychleni ... -
Pavel TišnovskýZlatý podporovatelAno, je pravda, ze v nekterych pripadech je GhostScript (jako konvertor ps->ps) jedine reseni u zmrsenych dokumentu, ktere pri poslani na tiskarnu zlobi. Vetsinou za to muzou napriklad spatne uvedene prikazy clearpage apod. (a samozrejme vsechno produkovane jednou nejmenovanou kancelari :-). Nevim, proc by GS vykresloval do vetsiho rozliseni, to by prece melo mnohem vyssi naroky na pamet, ale nevylucuji, ze se tam neco takoveho deje.
Z praktickeho hlediska mi tam vadi neexistence funkce "zoom window", takhle pohled musim pri zkoumani nejake titernosti slozite zvetsovat, zmensovat a posouvat, coz pri pomalosti renderovani uzasne zpomaluje praci. Nebo by stacilo neco na zpusob "zvetsovaciho skla", ktery je implementovany v mnoha DVI prohlizecich (to stejne bych nekdy potreboval i u Firefoxu, kdyz neco doladuji na pixely :-).
