Názory k článku Grafické karty a grafické akcelerátory (25)
-
Frn (neregistrovaný)" ... jakým způsobem je možné implementovat vlastní jednoduchou grafickou kartu pomocí běžně dostupných integrovaných obvodů ..."
Geniálně přehledné (a relativně jednoduché) řešení bylo v PMD85, kde základní čítač "bodů" honil posuvný registr a po vydělení 6-ti se pak přivedl na kaskádu čítačů, které adresovaly jednotlivé byty ve videoRAM. To schema bylo přímo školácká ukázka principu, na jakém to pracuje.
P.S. Docela mi to připomnělo televizi na kolejích - na začátku školního roku jsme si sháněli na inzerát staré ČB (za odvoz) aby bylo na pokoji na co koukat a na konci roku jsme je zase vyhodili. Spoulužák si jednou pořídil "barevnou" ruskou za kilo. Na ní byly zajímavé dvě věci - jednak kysna (děsně těžká z poctivých dubových fošen), ale hlavně střeva.
Např. dekodér barvy byl udělán přesně podle učebnice - tj. na plošňáku byly pěkně srovnané LC články které posouvaly fázi a diodové přepínače které otáčely polaritu podle potřeby. Autoři holt potřebovali jednoduché schema, které se dá ubastlit ze základních součástek (i když vyladění parametrů musel být pěkný horor) - jinak se na tyhle věci už dávno používají jednoúčelové integráče, do kterých se pustí chrominační složka a na druhé straně z něj leze rovnou RGB .. Ale soudruzi v Sojuzu je asi v době kdy tu televizi vyvíjeli ještě nestihli okopírovat :)
Takže se ze zvědavosti ptám už předem, z jakých součástek bude udělaný ten návrh grafické karty ? -
Pavel TišnovskýZlatý podporovatelJo, PMD-cko to melo vyreseny takhle jednoduse. Trosku slozitejsi to bylo napriklad na Spectru (tam se nepouzivaly diskretni soucastky), kde bylo potreba adresovat i barvu.
Graficka karta: takto nizko (na HW) v tom clanku nepujdu, pouze se zminim o fungovan i synchronizacnich signalu, pristupu do obrazove pameti atd. Vlastni implementace muze byt v Xilinx XC9500, ale snad by to nacpat i do neceho mensiho. Vystup RGB pres DA prevodniky na VGA monitor. Pomoci par odporu se do da primo prenaset do SCARTu (sice to presne neodpovida specifikaci, ale funguje to dobre - mimochodem, atori puvodniho schematu zapomeli nastavit uroven, kterou se specifikuje typ obrazu). No a pro prevod na S-video ci kompozitni video jsem na webu vzal schema s AD-722 (a take mou oblibenou 555, ktera tam narovnavala delky synchro pulsu :-). -
Pavel TišnovskýZlatý podporovatelNa tech starych televizich (i ceskych) se mi libilo, ze se k nim dodavala docela dobra technicka dokumentace. Slo napriklad o seznam mericich bodu, kde ke kazdemu bodu bylo nakreslene, jak na nem ma vypadat signal na osciloskopu. Spolu s dodavanym schematem (!) to bylo dost dobre na vyuku.
-
Pavel TišnovskýZlatý podporovatelNo, nejakej rychlejsi PIC by to urcite zvladl, vsak taky prenosove pasmo televize je pod 7 MHz. Ja jsem mel s pouzitim mikroradicu problemy, protoze kazde preruseni se ihned projevilo na generovanem obraze. Zase to melo vyhodu v tom, ze pokud se generovala pouze mrizka, tak se dalo presne vizualne vydetekovat, kdy preruseni nastalo :-)
-
Radovan Garabík (neregistrovaný)Hardwareovy emulator PMD85 http://www.kmit.sk/~peto/AVR/smallpmd/index.php podla popisu generuje video in real time softwareovo.
-
krupkaj (neregistrovaný)muzu potvrdit. Videl sem to v realu na Foreveru a je to povede. Ale on tam ma pomerne silny jednochip rady AVR, takze se nedivim, ze to zvlada generovat.
Jinak nasel sem v bookmarku ten odkaz na PICPONG, kdyby to nekoho zajimalo.
http://www.rickard.gunee.com/projects/ -
Pavel TišnovskýZlatý podporovatelTen PicPong vypada dobre minimalisticky :-) - jednobitovy zvuk a dvoubitovy DA prevodnik na video. Zajimave je pouziti digitalnich joysticku, ty ja rad uz od dob Atarka :-)
Jo, taky tam autor spravne pise, ze cele video s tim PICem generovat neustiha - zvladne 156 pixelu na radek. Ten PIC jede na dvanacti MHz a zvladne cca 3 MIPS. Spatne to neni, ale na full video by potreboval alespon 6 MIPS. -
Pavel TišnovskýZlatý podporovatelTo je dost složité, protože to neběží na stejném hardwaru ani systému. I používané programy jsou dost odlišné - SGI je používáno pro náročné vizualizace a proto dost rychle podporují prakticky všechno z OpenGL. Naproti tomu PCčkové karty jsou optimalizovány pro rychlé vykreslování trojúhelníků (nic jiného uživatele a především testery nezajímá - chtějí prostě jedno absolutní číslo), ale zkuste jim podhodit wireframe model ("dráťák") - rychlost vykreslování paradoxně klesne, i když algoritmus pro čáry je nepochybně omnoho jednodušší než vykreslování trojúhelníků.
Ad čáry (úsečky) - existuje několik velmi pěkně navržených algoritmů pro vizualizaci vektorových polí právě pomocí otexturovaných čar. Vtip spočívá v tom, že volba textury (resp. umístění čáry na 2D textuře) se vypočítá podle orientace čáry vůči světelnému vektoru. Ovšem na PC tento algoritmus nemá šanci, to už je snad lepší vykreslovat pomocí SW :-) -
jezeq (neregistrovaný)no rekl bych,ze pri rasterizaci wireframe modelu rychlost vykreslovani "paradoxne klesne" na libovolnem opengl hardware (at uz hi-end nebo lo-end).nejde ani tak o slozitost algoritmu,jako o to,ze rasterizace trojuhelniku bude mnohem optimalneji vyuzivat cache a je celkove mnohem koherentnejsi napric pipeline.
a mohl by jste me kdyztak odkazat na nejaky clanek o tom algoritmu na vizualizaci vektorovych poli?
z toho co popisujete mi neni jasne proc by to pro konzumni pc kartu mel byt problem,nebo proc by v tomto pripade dokonce mela byt pomalejsi nez softwarovy rasterizer. -
Pavel TišnovskýZlatý podporovatelChápu, že trojúhelník je z prostorového hlediska koherentní. Ale stejně, pokud ten samý trojúhelník vykreslím pouze pomocí wireframe, tak by to v žádném případě nemělo být pomalejší. Teoreticky na každém vykresleném bodu wireframe trojúhelníku může dojít k výpadku cache nebo k přepočtu pozice v textuře, ale to stejné přece nastane u vyplněného trojúhelníku na hranách a kromě toho se musí načíst a vyrastrovat všechny vnitřní body.
Pokud se bude například jednat o trojúhelník se souřadnicemi (v prostoru obrazovky i pro jednoduchost ve světovém prostoru) [0,0], [100,0] a [0,100], tak se při vykreslení wireframe modelu hrábne do framebufferu přibližně takto:
100+100+sqrt(2*100^2)=341 fragmentů
Kdežto při vyplnění:
100*100/2=5000 fragmentů
Tj. poměr je 1:14 a to by se IMHO mělo projevit (v SW řešení se to projeví).
Při přístupu do texturovací paměti to platí ve stejném poměru.
Já dnešní výrobce GPU celkem chápu, jsou tlačeni (a sami si za to trošku můžou) jedním směrem - počtem vykreslených otexturovaných plošek, podobně jako Intel je tlačen do stále vyšších frekvencí a radikální změnu v jádře dělá jednou za tři roky.
Ten článek je tady:
Stalling D., et al.:
Fast Display of Illuminated Field Lines
IEEE Transaction of Visualization and Computer Graphics,
Volume 3, April 1997, strany 118-127
Ten časopis by snad měl být k dispozici v technických knihovnách, na 100% je také na FIT VUT :-) -
Kio (neregistrovaný)Ve skole jsme onehda zkouseli hrat Quake3 na sestave SGI O2 (s R5000@180MHz ... nazev grafiky si nepamatuju) a hra jela v plnem rozliseni na 21" monitoru (1600x1200?) naprosto stabilne, procesor mel v topku jeste rezervu a v FPS se scena stabilne drzela na synchronnich 72FPS s monitorem. Nevim ale jestli jsme tehda cast z toho nepousteli na serveru (2x Origin 200)
ČLÁNKY DO MAILU