Ich arbeite gerade noch an meinem Spiel, ich wollte dafür mehrere Threads benutzen. Nun habe ich aber gelesen, dass OpenGL aufrufe nur von dem Thread gemacht werden können, welcher OpenGL initiiert hat. Kann mir da jemand eine Lösung bieten. Ich bin bei meiner suche auf GLThread gestoßen, was es ist bzw. bewirkt habe ich nicht gefunden. Meine jetzige Lösung wäre einen Zeichenthread zu erstellen der eine List abarbeitet, welche von den anderen Threads gefüllt wird, mir wäre aber eine Lösung bei der alle Threads zeichnen könnten lieber.

_________________
You even trying ...

Website: http://rise-of-light.de/

Geht nicht. Könnte eh nur einer Zeichnen. Wegen DepthSort und so.
Davon abgesehen, kannst du den GANZEN Rest in Threads packen. Wie viele Kerne willst du unterstützen? 8?

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Ich hatte über eine Dynamische Lösung nachgedacht, welche theorthisch unendlich Kerne unterstützt, ich denke aber das kommt erst später und ab einer bestimmten Anzahl an Threads lont es sich ja sowieso nicht mehr. Mit war klar, das nur einer Zeichnen kann das hätte ich mit CriticalSection abgesichert, mich hätte interessiert, ob man das Recht zum Zeichnen auch auf andere Threads übertragen könnte.

PS.: Geht es wenigstens gleichzeitig ein VBO zu erstellen und etwas anderes zu zeichnen.

_________________
You even trying ...

Website: http://rise-of-light.de/

Du kannst von beliebig vielen Threads aus zeichnen, nur für OpenGL muss es so aussehen als ob es nur ein Thread wäre. OpenGL ist eine State-Machine und hat nur einen State, nicht für jeden Thread einen. Die sinnvollste Möglichkeit ist da eben nur einen Thread zum rendern zu benutzen.

Klassisches Konzept:
ein Thread rendert, während die anderen Threads parallel die Physik und Spiellogik für das nächste Frame berechnen. Am Ende jedes Frames (oder am Anfang) werden die zum rendern notwendigen Daten kopiert, damit der Render-Thread unabhängig arbeiten kann, während die anderen Threads die Daten verändern.



Nein. Du kannst aber natürlich schon mal die Daten für den VBO im Speicher vorbereiten, z.B. von der Festplatte laden. Anlegen des VBO und das kopieren der Daten auf die Grafikarte dauert ja im Vergleich nicht sonderlich lange.

_________________
Yeah!

Ok,
danke für die Antworten, ich stelle jetzt den Code so um das ein Thread rendert, und der Rest alles für den nächsten Frame vorbereitet.

_________________
You even trying ...

Website: http://rise-of-light.de/

Ich bin mir recht sicher, vor einer weile gelesen zu haben, dass OpenGL nicht thread-safe ist und damit schon das schreiben und lesen von mehreren Threads auf OpenGL Variablen schon schief geht. Noch dazu bricht dir dann auch die CPU ein, wenn ständig zwischen cpu und gpu gesynct wird, weil noch ein thread drauf zugreifen will.

Wie Coolcat schon sagte, ein Thread macht die reinen Rendercalls und andere Threads kümmern sich um das laden, verarbeiten und übergeben an den Renderthread.
Damit geht der Thread in ruhephasen und lässt anderen Threads platz auf dem Kern. Da ja alle rendercalls in einem block raus wirfst, dann geht er in pause, ein anderer thread startet und arbeitet, wärend dessen läuft auf der gpu alle rendercalls nacheinander durch. Es macht Sinn die Physik für den nächsten Frame nach dem absetzen der Rendercalls zu durchlaufen und auf Basis der Daten dann noch zu bestimmen was sichtbar ist und Rendercalls zu eleminieren. Danach kann man wieder ein Renderprozess durchlaufen.
Musik und Netzwerk kann unabhängig von diesen laufen, wobei sound wiederum abhängig von der Szene ist.
Es macht Sinn vorher die Abhängigkeiten zu prüfen und mal durch zu kauen, wie die sachen auf wievielen kernen parallel laufen würden.
Auch die Art des Threading ist zu beachtetn, wärend normale Windows und posix threads auf singlecore starke performanceverluste haben, gehen diese auf mehrkern gut ab aber können bei vielen ops auch zu performanceverlusten führen(z.B. bei Hashlisten, Array's, counter, ...).
Daher etabliert sich seit einer weile in High Performance Applications Atomic Operation. Diese benötigen keine mutex, condition, critical section, semaphore oder ähnliches und sind dadurch schneller(vorallem auf singlecore und cpus mit vielen Kernen).
Eine Atomic Operation hat auch den vorteil, dass Klassen nicht mehr abhängig von einer Thread API sind.
http://en.wikipedia.org/wiki/Compare-and-swap Ein Beispiel einer AO.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004