Komentáře: Historie grafických karet v noteboocích – 2. díl: od SVGA k přehrávání DVD

Od: jarop

jarop — Thu, 06 Feb 2014 15:10:47 +0000

Ad 7: Hardwarovy blitter sa už nepoužíva, miesto toho texturovacia jednotka kreslí tzv.textured quads. Už sa ani nepoužíva ten starý spôsob blittingu, kde sa presúvali obdlžnikové výrezy vrámci framebuffera. Dnes GPU vytvára kreslí každý frame od piky. Jednoducho výsledný obraz poskladá z offscreen bitmap(textur).

Od: swarm

swarm — Thu, 06 Feb 2014 14:57:42 +0000

[10] Ad Duke3D: Nemám tu hru u sebe, ale nastavovalo se to přes položku screenmode (tam, kde se dalo zapnout i stereoskopické zobrazení) v duke3d.cfg. V setupu to vyvolat nešlo. S jistotou si pamatuju podporu karet od S3 (kterých, to už nevim).

O zbytku se nepřu, v článku ostatně říkám to samé.

Od: jarop

jarop — Thu, 06 Feb 2014 14:32:31 +0000

Zdravim.
Píšete, že „Duke Nukem 3D uměl využít vyšších rozlišení a (2D) akcelerace některých grafik.“ Fakt by ma zaujímalo akú akceleráciu (blitting?) a u ktorých kariet. Nič som o tom nenašiel. Vo všeobecnosti sa 2D akceleracia v DOSe takmer nepoužívala, lebo neexistoval programový štandard. Než prišlo VBE/AF, nastala era Windows a DirectX.
Je len pár programov, ktoré dokázali využiť v DOSe 2D akceleraciu – napr. aplikácie ako QuickView. A občas mala niektorá hra vlastné ovladáče pre karty (Dawn Patrol, Flight simulator) ale ktovie, či použili blitting alebo kreslenie čiar.
Vačšina kariet mala jedine ovládač pre Windows GDI a OS/2, prípadne nejaké CAD systémy a na DOS výrobcovia už vtedy kašlali.

Od: pavt

pavt — Mon, 06 Jan 2014 07:47:09 +0000

Ladis->Asi máte pravdu, už jsem ve věku, kdy mám nárok na sklerózu:-) Na ošetřování WM_REDRAW a Invalidate jsem již pozapomněl… Nejsem si ale jistý tím vaším tvrzením, že GDC vám umožnilo kreslit přímo ve videopaměti. Bylo to přes WinAPI šíleně pomalé a kromě toho si pamatuji, že v dokumentaci Direct X se stále zdůrazňovalo, že nyní konečně programátor může přímo přistupovat do videopaměti. Samozřejmě, Direct X měl zásadní výhodu, že umožnil vytvářet bitmapy přímo ve videopaměti, člověk nad tím měl kontrolu, takže bitblt operace pak probíhaly s HW akcelerací podstatně rychleji. Ale jak říkám paměť je děravá a tyto detaily už jdou mimo mě.

S tím čtení z GDC jsem se to dočetl nyní, když jsem zkoumal ty bitplány (už si to přesně nepamatuji), no a zní to logicky – protože pokud byste zkoumal obsah zakryté části okna, tak nevím, co byste dostal, nikde nebyla uložena. Samozřejmě, GDC 0 pro printscreen byl jiný případ, ale pro jednotlivá okna mi to, jak píšu, dává smysl. Takže bych spíše řekl, že po příchodu kompozitního desktopu se z GDC dá číst… Ale hádat se nemíním, už se tomu léta nevěnuji:-)

Masta->No, neznám sice všechny implementace blitteru, ale jako speciální čip nikde moc nebyl (možná někde na SGI či SUN stanicích), spíše byl vždy součástí nějakého čipu, například na Amize to byl Fat Agnus. Jeho funkcionalita (tedy rychlé bitblt operace s maskováním atd.) je určitě implementována i dnes, ale jak píše Ladis, to kreslení už dnes nehraje roli – tehdejší GUI bylo velmi jednoduché, takže pro okno vykreslené několika čarami a vyplněné jednoduchým vzorkem dávalo smysl mít to vykreslování akcelerované. Dnes už to k ničemu moc není. Kromě toho, i na Amize nakonec došlo k fázi, kdy některé funkce Fat Agnusu (například rychlé přesuny bloků paměti, její mazání atd.) se s turbokartami vyplatilo dělat pomocí CPU, protože byl daleko výkonnější.

Od: Ladis

Ladis — Mon, 06 Jan 2014 01:25:33 +0000

[7] Pokud vim, bitblt je jediny, co zustalo (kopirovat FullHD 24bit pixelu je pekny zahul, a co kdyz chces jeste prevadet mezi ruznymi pixel formaty?). Naopak kresleni car, kruznic apod. grafikou je brzda, protoze CPU ztraci cas komunikaci s GPU.

Od: Masta

