OpenGL vs vlakna

[pcmaster]

Zdar,

mam monzo neobvykly, mozno lamersky dotaz. Z toho co viem, nie je rozumne ani dovolene pouzivat GL context v inom vlakne nez v tom, ktore ho vytvorilo. Moj problem je taky, ze mam hlavne vlakno, ktore vytvori GL kontext, textury, objekty, vsetko a potom v hlavnom loope kresli. No a jedna vec, ktoru kresli a preco ju chcem oddelit do samostatneho vlakna, je vysledok mojho (skoro-realtime) raytracera. Problem je ten, ze mily (CPU C++) raytracer doteraz zapisoval svoje pixely pekne do GL buffera (glMapBuffer, zapise pixely, co mu moze trvat aj sekundu, ale aj minutu a potom glUnmapBuffer). Toto teraz po pokuse s vlaknami nefunguje, dostavam logicky GL_INVALID_OPERATION (v glMapBuffer).

Napadlo ma obalit VSETKY OpenGL volania kritickou sekciou (mutexom) tak, aby vzdy prave jedno vlakno volalo ktorekolvek GL prikazy. Nepomohlo. Jedine riesenie pre tento moj CPU raytracer, ktore ma napadlo, je nerenderovat do GL textury/bufferu, ale do obycajneho CPU bufferu a ten potom nakopcit v hlavnom vlakne do GL textury a blitnut. To by este slo.

No dalsi a ovela zavaznejsi problem nastane pri OpenCL raytraceri, ktory potrebujem tiez oddelit do samostatneho vlakna (trva radovo jednotky sekund), pretoze chcem, aby GUI ostalo interaktivne. Moznost vytvarat (Nokia) Qt GUI v inom vlakne nez vo vlakne, kde sa vytvara GL/CL context pre mna absolutne neprichadza do uvahy! To si neviem predstavit celkom, ale mozno to je mozne. Len pre informaciu, GL/CL context, buffery a textury sa normalne sharuju ako medzi GL a GL contextmi, takze predpokladam, ze problem s thread-safety nastava logicky aj tu.

Ako to riesit? Ako navrhnut vlaknovy model tak, aby som v hlavnom vlakne mohol kreslit obycajne GL veci a zaroven v inych vlaknach mohol vykonavat velmi casovo narocne CPU/GL/CL operacie, ktore musia sahat na GL/CL buffery/textury? Viem, ze driver si uz volana CL kernelov a GL shaderov vie nejako zmanazovat, beha to pekne asynchronne. CL/GL GPU device mam len jeden (CL CPU sa nepocita, pretoze mi nepomoze ) Mozno vytvorit viacero kontextov? :-O Ako sa potom sharuju GL textury? Ma to nieco s GL Texture Object extensions, ak nieco take je? :-O

Kludne piste hocijake napady ci otazky!
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[]semo[]

[nou]

samozrejme ze sharovanie textur, VBO a vlastne vsetkych objektov funguje aj na linuxe. samotne Qt ma na to podporu ked staci predat QGLWidget pointer na druhy widget s ktorym sa budu zdielat objekty.

ale ten pristup MapBuffer, vykreslujem dlho do toho bufferu UnmapBuffer je v pripade vlakien zly pretoze to zabija subeznost tych vlakien pretoze na seba musia tak ci tak cakat.
ked uz treba zaviest double buffering kedy sa kresli z jedneho bufferu na obrazovku a ruhy je namapovany kresli sa donho v raytracery.

ale v tvojom pripade by bolo vhodnejsie pouzivat OpenGL/OpenCL interoperabilitu a pouzivat clEnqueueAcquireGLObjects() taktiez v spojeni s double bufferingom.

pretoze co je treba zabezpecit je aby sa v OpenGL casti nepouzival objekt ktory je zamknuty cez clEnqueueAcquireGLObjects().

GUI musi byt v Qt tvorene len v hlavnom vlakne http://doc.qt.nokia.com/4.6/threads-starting.html vid dole
OpenGL vykreslovanie by som drzal v hlavnom vlakne. pochybujem ze potrebujes vykreslovat nieco co nie je zvlanutelne realtime a teda by brzdilo GUI.

v konecnom dosledku by som mal dve vlakna. hlavne a potom CL vlakno v ktorom by sa rendrovalo a v nom by som drzal vsetky CL volania.

myslim ze vhodnym prikladom ako spravit je myslim tento priklad http://doc.qt.nokia.com/4.6/threads-mandelbrot.html
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[pcmaster]

No. Problem je, ze som povodne vobec nechcel mat 2 a viac GLWidgetov (rozumej kontextov). To, ze je to s tym mojim pristupom pisat 5 sekund do namapovaneho bufferu zle, som pochopil.

CL/GL interoperabilita mi funugje a clEnqueueAcquireGLObjects samozrejme odzaciatku pouzivam, vobec si neviem predstavit napisat ani tu jednovlaknovu vec bez toho

No a k tomu vykreslovaniu len v hlavnom vlakne. Ok, skusim to tak, ze C++ tracer bude pisat len do CPU pamati. To verim, ze bude fachat. Este to CL, no.

Rekapitulacia, kreslim:
- Qt GUI (hlavne vlakno)
- OpenGL rasteriser (ostane tiez hlavne vlakno, toto je rychle)
- OpenCL raytracer (kresli do sharovanych CL/GL bufferov, chce byt nove vlakno)
- C++ raytracer (kresli nateraz do GL buffer, bude do CPU bufferu, chce byt nove vlakno).
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[pcmaster]

Ok, tak C++ cast som vyriesil. Pouzil som QThreadPool, jednotlive vlakna si postupne beru "casti" vysledneho obrazu. Posledne po skonceni o tom informuje hlavne vlakno. Vtedy uz su vsetky vlakna ukoncene, hlavne vlakno odmapuje buffer, uploadne obrazok na device (do textury), swapne buffery, namapuje novy novy zadny buffer a ten s prikazom na start posle wrapperu nad QThreadPool, ten pospusta vlakna a ide sa zase dokola. Ma to nejake nevyhody, napriklad je tam kopec overheadu, ale vzhladom na to, ze rendering trva velmi dlho, tak to vobec nevadi. Co sa tyka CL/GL druheho vlakna, este som to neriesil. Budem informovat
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.