Více OpenGL rendering kontextů

[pcim]

Můžete mi prosím někdo objasnit následujcící ? :

Pokud mám v OpenGL více než jeden rendering kontext, a tyto kontexty mezi sebou sdílí objekty (WGL_share_lists), nese to s sebou nějakou zvýšenou režii při volání OpenGL funkcí ? Říkám si, že pokud dva thready přes dva kontexty nějak manipulují s jedním a tím samým sdíleným OpenGL objektem (např. texturou), tak přístup k objektu jako takovému musí být obalen nějakou kritickou sekcí, mutexem apod., který by v tam v případě jednoho kontextu být nemusel.

Jde mi například i situaci, kdy jeden thread čistě jen renderuje a v druhém se plní VBOs, textury apod. Samozřejmě to asi jde udělat i bez použití druhého kontextu např. pomoci glMapBuffer(), ale to už je jiná otázka.

[Marek]

Řežie tam rozhodně je a podle mě je zbytečné mít 2 kontexty, protože grafická karta dokáže v jednu chvíli obsloužit jen jeden. Když už chceš něco uploadovat za běhu, používej třeba glBufferData nebo glMapBuffer s parametrem GL_WRITE_ONLY. Ve chvíli uploadování může být aktuální buffer používán grafickou kartou a inteligentní driver zpravidla vytvoří druhý, kde uloží ty data a po dokončení práce grafické karty ho aktivuje a ten starý uvolní. To je asi nejvhodnější způsob, protože se nic nemusí zamykat a karta nemusí přerušovat svoji činnost. Nutno podotknout, že když použiješ glBufferSubData nebo glMapBuffer s jinými parametry, tohle nastat nemůže, protože si tím vynutíš editaci toho stávajícího bufferu a tam už driver musí zamykat. Zajímavá myšlenka co? - mít na kartě 2 buffery a mezi nima přepínat - zatímco se jeden plní, druhý se používá. U VBO to inteligentní drivery dělají automaticky. Jak je to u textur si nejsem jistej, ale není problém stejnou fintu naprogramovat pomocí dvou textur, že.
_________________
AMD Open Source Graphics Driver Developer

[pcim]

Myslel jsem si, že ty dva kontexty asi nebude to nejlepší řešení, ale zdálo se mi takhle to načítání na pozadí implementačně trochu jednoduší. Pokud bude všechen GL kód jen v renderovacím threadu, bude se zde muset např. zavolat glMapBuffer, pak nějak sdělit načítacím threadu,, že ho může naplnit a až ten to udělá tak zase sdělí rwenderovacímu threadu, že je hotov a ten pak provede glUnmapBuffer. Trochu složitější, ale nějak by se to asi udělat dalo.

To co jsi psal o přeínání více bufferů mě ale přivádí na otázku jak vlastně spravovat buffery, např. VBO. Četl jsem na to různé názory, ale stále vlastně nevím jak to správně řešit. Jsou třeba tyto dvě možnosti :

1. Každý objekt, nebo prostě něco co se rederuje v jednom render callu má svůj VBO :

Výhody :
- Implementačně jednoduché
- Alikace ani driver asi nemají problém s nějakou fragmentací bufferů
- Buffer se dá snadno a rychle naplnit a nebrzdí se tím rendering z jiných bufferů,
navíc jak píše Eosie by se driver měl postarat o vytvoření nového bufferu v případě, že by se plněný buffer právě používal pro rendering.
Nevýhody:
- Pokud se objekty načítají nabo donačítávají na pozadí až za běhu, budou se buffery vytvářet a rušit až v hlavní renderovací smyčce, což asi může brzdit.
- Častý glBindBuffer, pro každý render call se mapuje buffer(y) znovu.

2. Při startu engine se zaalokuje určitý počet poměrně velkých bufferů (např. 10 bufferů po 2MB) a ty se potom používají pro rendering všech objektů. V hlavní smyčce se žádné nové buffery nevytvářejí pouze se plní tyto existující.

Výhody :
- Žádné alokace bufferů v hlavní smyčce
- Méně časté přepínání bufferů, glBindBUffer.
Nevýhody :
- Složitější implementace, nutno vyřešit přidělování prostoru v bufferech objektům
- Při plnění dat objektu do jednoho bufferu pomocí glBufferSubData nebo glMapBuffer je třeba mít zajištěno, že z tohoto bufferu neprobíhá rendering ani žádných jiných objektů. Takže by bylo nutné vzájemně sladit pořadí renderování objektů s plněním bufferů tak, aby pokud možno nedocházelo ke kolizím.
- Problémy s framentací těchto velkých VBO

Jak to řešíte Vy ?

[tempicek]

[Marek]

pcim> Pokud chceš méně bufferů, můžeš ho udělat interleaved - prokládaný, tzn. uložíš za sebe pozici, normálu, koordináty, pozici, normálu... atd. Pak použiješ v gl*Pointer parametr stride, kde dáš velikost celého vertexu (sizeof(pozice a normála a koordináty)), a do pointer dáš akorát offset na konkretní atribut (pro pozici 0, pro normálu ((char*)0)+sizeof(pozice), pro koordináty ((char*)0)+sizeof(pozice a normála)).
_________________
AMD Open Source Graphics Driver Developer