Hallo ihr da draußen ,

ist euch schon einmal aufgefallen, wieviel RAM OpenGL bei Programmen zustätzlich benötigt, wenn man nur das Grundgerüst einbindet (inkl. glClear und SwapBuffers, aber nichts dazwischen)? Sage und schreibe 6 MB zustätzlichen RAM benötigt das ganze zusätzlich. Wenn man dann noch 6 Linien zieht, merkt man das aber nicht so gravierend am RAM Verbrauch (17.300KB vs. 17.328KB; ohne OpenGL: 11.612KB).

Woran liegt der Ressourcenhunger und wie kann man den verringern (für 2D-Grafik benötige ich ja eigentlich nicht die komplette 3D-Fähigkeit )?

Ich würde gar nicht so viel Wert darauf legen. Mal ehrlich: die meisten haben 512MB oder fast schon 1024MB Arbeitsspeicher. Was machen da 6-7 MB mehr? Außerdem kann das u.U. auch an der Speicherverwaltung von Delphi liegen. Wenn man in Delphi Speicher reserviert und ihn dann wieder freigibt, wird nicht zwangsläufig der Speicher vom Deplhi-Memory-Manager auch wieder freigegeben sondern erstmal behalten um ihn wieder zu verwenden.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ich denke mal es sind mehrere Faktoren. Der Header von uns ist mit Sicherheit auch nicht ohne was das angeht. In der Demoszene werden die Programme so gebaut, dass sie nur genau das an Funktionen laden was auch wirklich benötigt wird. Dadurch kannst du natürlich einiges an speicher Sparen. Aber hast einen gehörigen Mehraufwand.

Außerdem ist OpenGL 2D = OpenGL 3D nur, dass Ansicht ein wenig anders ist. Das ist ja auch gerade der große Vorteil an OpenGL.

Ist Ansichtssache. Ich habe zwar 1048 MB RAM, aber das hat nicht jeder. Und wenn ich jetzt schon sehe, dass einer der beiden Speicherriegl nur von den Standardprogrammen schon vollständig voll ist, sollte man schon darauf achten dass auch nicht so Ressourcenhungrig Programme schreibt, wie es andere bereits genug sind (WMP9 mit Visualisierung=40 MB; FF >20MB; Thunderbird >20 MB ...), denn wenn alle Prozesse soviel benötigen würden (sind immerhin meistens an die 50) wäre vom 2. Riegel auch nichts mehr zu merken.


Das mag sein, aber dafür muss erst einmal OpenGL die belegen, bevor delphi die wieder freigeben kann .

[quote="Lossy eX"]In der Demoszene werden die Programme so gebaut, dass sie nur genau das an Funktionen laden was auch wirklich benötigt wird. Dadurch kannst du natürlich einiges an speicher Sparen. Aber hast einen gehörigen Mehraufwand.

Außerdem ist OpenGL 2D = OpenGL 3D nur, dass Ansicht ein wenig anders ist. Das ist ja auch gerade der große Vorteil an OpenGL.[/qoute]

Ich will ja eigentlich nur 2D (Schrift+Linien und evtl. Rechtecke). Wäre es nicht bald etwas für den nächsten OpenGL-Header, dass man die Grundfunktionen schon anbietet und so automatisch dann auch nicht zuviel Speicher genommen wird (also eine Erzeugungsprozedur für 3D und eine für 2D, wo weniger geladen werden muss)? Denn fast alle Grundgerüste sehen ja gleich aus. Und wenn man die nicht so haben will, kann man ja immernoch das Grundgerüst selber bauen. Das wäre auch für Einsteiger besser, da die dann nicht bereits am Grundgerüst scheitern (was einige schon bei den ersten Tutorials machen, da einige Beschreibungen nicht ganz hinhauen ).

Speicher: Na ja. Sofern du na ATI Grafikkarte und die neuen Treiber drauf hast werden immer mindest 40 Mb benutzt und solltest du das Symbol in der Taskleisten haben wollen kommen noch mal locker 20 MB hinzu. Der Startet nämlich 3 .NET Prozesse die jeweils 20 brauchen. Und das obwohl man es überhaupt nicht sieht. Und dass dann eine OpenGL Anwendung mal eben so "viel" Speicher haben will erscheit daneben nicht wirklich wichtig.

FF und TB. Da sage ich nur SeaMonkey zu. WMP9. Hmmm. Winamp ist recht schmal oder benutz den Media Player Classic. Der kann alles abspielen und ist richtig klein und schnell. Wie du siehst gibt es alleine von deiner Seite durchaus die Möglichkeit schon etwas am Speicherverbrauch zu tun.

