spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn ich mich recht erinnere gab es bei SFML einen BugTracker-Eintrag, das Window::GetSize() ziemlich lange dauert, weil jedes mal die Größe über das Betriebssystem ermittelt und nicht gecached werden. Diese Funktion wird sehr oft in dem RayTracer-Code sogar parallelisiert aufgerufen. Schau doch mal was passiert, wenn du die Größe nur einmal ermittelst.
Ansonsten ist es für das Betriebssystem keinesfalls schön, wenn permanent neue Threads erzeugt werden. Das kostet teilweise auch etwas Zeit. Üblicherweise implementiert man dafür so etwas wie einen Threadpool.
Das wird vermutlich nicht die Performance ins unermessliche steigern, aber versuchen kann man es ja mal

Einfacher wäre es für den Anfang das Bild in ein paar wenige Bereiche zu teilen und jeden komplett von einem Thread abarbeiten zu lassen. Dann erzeugt man die Threads auch nur einmal am Anfang. Vermutlich sogar sinnvoller als ein Threadpool mit notwendigem Scheduler.

Threadpool nur im Sinne von wiederverwendung bestehender Threads. Scheduler wird ja bei dem Verfahren wie er das ganze Rendert irrelevant sein.

Und natürlich sollte die Anzahl der Thread idealerweise irgendwie auf ein optimum ermittelt werden und entsprechend der Screen in Rechtecke aufgeteilt werden.

Dann brauchst Du aber auch keinen Pool. Kanonen auf Spatzen.

Zitat von »BlueCobold«

Einfacher wäre es für den Anfang das Bild in ein paar wenige Bereiche zu teilen und jeden komplett von einem Thread abarbeiten zu lassen.

Das wäre so noch kein wirklich sinnvoller Ansatz, weil Raytracing üblicherweise deutlich unterschiedlichen Rechenaufwand in verschiedenen Bildbereichen besitzt. Statisches Scheduling im Sinne von Einteilen in wenige Bereiche am Anfang wäre sehr ungünstig und würde dafür sorgen, dass einige der Threads viel schneller fertig werden würden, als der Thread, der den potentiell komplexen Teil der Szene darstellt. Die Rechenleistung wäre dann ungleichmäßig verteilt. Man sollte die Szene eher in viele kleine Bereiche einteilen und diese dynamisch an die verfügbaren Threads verteilen.
Ein Pool ist dafür dann schon sinnvoll.

Du kannst das Bild aber auch so aufteilen, dass die Threads alle Pixel nebeneinander berechnen.
Also
Task 1 macht Pixel 0, 4, 8, 12
Task 2 macht Pixel 1, 5, 9, 13
Task 3 macht Pixel 2, 6, 10, 14
Task 4 macht Pixel 3, 7, 11, 15
Dann haben alle Threads ähnliche Last. Damit braucht man noch immer keinen Threadpool.

Das könnte man theoretisch machen, die Sinnhaftigkeit zweifel ich aber an.
Es bekämpft eher die Symptome als die Ursache und eine optimale Verteilung ist damit noch lange nicht garantiert.
Außerdem schränkt es die Flexiblität bei erweiterten Aufgaben ein. Es hat schon seinen Grund, warum in der Praxis bei Raytracern dynamisches Scheduling betrieben wird.

Dynamische Verteilung der Last auf die Threads ist natürlich der der Königsweg.
Dabei muss es nicht schwer sein.

Unbedint möchte auf folgende Methoden hinweuisen:
http://msdn.microsoft.com/de-de/library/…(v=vs.110).aspx
http://msdn.microsoft.com/de-de/library/…(v=vs.110).aspx

So lassen sich sehr schnell neue Threads erzeugen. Das Scheduling geht wie von Geisterhand, die Performance ist sehr gut.
Vor allem aber ist es komfortabel zu benutzen.

Diese Methoden sind aber für .NET, nicht für natives C++.
Für C++ empfehle ich OpenMP, was ja von Visual C++ auch unterstützt wird. Das geht auch fast von Geisterhand

Zitat von »Spiele Programmierer«

Das könnte man theoretisch machen, die Sinnhaftigkeit zweifel ich aber an.
Es bekämpft eher die Symptome als die Ursache und eine optimale Verteilung ist damit noch lange nicht garantiert.
Außerdem schränkt es die Flexiblität bei erweiterten Aufgaben ein. Es hat schon seinen Grund, warum in der Praxis bei Raytracern dynamisches Scheduling betrieben wird.

Das mag ja alles stimmen. Aber es bleibt eine Kosten-Nutzen-Rechnung. Muss hier ein Scheduler oder Thread-Pool sein? Nö. Reicht eine Verteilung der Pixel auf eine fixe Anzahl Threads aus? Ja.