Multithreaded
-
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();
-
-
Ishildur schrieb:
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....
Im Klartext willst du also das Prinzip der vertikalen Synchronisation auf den Kopf stellen
Dir ist aber klar, das du am Problem vorbeidenkst oder ? Hier wartet die CPU nicht auf die Grafikkarte sondern die Grafikkarte auf den Monitor.