Nur wirst du die anderen Herstellen nicht dazu bringen etwas einzusparen. Und wenn dein Programm anstelle von 7 MB dann nur noch 5 MB frisst macht es das auch nicht wirklich. Wenn du dann in deinem Programm eine ungünstige Struktur gewählt hast, dann verschleuderst du da wieder Speicher was nicht hätte sein müssen. Außerdem solltest du bedenken, dass Windows ungenutzten Speicher auslagert um so mehr physischen Speicher zu bekommen. Also auch wenn da 30 MB steht heißt es nicht, dass es auch 30 MB physischer Speicher sein müssen.

Header: Nein. Ich werde definitiv keinen 2ten Header bauen. Und in einen werden ich das auch nicht ein bauen. Dann kommen wieder die Fragen warum gibt es das denn nicht oder warum existieren denn da 2 überhaupt Header? Also das werde ich mir definitiv nicht antun. Und außerdem stellt sich dann die Frage wo hören Grundfunktionen auf und fangen Erweiterungen an. Alleine so etwas klären zu wollen würde unsägliche Probleme mit sich bringen. Da sehe ich also keinen Sinn drinn.

Für den Fall, dass du einen scmalen header haben möchtest solltest du dir die OpenGL.pas von Borland mal anschauen. Da sind nur ein paar Sachen drinne.

Nein, würden wir mehre Header auf den Markt schmeißen, gäbe es nur das große Chaos, welcher für welchen ist. Hat lange genug gedauert bis das ganze 1.0, 1.2, 1.4-Chaos im Griff ist. Der normale Anwender wird OpenGL stets mit allen Funktionen nützen wollen, der Teil, der diese nicht komplett braucht ist eher gering und spezialisierter. Auch vorsicht mit Speicherangaben. Schmeiße ich hier unter Linux ein größeres OpenGL-Programm an, zeigt er einen Verbrauch von 30 MB an. Ziehe ich davon dann die Bibliotheken ab, die im Hintergrund geladen werden (und shared im Speicher sind), bleiben noch rund 10 MB übrig. Das ist aus der heutigen Sicht alles anderes als viel. 256 MB sind Norma, viele haben bereits 1 GB drinne, Poweruser meist sogar schon mehr. Die ersten Spiele brauchen bereits 256 MB alleine in der Grafikkarte und die Spieler ziehen hinterher. Gleiches gilt auch für die Speicherverwaltung, die bei vielen Betriebssystemen schon sehr weit ist und wir ja schon lange keine OSe mehr haben, die ein Programm zwangsläufig komplett im Speicher halten müssen. Eine darstellende Anwendung mit 10 MB ist daher nicht viel, wenn ich bedenke, dass ich schon so manche TrayIcon gesehen habe, dass nichts anderes macht als Updates zu überprüfen und locker 30 MB verheizt. Ich weiss, für jene die in Zeiten groß geworden ist als man 64KB als technisches Wunder feierte ist die heutige Zeit oft hart

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Welches Symbol meinst du? (Ich habe ATI inkl 2 Monate altem Treiber ) Denn das ATI Catalyst Control habe ich deinstalliert, was sich unten mit eingeklingt hatte und das andere ATI-Symbol "überschrieben" hat (das Recheckige istdas vom Control Center und das mit dem transparenten Rand (wo nur die Schrift noch da ist) hat man, wenn man nur den Control Center noch oben hat).


Das der WMP9 soviel verbraucht stört mich nicht so, denn da kenne ich den Grund (die Visualisierung, wo sicherlich nen Haufen Variablen benötigt wird) und wenns einem stört, kann man diese abstellen und hat damit ein wesentlich Ressourcensparenderes WMP (ca 6 MB) vs. 12 MB WinAMP, wobei er noch nichtmal dabei etwas abspiel gegnüber dem WMP.


Wird man auch nicht hinbekommen, da die teilweise zu starken Druck von oben haben, um es soweit wie möglich zu optimieren. Aber man sollte auch Beispiele bringen, dass es auch anders geht .

@Header: Ok, war nur nen Vorschlag .

@Phobeus: Ich gehöre nicht der 64-K-Gruppe an, da ich erst seit nem Jahr messen kann, wieviel RAM ein Programm verbraucht (XP, vorher 95).

Hallo SunBlack,

also ich glaube das 6 bis 7 MB Arbeitsspeicherverbrauch ganz o.k. sind (obwohl bei mir kleine C-OpenGL-Programme 'nur' 3 bis 4 MB Arbeitsspeicher einnehmen).

