Multithreaded
-
Hallo Leute, ist ein Spiel nicht bedeutend schneller, wenn es multithreaded programmiert ist?
Damit könnte z.B. während im einen Thread auf IDirect3DDevice9::Present gewartet wird, im anderen Thread bereits das nächste Frame berechnet werden?
-
Ist schwer so synchronisieren sowas. Ich hab mal aus Spass in einer OpenGL Anwendung das Rendering in einen eigenen Thread verlagert. Das machte eigentlich mehr Ärger als das es was nützte.
-
Lass es sein.
Wir arbeiten auch an einer multithread-Anwendung (laeuft aber auf einer SMP, da macht das schon Sinn..), die Synchronisation von collision handling, solver und Grafik ist ein Riesenaerger
Tu es nicht.
edit: versteh ich das richtig, Du willst alleine die Grafikberechnungen auf mehrere Threads verteilen?
wie soll denn das funktionieren....
-
Neinein ich möchte alles ausser IDirect3DDevice9::Present im einen Thread und eben IDirect3DDevice9::Present im anderen Thread aufrufen.
-
hi,
was bringt es, nur IDirect3D9Device->Present() in einen Thread? Dieser Aufruf bringt nur den Backbuffer auf den Bildschirm. Vor IDirect3D9Device->Present() is doch bereits alles gerendert, oder?
Bringt das Multithreading auch auf Prozessoren mit Hyperthreading (HT) nichts?
-
Ab einer gewissen CPU Leistung liegt der Engpass fast immer bei der Grafikhardware. Von daher ist es meist sinnvoller, die Grafikdaten zu optimieren (Menge, Form usw - Culling-Algorithmen auf CPU Ebene)
anstatt dem Prozessor Luft zu verschaffen. (Das soll aber auch nicht heissen, das man den letzten Chaoscode schreiben kann, nur weil leistungsfähige CPUs standard sind
)
-
Man sollte aber beachten, dass die Zukunft in Richtung Parallelität geht. Man achte nur auf Hyperthreading und Dual-Core. Wenn du also das Spiel aus Lernzwecken programmierst, dann versuch dich doch gleich mit Multithreading. Wenn du natürlich nur ein Spiel fertig programmieren willst, dann mach es ohne Multithreading.
-
ich würde auch eher multithreading nutzen als alles in eine riesige schleife zu packen.
-
net schrieb:
ich würde auch eher multithreading nutzen als alles in eine riesige schleife zu packen.
Ahja. Und für jeden Frame wir dann wohl 'nen neuer Thread gestartet...
Bye, TGGC (Keine Macht den Dummen)
-
also wenn du 20spiele gemacht hast, dann hasst du genug grundlage um dich mit multithreaded applikationen zu ärgern. ach ja, wenn du kein multiprozessorsystem hast (bzw HT), dann kannst du garnicht all die schönen 'sachen' lernen die auftauchen können, teste es also auf jeden fall nicht nur auf SP.
rapso->greets();
-
TGGC schrieb:
Ahja. Und für jeden Frame wir dann wohl 'nen neuer Thread gestartet...
was verstehst du unter 'frame'?
-
Gar nix, weils da so laut ist.
Bye, TGGC (Keine Macht den Dummen)
-
Ahja. Und für jeden Frame wir dann wohl 'nen neuer Thread gestartet...
TGGC überleg doch mal,(oder vielleicht sollte ich ein wenig überlegen?
)
Während die GPU Berechnungen durchführt, muss die CPU warten. Währe es denn da nicht sinnvoller, wenn die CPU in einem parallelen Thread in der zwischenzeit schon mal das nächste Frame berechnet?Einen lieben Gruss Ishildur
-
in java hab ich sowas gemacht.
2 threads. der eine ist für das rendern, der andere war für die kollisionberechnungen usw.
hat eigentlich richtig gut geklappt.
der renderthread braucht ja nur die position der objekte die er zeichnen muss. d.h. er greift eigentlich nur lesend auf die daten zu, während der berechnungs-thread lesend/schreiben darauf zugreift.
was spricht dagegen sowas in einer komplexered grafik-anwendung anzuwenden?
-
Ishildur schrieb:
Ahja. Und für jeden Frame wir dann wohl 'nen neuer Thread gestartet...
...
Während die GPU Berechnungen durchführt, muss die CPU warten...Wie kommst du darauf ? Ist nicht böse gemeint, also ich wills wirklich wissen (Will ja nicht doof sterben
) Ich bin bisher immer davon ausgegangen das eben genau das bei Hardware-Beschleunigern nicht passiert.
-
Naja, rufe mal die Methode IDirect3DDevice9::Present mit eingeschaltetem vertical-sync auf. Was passiert da, die Framerate entspricht ziemlich genau der Bildwiederholfrequenz des Bildschirms... Woraus dieser Umstand wohl zurückzuführen ist?
Huuups, ich habs: IDirect3DDevice9::Present kehrt erst zurück, nachdem alles erledigt ist! Und das kann dauern....
-
ist bestimmt toll wenn die cpu schon frames berechnet, die erst 2 std später von gpu rendert werden können. Besonders ansprechend ist das ganze, weil dann der benutzter 2 stunden darauf wartet, dass seine aktion auch wirklich ausgeführt wird
und nein, das programm wartet nicht grundsätzlich bis die gpu fertig ist ..
ich würd einfach mal behaupten:
t(frame) = max(t(cpuBerechnungen),t(gpuBerechnungen))
-
t(frame) = max(t(cpuBerechnungen),t(gpuBerechnungen))
Genau, so wäre es mit einer Multihread-Applikation!
Singelthreaded wärs wohl eher so:t(frame) = t(cpuBerechnungen)+t(gpuBerechnungen)
-
Singelthreaded wärs wohl eher so:
t(frame) = t(cpuBerechnungen)+t(gpuBerechnungen)
also bei mir nicht..
-
Ishildur schrieb:
t(frame) = t(cpuBerechnungen)+t(gpuBerechnungen)
nein, das ist falsch, das mit max ist die richtige formel. ein commando das du an die gpu schickst, kommt erstmal in eine queue. dort werden je nach framerate,treiber,hersteller dann bis zu 5frames im voraus gespeichert. das ganze kann nur durch folgende dummheiten ausgehebelt werden:
-z-/framebuffer-lock
-resourcen-lock (z.b. vertex-/index-/texturebuffer)
-taskswitchin manchen spielen(AFAIK z.B. UT2004) kann man in den optionen einstellen dass das ausgehebelt werden soll, weil man dann natürlich weniger lag sieht weil nicht 5frames im voraus gespeichert werden.
gpu und cpu sind schon zwei "threads" die unabhängig von einander laufen können.
rapso->greets();
