OpenGL - 2D

[frca]

Zdravim,
da se nejak v OpenGL akcelerovat 2D grafika? A ted nemyslim natazeni textury na quad a jeho vykreslovani, ale dynamicke kresleni po pixelech, proste neco takoveho (napriklad): http://en.wikipedia.org/wiki/Plasma_effect
Diky,
frca
_________________
www.FRANTICWARE.com

[OndraSej]

Co myslíš tím akcelerováním? Spočítat plazmu na GPU? Asi se podívej na to, co se dá dělat pomocí GLSL a Pixel (Fragment) shaderů.
_________________
http://trionteam.net

[frca]

Pocitat primo na GPU ne (i kdyz by to taky slo, ale o to mi ted nejde). Pokud si vezmu srovnani GDI a DDraw, tak je rychlejsi DDraw. Jde mi o nasimulovani DDraw pomoci OpenGL. Asi je to o tom, jak rychle se prenasi data z RAM do frame bufferu. Nevim, jak to presne resi GDI nebo X protokol, ale urcite existuje rychlejsi zpusob. Prave ten me zajima, a vzhledem k tomu, ze OpenGL je graficka knihovna, tak logika veci rika, ze by to pomoci ni mohlo jit.
_________________
www.FRANTICWARE.com

[Quiark]

No já nevim... tak vytvořit si texturu, nasypat do ní pixely a poslat ji běžně přes OpenGL na kartu (do videoRAM), pak vytvořit quad a na něj ji natáhnout a zobrazit?
_________________
Mám strach

[OndraSej]

Tak ted fakt nevim, o co presne ti jde. Spocitat neco na CPU a pak to zobrazit? Pak ano - na CPU si to spocitas, nahrajes jako texturu a tu pomoci quadu vyrenderujes. Ale prenos RAM -> VRAM je presne to, co je pomale (a DDraw bylo rychle prave v tom, ze vetsinu veci umoznovalo delat v ramci VRAM, bez primych zasahu CPU).

Jinak i to GDI je celkem rychle (zobrazi plynulou grafiku), pokud nekreslis primo na obrazovku, ale pres off-screen buffer. Princip stejny jako backbuffery u DDraw, efekty hodne podobne.
_________________
http://trionteam.net

[frca]

U DDraw je ukazatel na nejaky surface, pomoci nejz se meni barvy pixelu. Pamet, kam ukazuje, je teda v RAM, nebo ve VRAM? A co vubec dela ten lock a unlock?
_________________
www.FRANTICWARE.com

[OndraSej]

Surface v DDraw je sice ukazatel, ale je to ukazatel na objekt, ktery reprezentuje blok pameti (typicky ve VRAM, ale mohl byt i v RAM). Pozor na to, ze to je ukazatel na objekt, ne na samotnou pamet s pixelama! Tu menily az samotne metody toho objektu a primy pristup k pameti, kterou Surface reprezentuje, neni mozny. Ten pointer, ktery ma programator v ruce samozrejme jde do RAM, ale v RAM je jenom objekt, ktery uvnitr nekde ma pointer (handle) do VRAM.

Resp. ten pristup mozny je, prave pres Lock & Unlock. Ty zajistily namapovani kusu VRAM do RAM tak, aby k surface bylo mozne pristupovat. Jak presne to probiha nevim (jestli je tam primy pristup pres ty mapovane adresy, nebo se kopiruje pri Locku tam a pri Unlocku zpet; asi to muze zalezet i na ovladacich), nicmene vysledek je ten, ze do pameti s pixelama jde pristupovat jen mezi Lock & Unlock a Lock & Unlock kazdopadne jsou netrivialni operace a (minimalne v DirectX 5) Lock znamenal globalni pouziti globalniho mutexu nekde v kernelu. Jak to bylo v dalsich verzich nevim.

Stale jsi ale nenapsal, ceho chces dosahnout... Zapisovani pixelu do vystupniho bufferu? Zapisovani pixelu do textur? Renderovani do textur?
_________________
http://trionteam.net

[frca]

Jo, asi to zapisovani pixelu do vystupniho bufferu.
_________________
www.FRANTICWARE.com

[OndraSej]

Takze hledas glDrawPixels/glReadPixels? (ktere asi nebudou moc rychle a nedoporucoval bych je pouzivat, ale existuji)
_________________
http://trionteam.net

[frca]