Grade bei Grafikprogrammen sollte man immer mit erhöhtem Speicherverbrauch rechnen (ob nun mit oder ohne OpenGL, bedenke, ein einfaches unkomprimiertes 1024x768 Bild mit 24 Bit Farbtiefe würde im Speicher 1024x768x3 Byte = 2359296 Byte belegen, ohne solche Sachen wie z.B. doublebuffer, alphabuffer, depthbuffer oder stencilbuffer einzubeziehen)

Ausserdem gilt die Beziehung : mehr Hauptspeicher < = > weniger Zugriffe auf die Festplatte bzw. weniger im Prozessor berechnen und da es grade bei 3D-Programmen bzw. Grafikanwendungen um Geschwindigkeit geht, kann man eigentlich nie genug Daten im Hauptspeicher halten

Viele Grüße
dj3hut1

Symbol: Habe bisher immer das ControlPanel mit benutzt aber leider gibt es die neueren Treiber nur noch mit dem CCC. Aber ich meine direkt das vom CCC.

WMP: Okay. Ich persönlich nutze den MediaMonkey. Der benutzt 20 MB und hat eine sinnvolle Musikverwaltung (autotaggen von Amazon, autoumbenennen der Dateien) eingebaut. Eigentlich ist das Abspielen da nur nebensächlich. Und der ist in Pascal geschrieben worden.

Beispiel: Ja da hast du natürlich irgendwo recht. Aber es würde dich ja niemand daran hindern, wenn du dir den Header schnappst und alle nicht gewollten Extension etc. löscht und diesen dann benutzt. Aber irgendwo muss man ne Grundvorraussetzung festlegen. Das ist halt das absolute Minimum. Ich denke aber mal, dass man eher die Geschwindigkeit/Kompatibilität/Benutzerfreundlichkeit optimieren sollte. Auf keinen Fall sollte man die Speichernutzung vollkommen außer acht lassen aber heutzutage ist es eher so dass man Speicher opfert anstelle der Geschwindigkeit. Früher war es eher andersrum, da dort leider der Speicher begrenzt war. Und ich meine jetzt noch nicht mal die 64k. Das war auch ein bisschen vor meiner Zeit. Aber die 640k kenne ich auch noch sehr gut.

Das weiß ich, allerdings stört es mich, wenn man bei vielen Programmen sieht, wie verschwenderisch die mit Speicher umgehen für Variablen die man nicht benötigt bzw. extrem selten. Z.B. muss bei einem Spiel nicht das Hauptmenü ständig im RAM liegen, sondern kann meiner Meinung nach freigegeben werden, da dieses zu selten benötigt wird. Falls dass das Programm das jedoch drinnen lassen würde, würde zwar das Programm keine Verluste machen, aber wahrscheinlich das Betriebsystem, da es eine höhere Speicherverwaltung/-Ordnung mehr Aufwand hat und damit das Spiel gewissermaßen verlangsamt wird.

@CCC: Ich lade mir auch immer das Komplettpaket runter. Nach der Installation deinstalliere ich aber immer gleich das CCC, wobei der Rest aber aufm aktuellsten Stand bleibt (Teilprogramme die ich nicht brauche werden bei mir allgemein, wenn es möglich ist, deinstalliert, da unser verbuggtest XP aller 2 Monate ne fragmentierung von 15-20% hat ).

Wobei die in dem CCC auch Optimierungen für verschiedene Anwendungen drinne haben. Also Shaderreplacement etc. Von daher macht das leider schon einen ziemlichen Sinn. Bzw haben die da auch einen extremmodus eingebaut der so live alles untersucht. Was mitunter auch ziemlich nach hinten gehen kann.

Zu dem Header:
Jeder kann und darf ihn selber reduzieren, sodass eine reduzierte Variante nur die Faulheit einzelner Personen unterstützen würde.
Und da der Header schon genug Arbeit für Lossy und Lars darstellt, reicht die aktuelle Variante aus.

Natürlich habe ich mich auch geärgert, dass mit der letzten Version meine Dateien angeschwollen sind.
Denoch ist es vernachlässbar, weil ich es selber ja noch reduzieren kann, und ich sowieso auf keine spezielle Dateigrösse hinarbeite.


Du kannst bei der Installation auch direkt nur den Treiber installieren und das CCC weglassen. Die Option wird angeboten.
Oder du lädst direkt nur den Treiber ohne CCC runter

Ich vertraue lieber auf die Programmhersteller von den Produkten bei der Optimierung, anstatt dem Hersteller der GraKa für alle solche Programme.

