buffern von opengl states
-
Ich könnte mir vorstellen dass der CPU seitige Overhead unter Umständen relevant werden könnte. Vor allem die glBind*() calls haben einen evtl. nicht zu vernachlässigbaren Overhead (nicht umsonst hat NVIDIA eine Extension entwickelt um ohne glBind*() arbeiten zu können). Was reine State Changes angeht so liest man aber eigentlich überall dass das heutzutage praktisch nichtmehr relevant ist (glGet() sowieso nicht, warum sollte das einen Flush verursachen, damit liest du doch nur CPU seitigen API State aus, natürlich gibts Function call Overhead, aber das ist denk ich mal klar). Lediglich Shader und Texture Switches können kosten, der Rest ist wohl eher vernachlässigbar. Viel wichtiger als redundante State Changes vermeiden ist heute wohl vernünftiges Batching. Wie immer bei solchen Dingen: Die Antwort hängt von deiner Anwendung ab, wenn dus genau wissen willst frag deinen Profiler...
-
treiber guarden state changes eigentlich nicht. Das problem ist auch nicht ein einziger state change mehr oder weniger, sondern wenn es ueberhaupt welche gibt.
Die GPU pipelines sind so aufgebaut, dass sie einen state haben und anhand dessen viele arbeiten vorllbringen koennen, ob dann die informationen in einem oder 10 drawcalls ankommen ist es egal, die pipeline arbeitet sie eh immer in der richtigen reihenfolge ab.
will man aber einen state wechseln, kann es sein, dass es einen pipeline flush gibt (also gewartet wird bis alles vorherige fertig ist), dann ein state umgesetzt wird und dann weiter gearbeitet wird.aus diesem grund, wenn man das letzte rausholen will, sollte man fuer states optimieren, aus ebenfalls diesem grund kann ein treiber programmierer davon ausgehen, dass er nicht selbst noch states guarden muss, weil ein faehiger programmierer auf der anderen seite das eh schon besser geloest hat.
welche states wie teuer sind haengt dabei stark von der hardware ab, bei mancher muss der treiber per hand caches flushen, bei mancher flushen ganz harmlos aussehende states die ganze gpu, etc.
