Könnt ihr euch mal über Parallele Programmierung in Spielen und CG auslassen? Also wie macht man das am besten, was bringts, wie wirds in aktuellen Titeln gemacht.

Ich frage, weil unsere Profs. zunehmen sagen: in 1-2 Jahren werden alle neuen Chips Multicore Prozessoren sein. Wer dann nicht wirklich Parallel Programmieren kann hat schlechte Chancen als Programmierer.

Mich würde einfach interessieren was Multithreading für Spiele und CG Anwendungen bringt und wie man es umsetzen kann.

Und auch Implementationsfragen:
Also wenn ich das Zeichnen z.B. auslagere, wie erwisch ich dann das OnIdle des Hauptthreads. Interessiet mich das noch?

Ein Tutorial zu dem Thema fänd ich spitze... Es ist ja bald Weihnachten...vielleicht werden da ja solche Wünsche war...

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ein Tutorial zum Thema Threads habe ich ja gemacht. Allerdings hast du da das Problem, dass es sehr wenig direkt mit der Grafik zu tun hat. Was ehrlich gesagt sowieso noch spannend genug werden wird. Denn gezeichnet wird so oder so nur aus einem Thread herraus. Zu mindest pro Kontext. Du bist im Übrigen nicht an OnIdle gebunden. Du kannst auch alles in einen Thread auslagern. Also Initialisierung und Zeichnen. Das klappt auch mit mehreren Kontexten problemlos. Allerdings hat man dann immer wieder Probleme, wenn es um die Windowsmessages und Fensterinteraktion kommt. Das muss dann alles peinlichst genau Synchronisiert werden und auch dann tauchen immer wieder komische Probleme auf.

Sonst muss ich ehrlich sagen, dass mehrere CPUs für Spieler oder Grafikprogrammierer in erster Linie nicht wirklich von Interesse sind. Das einzige was man machen kann ist alles nicht Zeichnerische auf einen anderen Thread auslagern. Aber das macht oft gar keinen Sinn, da die Operationen unmittelbar im Zusammenhang stehen. Und wenn man die Entwicklung betrachtet, dass Grafisches zunehmend mehr und mehr auf die GPU ausgelagert wird, kommt man in eine echte Zwickmühle. Also wenn man kontinuirlich Daten laden müsste oder einen Spieleserver am Laufen hätte das könnte man problemlos auslagern. Sonst würde es wohl eher auch nur bei CAD Anwendungen Sinn machen. Anso entweder komplett getrennte RCs oder man hat genügend Berechnungen die durchgeführt werden müssen.

Wenn ich mich recht erinner kommt Quake 3 im Übrigen auch mit mehreren CPUs klar. Da sollten wohl auch ein paar Optimierungen eingebaut sein. Aber auch dort ist es so, dass die für die hauptsächliche Arbeit nur eine CPU benutzen.

MoviePack eine Videoschnittsoftware. Die besteht aus einem OpenGL Renderer für die VideoAnimationen und einem Programm welches die Ein und Ausgangsdateien ließt und schreibt. Das sind aber 2 getrennte Anwendungen die eine rege Kommunikation haben. Das dürfte von einem MultiCore sehr gut profitieren.

Eine kleine Spinnerei. Wenn man mehrere Grafikkarten + Multicore im Rechner hat könnte man beide Karten dazu bringen sich das Rendern eines Bildes zu teilen. Was in größere Bildauflösungen resultieren dürfte. Allerdings ist da eine Softwarelösung immer die schlechteste Wahl. Das haben aber auch die Hersteller schon begriffen. Ich sage nur Crossfire und SLI. Da sind die Karten dann nicht komplett getrennt sondern werden vom Treiber zu einer Einheit verbunden.

Es geht einfach darum, dass neue Prozessoren eh alle echtes Multithreading unterstützen. Da kann man dann doch bestimmt auch für Spiele Profit draus schlagen. Also Grafik, KI, Physik - all das könnte man auslagern. Nur frag ich mich halt wo Signale wie OnClick vom Betriebssystem hingesendet werden. An den Hauptthread? An alle? Wenn man die Grafik auslagert, läßt du den Thread dann in ner Endlosschleife laufen, oder nimmst du auch sowas wie OnIdle? Halt solche Fragen...

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also das reine Rendering kann eh nur in einem Thread passieren, da die OpenGL Contexte jeweils an einen Thread gebunden sind. Aber die Phjysik z.B. kann ja parallel laufen und bei UT2007 soll man dadurch einen großen Geschwindigkeitsvorteil erhalten. Das Problem ist nur, dass man dann die Daten doppelt haben müßte und damit es zu keinen Konflikten zwischen den Threads kommt.
Eine andere Sache die bereits ohne Multiprozessor Geschwindigkeit bringt ist das Laden der Texturen im Hintegrund Thread. Der Thread wartet ja praktisch die ganze Zeit nur auf die Festplatte und kostet daher wenig.