Ja to chci ale zrychlit, ne zpomalit
Takze zustat u DDraw? A pod linuxem co?

Jinak co se tyce OpenGL, tak jsem mel tajny tip na pixel buffer object, ale nikdo ho tu nezminil... No a v souvislosti s tim by uz mohla prestat platit ta ohrana pisnicka, jak je glDrawPixels pomale. Ale nevim, jestli to nebude i tak pomale, proto se tady snazim najit nejake zkusenosti.
_________________
www.FRANTICWARE.com

[Quiark]

Když to budeš počítat ve fragment shaderu, bude to ďábelsky rychlé
_________________
Mám strach

[MD]

Ja se obavam ze zadnou zazracne rychlou funkci nenajdes. Je to proto, ze dnesni hardware nic takoveho proste neumi, takze to musis zrychlit sam pomoci nejakeho chytreho figle

1) zakladni moznost. Mit v RAM backbuffer, do ktereho si softwarove zapisujes pixely na libovolna mista. Kdyz je snimek hotovy posles cely buffer na kartu (viz Lock-Unlock operace vyse). Tohle je pomale jednak proto ze pixely pises softwarove po jednom a jednak proto, ze kazdy snimek prenasis velke mnozstvi dat na kartu (a cim vyssi rozliseni tim pomalejsi) Je mozna optimalizace, ze se prenasi jen urcity vyrez, ktery se zmenil. (Myslim, ze surova prace s bufferem by mela byt rychlejsi, nez glDrawPixels, pokud pixelu bude hodne.)

2) Zkusit obrazek sestavit z bitmap. At uz konstantnich obrazku, animaci nebo neceho pocitaneho, co se da ulozit do cache. (Protoze tu samou bitmapu pouzijes jinde nebo jindy znovu.) Pak ses na tom celkem dobre, bitmapy nahravas do vram, mapujes na quady, kreslis. Tohle je rychle.

3) Pokud jde o nejakou plazmu, sum atd., tedy neco, co se da vypocitat nejakym vzorcem v pixel shaderu, tak to udelat. Vykreslit quad a shader nahodi potrebny plazmoidni pixely.
_________________
- play with objects - www.krkal.org -

[frca]

Tak jsem zkousel test 2D v SDL na linuxu (tam ani neni potreba lock/unlock, protoze SDL_MUSTLOCK(surface_okna) je 0). Dal pak prenos pomoci pixel buffer objektu (dvojiteho, glMapBufferARB) a glDrawPixels(..., 0). Vyslo mi, ze to druhe je jeste o nejakych 10 % pomalejsi.
_________________
www.FRANTICWARE.com

[OndraSej]

[Marek]

Vykreslíš fullscreen quad/triangle (je to jedno). V pixel shaderu dostaneš vstupní texturu/další data, uděláš operaci nad pixelem. Uložíš do výstupní textury. Tohle by mělo být nejrychlejší, protože to tak dělá každý.

Pokud chceš naprogramovat výpočet nějakého obrázku, můžeš to udělat jenom v pixel shaderu a k tomu potřebuješ zařídit všechny ty věci okolo.

Vertex shader můžeš využít na předpočítání nějakých dat, na výstup můžeš dát minimálně 32 floatů a data budeš mít automaticky lineárně interpolovaná mezi jednotlivými vrcholy pro každý pixel (nelineární interpolace jde taky). Dá se tak urychlit i blbej blur (offsetuješ koordináty už ve vertex shaderu).

Jiná možnost: Použít CUDA nebo OpenCL (až bude rozumně dostupné), ale tam zas není přístup k některým funkcím hardwaru (ROP jednotky, interpolátory, depth a stencil buffer...). Nebudeš muset použít fullscreen quad, ale bude to mnohem víc low-level, než si dokážeš v tuto chvíli představit.

K Lock/Unlock paměti ve VRAM vs RAM:
Teoreticky by neměl být problém locknout paměť ve VRAM (vždyť si přece vezme shora kus adresovatelného paměťového prostoru), driver a systém to ale musí umožnit. Předpokládej, že locknutá paměť není cachovaná = náhodný přístup je zlo, vyplňuj to sekvenčně (to samé platí pro glMapBuffer). Na novém hardware to jde i naopak, GPU umí číst přímo z RAM přes PCIe, ale mohou s tím být komplikace (viz CUDA 2.2).