Vlákno názorů k článku Grafické karty a grafické akcelerátory (25) od Luboš Doležel - Docela by mě zajímalo výkonnostní srovnání těchto akcelerátorů...
-
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