Masta — Mon, 06 Jan 2014 00:41:10 +0000

Mě by zajímalo jak moc se liší dnešní a tehdejší graf. čipy. Předpokládám že blitter jako speciální obvod se asi nepoužívá. A z5ná kompatibilita je zajištěna softwarově.

Od: Ladis

Ladis — Sun, 05 Jan 2014 13:57:07 +0000

[4] Ke čtení z device kontextu: Až do příchodu kompozitního desktopu ve Vistě šlo z device kontextu displeje (ne samozřejmě tiskárny apod.) číst. Printscreen celé plochy byl jednoduchým čtením z device kontextu 0.

Od: Ladis

Ladis — Sun, 05 Jan 2014 13:50:37 +0000

[4] To co popisujete, je kompozitní manažer oken (ten má Windows až od Visty). Ten tehdy určitě nebyl, protože by OS měl mnohem větší nároky na systémovou paměť (držet si obraz všech oken). Kreslilo se přímo, ve videopaměti to stejně zabíralo jen počet pixelů na obrazovce (překryté části nikde uložené nebyly) a v systémové paměti to nezabíralo nic (když se okno/část okna odkryla, okno dostalo zprávu o nutnosti překreslit danou oblast).

To s těmi chunky jsem myslel tak (a tohle souhlasí s vámi), že když aplikace kreslila do svého okna, tak neměla možnost vědět, jak jsou rozdělené chunky (pokud grafika neumí linear memory). Takže bez přemýšlení kreslila grafiku napříč celým oknem sem tam a ovladač grafiky neustále přepínal aktivní chunk, a do něj vykreslil část z právě kreslené grafiky.

Od: pavt

pavt — Sat, 04 Jan 2014 10:45:37 +0000

[3] Je to jinak (viz. níže), já teda dělal až v Direct X, pod DOSem jsem nic podobného nezkoušel. Ten důvod, proč Windows toto programátorům nedovolovala, byla snaha o vytvoření abstraktní vrstvy (device context), která udělá software nezávislým na hardware (pod WinNT se to jmenovalo HAL). Prostě šlo o to, aby se na rozdíl od DOSu eliminovala nutnost znát hardware počítače a program pro něj upravovat. Programátor prostě ovládal univerzální zařízení, no a bylo starostí ovladačů to převést na reálný hardware. Pokud to ale potřeboval, mohl si zjistit, zda tu či onu funkci zařízení podporuje a případně tomu program uzpůsobit.
Windows jely (jestli si dobře pamatuji)na bitplánové grafice (graphics device context, GDC) , která samozřejmě umožňovala přístup k obrazové paměti celého okna té které aplikace, kde jste si mohl kreslit dle požadavků a aktuální nálady. Ale nikam jinam a kromě toho jste mohli pouze zapisovat. No a při vytváření reálného obrazu ve videopaměti Windows vzaly obsah virtuální obrazové paměti všech oken, správně to poskládaly dle viditelnosti, no a následně nacpaly do framebufferu karty. Tohle pochopitelně bylo šíleně pomalé, protože se ještě musela převést bitplánová grafika na chunky lineární grafiku. V bitplánové grafice máte každou bitovou rovinu uloženou separátně, zatímco v chunky grafice máte jeden byte=jeden pixel (256 barev), případně 2, 4 či 16, podle počtu barev. V případě 24bitové grafiky máte jeden bod=3 za sebou navazující byty. Důvod, proč byla bitplánová grafika ve své době tak populární, bylo šetření pamětí. Na Amize jste si mohl vytvořit obrazovku se třemi biplány, tedy osmi barvami, a ušetřit tak paměť (což na PC nešlo). Na PC to Windows zpočátky dělaly stejně právě z toho stejného důvodu (aby ušetřily paměť pro device contexty všech oken), ale znamenalo to pomalost celého grafického systému. Dnes je to pochopitelně už překonané.
No a právě zde je ten můj sklerotický problém – já si totiž nejsem zcela jist, zda to Windows interně opravdu dělaly bitplánově. V té době jsem programovával na PC i Amize, takže se mě to možná plete, ale řekl bych, že ano. Pokoušel jsem se to teď nalézt, ale nepodařilo se, takže na férovky přiznávám svou sklerózu:-)

Od: Ladis

Ladis — Sat, 04 Jan 2014 02:32:30 +0000

[1] Pokud vím, staré grafiky neuměly svoji videopaměť adresovat najednou (16bit adresace?), to až pozdější (linear video memory). Vybíral jsi chunk, a do něj kreslil. Dokonce to byl požadavek na grafiku od nějaké (možná dokonce první) verze DirectDraw, že musí umět linear memory. Takže tady hádám, že byla ta pomalost – že to Windows před programy skrýval, namísto aby nabídl (zvláště hrám) vykreslovat přímo do chunků (jako dělaly hry v DOSu – musely ale znát různé grafické chipy, protože rozdělení do chunků se mohlo lišit).