DocWindows: Alles, was sich nicht direkt auf die Rasterisierung und die Hintereinanderausführung der Shader Stages bezieht, muss man (jetzt mal im Falle von OpenGL, weil ich mich damit halbwegs auskenne) auch schon selbst machen. Und die beiden Punkte dürfte dir auch Mantle abnehmen.
Nehmen wir allein mal das Verändern einer Textur im Grafikspeicher. Wie macht man das am besten? Mit glTexSubImage2D direkt aus dem RAM? Nun, nein, das ist einfach unglaublich langsam. Auf meinem System komme ich auf die Art und Weise nicht einmal auf 100 Megapixel pro Sekunde.
Was kann man stattdessen machen? Zum Beispiel einen Puffer im Grafikspeicher erstellen, asynchron zum weiteren Rendering die Pixeldaten hineinschreiben (das kann man sogar in nem zweiten Thread erledigen), und irgendwann, wenn die Daten da sind, glTexSubImag2D aus dem Puffer lesen lassen. Performancemäßig liegen zwischen den zwei Methoden Welten.
Damit entzieht man dem Treiber auch nahezu jegliche Kontrolle, und das sogar explizit (GL_MAP_UNSYNCHRONIZED_BIT). Er übernimmt noch die Speicherverwaltung, ja.
Aber was auch nervt, ist, dass Texturen ihre Daten nicht
direkt aus Buffer Objects beziehen können. Man muss immer den Umweg über temporäres Buffer Object => Pixel kopieren gehen. Da wäre mehr direkte Kontrolle sogar wünschenswert.
Aber gilt das denn auch, wenn man davon ausgeht, dass praktisch kein Spiel Mantle-exklusiv entwickelt werden wird, sondern immer Mantle und Direct3D?
Wenn Mantle tatsächlich GCN-exklusiv wird und bleibt, dann wird das ganze ziemlich unattraktiv, ja. Technisch wäre das API aber durchaus zu begrüßen.