spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »SlinDev«

Der Immediate Mode hat nichts mit Shadern zu tun.

Das ist doch genau das, was ich gesagt habe.
Dennoch ist man noch immer in der Lage ohne einen eigenen Shader zu arbeiten (der ja doch gern mal Verständnisprobleme und zusätzlichen Aufwand der Initialisierung bedeutet) und trotzdem keinen Immediate Mode zu verwenden. Ob man das sollte sei mal dahin gestellt, aber wenn man das tut, gibt es halt einen default-Shader.

Zitat von »iSmokiieZz«

Dieser Ansatz ist jedoch unperformant, da jeder API Call (DrawObject()) warten muss, bis die GPU mit dem aktuellen Vorgang fertig ist.

Aufgrund der Pipeline muss die GPU nicht nach jedem API Call warten, bis der Vorgang abgeschlossen ist.
GPUs haben dadurch einen sehr hohen Durchsatz.
Aber natürlich ist Hardware Instancing besser, als jedes Objekt einzeln zu rendern.
Gruß,
Lukas

Im Gegenteil sogar. Oft braucht ein Entwickler oder eine Engine ein Ergebnis vorheriger Operationen (Multi-GPU macht hier gern Probleme) um mit den Ergebnissen weiter zu arbeiten. Oft z.B. bei Post-Effekten.

In diesem Fall ja, z.B. bei Gaussian Blur, oder noch schlimmer 'Occlusion Culling' wo die CPU auf Resultate der GPU warten muss.

Aber solange das nicht der Fall ist - und im Beispiel von iSmokiieZz sehe ich das nicht - kann man vom Throughput der GPU gut Gebrauch machen.

Definitiv, ja.

Um noch ein bisschen mehr zu klugscheißen: Ich sehe ein, dass es mit multi-gpu alles etwas komplizierter wird, aber da sollten sich eigentlich Treiber und Hardware um die meisten Dinge kümmern. Meistens ist es aber so, dass wenn es tatsächlich mal außer beim Buffer Swap vorkommt, dass die CPU auf die GPU warten muss man etwas falsch macht, denn wirklich gerechtfertigt ist es fast nie. Das Beispiel mit dem Gaussian Blur verstehe ich nicht, denn da hat die Grafikkarte doch das original Bild, rendert mit horizontalem Blur in eine neue Textur und rendert das mit vertikalem Blur entweder wieder in die erste oder noch eine neue Textur. Dabei bleibt das aber alles auf der Grafikkarte und die CPU muss auf nichts warten.
Occlusion culling ist tatsächlich problematisch, aber genau aus diesem Grund wird es in richtigen Anwendungen dann auch nicht so naiv implementiert, denn dann wäre es meistens deutlich langsamer als ohne. Meistens ist der Ansatz bei solchen Problemen, asynchron zu die Daten zurück zu bekommen, mit dem Nachteil, dass die Daten dann mindestens einen Frame hinterher hängen, was man dann wenn nötig wieder versuchen kann auszugleichen.

Du hast schon bei vielen Post-Effekten ein Problem, wenn Du irgendwas in eine Textur renderst, eventuell Teile aus ihr heraus woanders hinkopierst und davon dann lesen willst. Ich hatte den Ärger schon, da waren bei vielen Spielern plötzlich gewisse Shader/Post-Filter Effekte eben nur schwarze Quads. GLFlush und alles lief wie erwartet. Dasselbe Problem findet sich oft. Auch im Zusammenhang mit der SFML und RenderTextures schon gesehen.

Und wie lautet die Lösung zum Multi-GPU Problem?
Jetzt habt ihr mich neugierig gemacht Kennen Shader soetwas wie Mutex?

GLFlush.

Zitat

Aufgrund der Pipeline muss die GPU nicht nach jedem API Call warten, bis der Vorgang abgeschlossen ist.
GPUs haben dadurch einen sehr hohen Durchsatz.

Es ist richtig, dass die CPU nicht auf die Beendung eines Draw-API Calls warten muss. Der Einfachkeit und ohne das Buffering bis zum Flush in betracht zu ziehen, hab ich das so jedoch formuliert, da auch die Anzahl der DrawCalls (hochkomplexe und moderne Optimierungen durch den Software Driver außer Betracht gelassen), und somit die Größe des Command buffers, auf die Ausführungszeit vom Flush Einfluss hat