@nochmal zum Header: Ich gehe hier eigentlich meistens davon aus, dass Delphi die Prozeduren die ich nicht benötige autom atisch entfernt, wes wegen ich die dglOpenGL.pas im Projektorder habe und immmer nur im implementation einbinde (da dort Delphi sich die Units noch mit anschaut, während im Interfacebereich er nur die DCUs nimmt ). Des wegen habe ich den Thread dann hier aufgemacht, da Delphi es ja eigentlich schon genug gekürzt haben um den Speicherbedarf zu minimieren .

@SunBlack,

stimmt, damit hast du eigentlich auch Recht.
Sachen, die nicht ständig gebraucht werden, wie z.B. ein Hauptmenü müssen wirklich nicht permanent im Hauptspeicher gehalten werden.
Ein Hauptmenü kann notfalls immer neu gerendert werden, da dieses, wenn es erst einmal erzeugt ist, mind. mehrere Sekunden lang 'bestehen' bleibt.
Und ob das Menü nun in 0.1 oder 0.5 Sekunden nach Aufruf erscheint, macht eigentlich auch keinen großen Unterschied.

Ich stehe zufälligerweise momentan vor einer ähnlichen Problemstellung :
Ich programmiere zur Zeit an einem 3D-Interface für Schach-Engines, die über das UCI-Protokoll kommunizieren. Beim Anklicken einer Schachfigur möchte ich dem Nutzer alle möglichen Züge mitteilen, die diese Figur machen kann.

Nun ist die Frage, ob ich bereits einmalig vor dem Zug für all meine Schachfiguren alle Möglichkeiten ausrechne oder immer wieder neu nach dem Anklicken der jeweiligen Figur.
Beide Möglichkeiten haben ihre Vor-und Nachteile.

Die erste würde mehr Speicher verbrauchen und etwas mehr Zeit, bevor der Spieler zu seinem Zug kommt. Dafür stehen dann aber die ausgerechneten Möglichkeiten sofort zur Verfügung und müssen nicht, anscheinend unsinnigerweise, mehrfach ausgerechnet werden (falls der Nutzer auf die Idee kommt, immer wieder auf die selbe Figur zu klicken).

Die zweite Möglichkeit, anscheinend unsinnigere Herangehensweise, hat den Vorteil nur das zu berechnen, was vom Anwender wirklich verlangt wird. Warum sollten alle Möglichkeiten vorberechnet werden, wenn der Nutzer sowieso nur ein oder zwei verschiedene Schachfiguren pro Zug anklickt? (was wahrscheinlich auch der Fall sein wird)

Also, falls man es schafft, das wahrscheinliche Verhalten des Anwenders gut vorauszusagen oder vorauszuahnen (was in vielen Fällen garnicht so schwer ist ) kann man bestimmt einiges an Ressourcen einsparen.

Es ist nur wirklich schade, das sich nicht alle Programmierer allzuviel Gedanken um z.B. den Hauptspeicherbedarf ihres Programmes machen sondern nur darum, wie schnell sie es fertig bekommen (Javaprogrammierer sind in dem Sinne die Schlimmsten )
Ich habe da schon merkwürdige Sachen gesehen : Hashmaps mit maximal vier Einträgen, Listen wo man auch Arrays hätte vewenden können, Programme die statt mit int-Werten nur noch mit Strings hantieren oder XML-Gerüste, wo auch einfache Konfigurationsdateien ausgereicht hätten... bei der heutigen Rechenleistung kann man da wirklich schnell in Vesuchung geraten.

Viele Grüße
dj3hut1

Das erinnert mich irgendwie an die (wahre) Aussage eines meiner Informatikprofessoren : Die meiste Zeit verbringt eine Anwendung damit, auf die Eingabe des Nutzers zu warten...

Normal hast du dabei vollkommen recht aber in diesem Falle kann Delphi daran nichts ändern. Da der Header nun mal dynamisch geladen wird muss delphi alle Methodenpointer und alle Variablen im Speicher halten. Wenn der Header so wie der Borland header statisch wäre, dann könnte delphi das rauslassen was es nicht brauchen würde. Allerdings ist das mit dn OpenGL Extensions (alles inklusive Kern über OpenGL 1.1) nicht vereinbar, da diese nur dynamisch geladen werden können. Allerdings wage ich mal zu bezweifeln, dass die gesammten 6-7 MB alleine vom Header stammen. Denke mal so max 1 MB. Der Rest wird wohl von OpenGL selbst bzw durch das laden der DLLs verbraten. Und das wäre ein Faktor der so oder so vorhanden wäre.