Shader und Programmarchitektur
-
Geht mir nicht um's Programmieren, dass man das nicht öfter machen muss, ist schon klar. Nur um die Ressourcen die so "viele" Shader verbrauchen. Aber das ist, wie gesagt, eher ein theoretisches Problem.
-
Scorcher24 schrieb:
cooky451 schrieb:
Hm.. ein Shader/VBO? Na gut, normalerweise hat man nur so 100 verschiedene Models, da macht das wohl keinen so großen Unterschied, aber theoretisch gesehen ist es etwas Verschwendung, oder nicht? Benutzen die meisten Models normalerweise nicht den gleichen Shader?
Naja du brauchst nur einen Shader programmieren. Attribute wie Farbe kann man ja vor dem rendern des Models an ein uniform binden.
Das war auch meine Idee - macht die Sache sehr flexibel.
Besonders viele Modelle muss ich nicht verwenden, das Program ist kein Spiel.
Desweiteren denke ich das diese Technik die zukunftsträchtigste ist.Das Konzept ist immer das schwierigste. Ich habe nachdem ich mit OpenGL angefangen habe, die meisten Techniken aus den Tutorials displaylists etc. wieder entsorgt.
Gruss Peter
-
cooky451 schrieb:
Nur um die Ressourcen die so "viele" Shader verbrauchen. Aber das ist, wie gesagt, eher ein theoretisches Problem.
Wenn du zu Ressourcen nur Speicher zählst, dann mag das in der Tat kein großes Problem sein. Ansonsten ist es aber äußerst schlecht, viele verschiedene Shader zu haben, die im Grunde das gleiche machen, weil jeder Shader-Wechsel teuer ist (so ähnlich wie man Texturen nicht dauernd hin- und herwechseln sollte). Das hab ich selber oft genug gemerkt. Zudem ist es gut, selber zu wissen, welcher Shader grade aktiv ist, um ihn nicht nochmal zu binden, obwohl er schon aktiv ist - das kostet dann nämlich trotzdem nochmal (jedenfalls bei Hardware wo ich das getestet habe).
Ist bei kleinen Projekten sicher nicht so dramatisch, aber wenn man irgendwo von vornherein weiß, wo man einfach sparen kann, sollte mans auch gleich machen ; )
-
Powerpaule schrieb:
cooky451 schrieb:
Nur um die Ressourcen die so "viele" Shader verbrauchen. Aber das ist, wie gesagt, eher ein theoretisches Problem.
Wenn du zu Ressourcen nur Speicher zählst, dann mag das in der Tat kein großes Problem sein. Ansonsten ist es aber äußerst schlecht, viele verschiedene Shader zu haben, die im Grunde das gleiche machen, weil jeder Shader-Wechsel teuer ist (so ähnlich wie man Texturen nicht dauernd hin- und herwechseln sollte). Das hab ich selber oft genug gemerkt. Zudem ist es gut, selber zu wissen, welcher Shader grade aktiv ist, um ihn nicht nochmal zu binden, obwohl er schon aktiv ist - das kostet dann nämlich trotzdem nochmal (jedenfalls bei Hardware wo ich das getestet habe).
Ist bei kleinen Projekten sicher nicht so dramatisch, aber wenn man irgendwo von vornherein weiß, wo man einfach sparen kann, sollte mans auch gleich machen ; )Danke für den Hinweis, ich habe nirgens etwas darüber gefunden, wie teuer ein Shaderwechsel via glUseProgram ist.
Wenn du Werte hast würde ich mich freuen wenn du sie teilst - ansonsten muus ich wohl mal ne Benchmark machen.Gruss Peter
-
Die Grundregel ist: Jeder OpenGL Call ist verdammt teuer und sollte vermieden werden.
Es ist halt immer die Frage, an welcher Stelle sich das Optimieren lohnt. Wenn du 25 verschiedene Models hast, ist es egal ob du 25 oder 50 Switches pro Frame drin hast. Wenn du 2500 verschiedene Models hast, sieht das schon ganz anders aus. (Deshalb würde ich auch versuchen so ziemlich alles zu "instancen" (google instancing), 16 Objekte mit einem Call zeichnen zu können, kann schon einen ordentlichen Performancevorteil geben.)
-
So lange du weniger als hundert Objekte hast, ist es am Ende vermutlich völlig egal wie du diese renderst...
-
Hallo
ich möchte den Thread nochmal aufgreifen, weil ich mir etliche Gedanken darüber
gemacht habe.
Mein Grundansatz war von Anfang an, soviele Daten wie möglich auf der Grafikkarte zu haben, und die Anzahl der Transfers vom Host zur GPU so gering wie möglich zu halten.
Leider ist die nachträgliche Modifizierung von VBO Daten teuer, weil immer
grosse Mengen bewegt werden müssen. Dagegen sollte das an und abschalten eines Shaders doch billig sein.Wichtige Frage - wo wird ausführbare Shadercode abgelegt, im Videomem oder im Hauptspeicher? Auch wenn er gerade inaktiv ist.
Gruss Peter
-
Ich glaube nicht, dass OpenGL da etwas festlegt, aber vermutlich im VRAM. Allerdings dürfte das auch nicht so relevant sein, das bisschen Transfer. OpenGL Calls sind halt einfach an sich verdammt langsam.
-
Das Problem beim Wechseln von Shadern ist nicht, dass der Shadercode ständig über den PCI Bus geschickt werden muss (selbst wenn das der Fall wäre, wäre das wohl praktisch vernachlässigbar). Das Problem ist, dass (unter Umständen) die Pipeline (zumindest teilweise) leerlaufen muss, also erstmal alles was im Moment gerade gerendert wird, fertig laufen muss, bevor der aktuelle Shader gewechselt wird. Die GPU ist eine extrem parallele und auf maximalen Durchsatz (im Gegensatz zu minimaler Latency) optimierte Maschine und ein Pipeline Flush zählt mitunter zum schlimmsten, was man einer GPU antun kann...
Edit: Ok, das war wohl etwas zu dramatisch ausgedrückt. Wenn du Shader switchen musst, musst du Shader switchen, das lässt sich eh nicht vermeiden und wird einen nicht gleich umbringen. Aber es ist natürlich besser, das möglichst nicht ein paar hundert mal pro Frame zu machen. Aber das trifft eh auf praktisch allen State zu. Wie schlimm ein Shader Switch im Vergleich zum ändern der Daten in einem VBO ist, lässt sich, wie so vieles, nur mit "das hängt davon ab" beantworten. Der jeweilige Overhead ist potentiell sehr unterschiedlicher Natur und es macht imo jetzt nicht unbedingt Sinn, diese beiden Dinge direkt miteinander zu vergleichen. Oder findest du dich gerade in einer Situation, wo du einen direkten Trade-off zwischen Shaderswitches und VBO Uploads finden musst?
-
cooky451 schrieb:
OpenGL Calls sind halt einfach an sich verdammt langsam.
Das ist mir zu pauschal. Zwischen den versch. Funktionen gibts viele Unterschiede und nur wenige davon kan man als "verdammt langsam" bezeichnen. Als Beispiel kann man sich den VRAM mappen und so die Daten modifizieren. Ist schneller als sie nochmal zu senden.
