2017-08-13 4 views
0

Früher gab es eine Zeit, in der Leute sagten, dass das "Verwalten" der OpenGL-Staaten nützlich sei (siehe dazu einen Artikel aus dem Jahr 2001). Wie diese (C++):Ist es immer noch sinnvoll, OpenGL-Zustände zu cachen?

void CStateManager::setCulling(bool enabled) 
{ 
    if (m_culling != enabled) 
    { 
    m_culling = enabled; 
    if (m_culling) 
     glEnable(GL_CULL_FACE); 
    else 
     glDisable(GL_CULL_FACE); 
    } 
} 

kann ich sehen, dass dies in einer Situation immer noch nützlich sein, wenn die OpenGL-Server nicht auf der gleichen Stelle wie der OpenGL-Client ist. Aber das ist in meiner 'Spiel'-Engine sicherlich nicht der Fall, nehmen wir an, der OpenGL-Client befindet sich immer auf demselben Rechner wie der OpenGL-Server.

Ist es immer noch (es ist 2017) es wert, dass all diese Prüfcode-Zyklen dauern, anstatt immer nur den Treiber aufzurufen?

Man könnte sagen, dass ich es selbst profilieren sollte, aber ich denke nicht, dass die Ergebnisse von Bedeutung sein werden, weil es so viele verschiedene Grafikkarten, Treiber, CPUs, Betriebssysteme gibt, dass mein persönlicher Test nicht repräsentativ genug sein kann.

EDIT: Und wie über Dinge wie gebundene Puffer, Framebuffer, Texturen, ...

+3

Das hängt davon ab. Wenn Sie viele unnötige Anrufe tätigen, dann werden Sie davon profitieren. Aber am Ende wird es sich "abmessen". Das ist auch das einzige, was jemand anderes tun könnte. – BDL

+0

für Puffer können Sie auch Direct State Access Weg verwenden;) –

Antwort

2

ist es immer noch (es ist 2017 jetzt) ​​lohnt sich all diesen Prüfungscode zu haben nehmen Zyklen statt nur immer den Fahrer anrufen?

Sie sagen, dass, als ob es jemals "es wert" wäre. Es war nicht, und es ist immer noch nicht. Zumindest nicht in allgemein.

Status-Caching ist nützlich in den Fällen, in denen es zuvor war: wenn Sie keine direkte Kontrolle darüber haben, was vor sich geht.

Wenn Sie z. B. eine Game-Engine schreiben, wissen Sie genau, welche Rendering-Vorgänge Sie durchführen möchten und wann Sie diese durchführen möchten. Du weißt, dass all deine Meshes Gesichtskeulen verwenden werden, und du lässt deine Künstler/Tool-Pipeline dementsprechend damit umgehen. Sie könnten das Face Culling für GUI-Rendering oder ähnliches deaktivieren, aber das sind spezielle Fälle.

Wenn Sie hingegen ein verallgemeinertes Rendering-System schreiben, bei dem der Benutzer die totale Kontrolle über die Beschaffenheit von Meshes hat, kann das State-Caching hilfreich sein. Wenn Ihrem Code mitgeteilt wird, welche Meshes das Face Culling verwenden und welche nicht, haben Sie keine Kontrolle über diese Art von Dingen. Und da der Code/die Daten auf der höheren Ebene nicht direkt mit OpenGL kommunizieren können, können Sie einige State-Caching-Vorgänge durchführen, um die Dinge zu glätten.

Wenn Sie also kontrollieren, wie die Dinge gerendert werden, brauchen Sie keinen Cache, wenn Sie die allgemeine Art Ihrer Daten und die Art und Weise, wie sie gerendert werden, steuern. Ihr Code erledigt diesen Job angemessen. Und in guten datengesteuerten Designs können Sie das Rendern der Daten so anordnen, dass Sie immer noch keinen Cache benötigen. Sie brauchen nur eines in einem vollständigen Freilaufsystem, in dem die Außenwelt nahezu die totale Kontrolle über den gesamten Staat hat und wenig Rücksicht auf den Leistungseinfluss seiner Zustandsänderungen nimmt.

+0

Das macht sehr viel Sinn. Vielen Dank. Akzeptiert die Antwort, da ich denke, dass Sie völlig richtig sind. – scippie

Verwandte Themen