Hitraten von Texturcaches

[Quasar]

Ich bin gerade dabei, mit meinem Laienverständnis ein wenig herumzurechnen, bezüglich der Füllraten und deren Einschränkung durch mangelnde Bandbreite beim nV40.

nV selbst gibt an, 12,27 Pixel pro Takt erzeugen/versorgen zu können, was also bei einer Textur ~4900MPix pro Sekunde entsprächen.

Um meiner Überlegung ein klein wenig Praxisbezug zu geben, wollte ich keinen rein synthetischen Füllratentester bemühen und habe mich für den Villagemark entschieden.

Dieser nutzt drei Texturschichten, soweit mir bekannt ist, d.h., eine 4x2-Architektur (nV38) könnte hier mit trilinearer Filterung vier Pixel nach drei Takten ausgespuckt haben, bzw. bei bilinearem Filter vier Pixel nach zwei Takten.

Eine ansonsten (erstmal theoretisch) gleiche 16x1 Architektur (nV40) müsste nach 3 Takten 16 bilineare Pixel auswerfen oder nach sechs Takten 16 Trilineare.

Auf dieselbe Anzahl von Takten gebracht, hätten wir nach sechs Takten auf der 4x2-Architektur 12 bi- und 8 trilinear gefilterte Pixel. Die 16-Pipe Architektur käme auf 32 Bi- und 16 Trilineare.

Das Verhältnis zugunsten der 16-Pipe-Architektur wäre bei bilinearem Filter also 2,666:1, bei trilinearer Filterung nur noch 2:1.
Taktnormalisiert in Bezug auf nV38 und nV40 ergäben sich da 125% bzw. 68% Vorsprung.

Nun kommt aber, egal ob mit Multisampling oder ohne, der nV40 auch mit voll-trilinearer Filterung ggü. der reduziert-trilinearen des nV38 und erst recht bei rein bilinearer Filterung auf deutlich höhere Werte, als es rein rechnerisch der Fall wäre.

An eine Limitierung des nV38 durch die Bandbreite glaube ich nicht - ohne MSAA kommt der nV30 auf höhere Werte.

IMHO bleibt also die Möglichkeit, daß entweder das HSR, welches bei diesem Test natürlich auch eine Rolle spielt, verbessert worden ist, oder, was ich aufgrund der Tatsache, daß nV nicht mit verbessertem HSR geworben hat, eine größere Effizienz der Texturcaches beim NV40 zum Tragen.

- Ist es richtig, daß der Texturcache bei modernen GPUs pro TMU oder zumindest pro Pipeline angelegt ist? (Ich weiß, daß der NV40 mit einem zweistufigen Cache beworben wurde)
- Ist es auch richtig, daß die Hitraten dieser Texturcaches, wenn sie denn pro Pipelines angelegt sind, bei Einzelnen TMUs effektiver sind, als bei doppelt angelegten?

edit:
Rechnung korrigiert THX@zecki

[Demirug]

Der Aufbau der Caches hängt stark von der Architektur ab. Ein Chip der Quads rendert wird auch auf Quad Ebene oder grösser einen Cache haben. Bei einem Chip wie dem P10 der ja pro Pipeline eine Tile verarbeitet und daher wirklich unabhängige Pipes hat macht ein Cache auf Pipeline ebene Sinn. Allerdings ist auf jeden Fall ein globaler Cache für den gesamten Chip anzuraten.

Das HSR beim NV40 wurde zwangsläufig verbessert weil dieser ja jetzt mehr Pixel/Takt erzeugen kann.

[Blutgrätsche]

1) Gehen wir vom einfachsten Fall aus: bilineare Filterung, also 4 Texturaddressen * 16 Pixel/Pipeline = 64 Texturaddressen pro Takt.

2) Zwei Caches: Der L2 Cache beschafft sich fehlende Daten (L2-Cache-Miss) extern und beansprucht somit externe Bandbreite. Der L1 Cache holt fehlende Daten (L1-Cache-Miss) aus dem internen L2 Cache und beansprucht somit nur interne Bandbreite.

Es sollte klar sein, dass bei zu vielen Cache-Misses jeder Chip extra Takte drehen muss. Im schlechtesten Extremfall sind es 64 unterschiedliche Texturaddressen (64 Misses), im besten Extremfall 64 identische Texturadressen (1 Miss). Es ist nicht sonderlich vorteilhaft einen Cache pro Pipeline (schlimm) oder pro Quad (schon viel besser) zu implementieren, da man damit den entscheidenen Vorteil - identische Texturaddressen - verschenkt (was nicht heisst, dass man es nicht trotzdem so machen könnte, insbesonders im Hinblick auf Verzweigungen). Es bleibt also die Frage, wieviele Misses der Chip in einem Takt ohne Performance-Verlust vertragen kann. Und diese Frage lässt sich leider nicht ohne konkrete Architektur-Kenntnisse beantworten.

Die Grösse der Caches ist nur einer von vielen Faktoren, um einen Performance-Verlust zu vermeiden. NV ist mit einer L2-Hitrate von >80% zufrieden. Letztendlich ist die Anzahl und Verteilung der (erkannten) unterscheidlichen Adressen der bestimmende Faktor. Und damit lässt sich nun auch teilweise deine 2. Frage beantworten. Eine 16x1 Architektur ist (bei bilinearer Filterung) potentiell effizienter als eine 8x2 Architektur, weil unterschiedliche Texturen niemals eine identische Adresse besitzen können.

Trilineare Filterung habe ich nicht erörtert. Kann jemand anderes machen :)

[zeckensack]

Original geschrieben von Quasar
- Ist es richtig, daß der Texturcache bei modernen GPUs pro TMU oder zumindest pro Pipeline angelegt ist? (Ich weiß, daß der NV40 mit einem zweistufigen Cache beworben wurde)
- Ist es auch richtig, daß die Hitraten dieser Texturcaches, wenn sie denn pro Pipelines angelegt sind, bei Einzelnen TMUs effektiver sind, als bei doppelt angelegten? Der beworbene L1-T-Cache im NV40 ist - wenn es ihn überhaupt gibt, denn das ist messtechnisch nicht belegbar - IMO nicht performancerelevant, sondern vereinfachte nur das Design. Ich habe das mal mit aths ausdiskutiert (er hat Messwerte einer ganz speziellen ArchMark-Version erhalten).

Texturcaches nutzen sinnvollerweise die Lokalität benachbarter Pipelines aus, dh sie wirken eigentlich nur deswegen, weil, wenn für ein Sample einige Texel aus dem externen Speicher geholt werden müssen, auch die benachbarten Samples einen Teil dieser Texel benötigen.

Es ist bei derzeitigen Cachegrössen unvermeidbar, dass der Texturcache regelmässig umgefüllt werden muss. Es ist in praktischen Szenarien einfach nicht möglich, die Texel so lange vorzuhalten bis sie richtiggehend "später nochmal" gebraucht werden. Das steht im Kontrast zu "gleich nochmal, nämlich direkt daneben".

Von daher halte ich es für ziemlich unsinnig, pro Pixelpipeline einen separaten Cache zu haben. Der Gewinn durch die Texel-Überschneidung mit den benachbarten Pipes wäre dann verloren. Und wenn man den nicht mehr hat, bringt ein T-Cache einfach nichts mehr.

Man könnte jetzt sinnieren, ob ein Cache pro Quad-Pipe nützlich wäre oder nicht, und wie dependent reads die Lokalität beeinflussen würden, etc. Um es mal ganz kurz zu machen: IMO ist auch das nicht sinnvoll, denn Textur-Sampling jedweder Art hat genau so lange eine gute Lokalität, wie das Ergebnis kein Texturaliasing aufweist.

Hier zu optimieren hiesse auf die Anforderungen von im Grunde kaputter Software, respektive auf "hässliche" Ergebnisse zu optimieren.

Es gibt noch eine andere Möglichkeit, die Effizienz von Texturcaching zu steigern, nämlich die Pixel-Quads nicht in loser Reihenfolge abzuarbeiten, sondern so umzusortieren, dass die T-Cache-Hits maximiert werden. Das erfordert einige Arbeit am Rasterizer, und selbst dann ist es nur bei sehr grossen Dreiecken gangbar. Will man einen Gewinn über mehrere Dreiecke erzielen (Strips, Fans, etc), nähert man sich dem Terrain von deffered rendering.

Das ist IMO auch wieder eine Sache, die zwar grundsätzlich machbar ist, aber an den Anforderungen von Software vorbeigeht. Innerhalb eines IMR-Designs steht der zu erwartende Performancegewinn einfach in keinem gesunden Verhältnis zum Aufwand.



Btw, IMO ist deine Rechnung zu Beginn falsch, aber das Ergebnis ist richtig :|
Original geschrieben von Quasar
<..> für den Villagemark entschieden.

Dieser nutzt drei Texturschichten, soweit mir bekannt ist, d.h., eine 4x2-Architektur (nV38) könnte hier mit trilinearer Filterung vier Pixel nach zwei Takten ausgespuckt haben, bzw. bei bilinearem Filter acht Pixel nach zwei Takten.Tri: 4 Pixel nach drei Takten. Bi: 4 Pixel nach zwei Takten, bzw 8 Pixel nach vier Takten.
Eine ansonsten (erstmal theoretisch) gleiche 16x1 Architektur (nV40) müsste nach 3 Takten 16 bilineare Pixel auswerfen oder nach sechs Takten 16 Trilineare.

Auf dieselbe Anzahl von Takten gebracht, hätten wir nach sechs Takten auf der 4x2-Architektur 12 bi- und 8 trilinear gefilterte Pixel. Die 16-Pipe Architektur käme auf 32 Bi- und 16 Trilineare.Hmmm ... hier stimmt dann wieder alles :D

[Quasar]

Danke für die Erläuterungen bis hierher!


@Demi:
Daß die Anzahl der verworfenen Pixel sich durch die Anzahl der Pipes erhöht - ok. Aber deutet noch etwas darauf hin, daß auch die Effizienz der einzelnen Pipe erhöht wurde?

@Blutgrätsche:
Der Vorteil, den ich momentan noch bei einem Cache pro Pipeline (zusätzlich zu einem globale(re)n L2 auf Quadbasis oder auch auf der Gesamtheit der Pixelpipes, sehe, wäre der, daß bei Looping (davon gehe ich mal aus) für trilineare Filterung, was ja eigentlich der Mindest-Standard heutzutage ist, die Hitchance für das zusätzliche Sampling IMO deutlich ansteigt.

@Zecki:
Mein Rechenfehler ist eigentlich ein Schreibfehler. Auf meinem Zettel steht's noch richtig... deswegen kam am Ende auch das korrekte Ergebnis raus. Ich habe das ein paarmal umgeschrieben. Trotzdem danke für den Hinweis.

Wie hast du versucht, den L1 zu lokalisieren bzw. zu isolieren (s.O. meine Vermutung in Bezug auf Blutgrätsche's Posting)?
Was ist, wenn der nur für trilineare Filterung wirklich sinnvoll einzusetzen ist? (Das würde i.Ü. bestätigt durch die Tatsache, daß auch im Villagemark der NV40 durch rein-trilineares filtern gegenüber dem "neuen Standardn" *würg* nur ~11% verliert, der nV35 dagegen über >15%)

[Demirug]

Original geschrieben von Quasar
Danke für die Erläuterungen bis hierher!


@Demi:
Daß die Anzahl der verworfenen Pixel sich durch die Anzahl der Pipes erhöht - ok. Aber deutet noch etwas darauf hin, daß auch die Effizienz der einzelnen Pipe erhöht wurde?

Ich meinte im Verhältniss zur Filterleistung. Die Texel-Fillrate hat sich pro Takt ja verdoppelt aber die HSR-Fillrate vervierfacht.

[zeckensack]

Original geschrieben von Quasar
@Zecki:
Mein Rechenfehler ist eigentlich ein Schreibfehler. Auf meinem Zettel steht's noch richtig... deswegen kam am Ende auch das korrekte Ergebnis raus. Ich habe das ein paarmal umgeschrieben. Trotzdem danke für den Hinweis.

Wie hast du versucht, den L1 zu lokalisieren bzw. zu isolieren (s.O. meine Vermutung in Bezug auf Blutgrätsche's Posting)?
Schnüpp:
________________
Texture cache test

This test creates two mipmapped textures, 256x256 and 256x128 texels in size, and applies them to a fullscreen quad with varying zoom. The textures use a bilinear mipmap filter and the texture coordinates are carefully selected so that only specific mipmap levels of known size are required for rendering the surface. Only one texture is applied at a time. The second one is required to avoid non-uniform texture zooms.

Because running out of texture cache is signified by incresing bandwidth load, ArchMark puts a burden on bandwidth by applying the same bag of tricks already used in the bandwidth test: 32 bpp with z and stencil, blending, depth test, depth writes, stencil test and stencil writes. This way it can more easily be detected when texture fetches start going to external memory.
______________________
Die Texturen sind mittlerweile aber grösser (1024x1024), weil wir mit einem sehr grossen T-Cache gerechnet hatten.
Was ist, wenn der nur für trilineare Filterung wirklich sinnvoll einzusetzen ist? (Das würde i.Ü. bestätigt durch die Tatsache, daß auch im Villagemark der NV40 durch rein-trilineares filtern gegenüber dem "neuen Standardn" *würg* nur ~11% verliert, der nV35 dagegen über >15%) Der NV40 hat einfach doppelt soviel Texturcache wie der NV38 (8kiB vs 4kiB).

Darüberhinaus kann er nun auch DXT-Formate vernünftig cachen. Das ist möglicherweise das Resultat, und die eigentliche Motivation des zweistufigen Caches.

Das ganze ist ein Implementationsdetail, was IMO eigentlich niemanden interessieren muss. Es sieht aus wie 8kiB, es riecht wie 8kiB, es schmeckt wie 8kiB, es performt wie 8kiB. Genau wie beim R300. Nur dass sich dort niemand den Kopf zerbricht über die Cache-Architektur ;)

Die Geschichte mit dem mehrstufigen Cache-Design ist IMO eher irreführend denn nützlich.

[ram]

Original geschrieben von zeckensack
Die Texturen sind mittlerweile aber grösser (1024x1024), weil wir mit einem sehr grossen T-Cache gerechnet hatten.
Der NV40 hat einfach doppelt soviel Texturcache wie der NV38 (8kiB vs 4kiB).

Darüberhinaus kann er nun auch DXT-Formate vernünftig cachen. Das ist möglicherweise das Resultat, und die eigentliche Motivation des zweistufigen Caches.


Du meinst, dass der L1 weiterhin nur unkomprimierte Texel cached, der L2 aber auch komprimierte Daten halten kann?

[Blutgrätsche]

Wegem dem 2-stufigen Cache: So einfach lasse ich mich von Zeckensack nun auch nicht überfahren.:bäh:

Ein etwas übersehenes Problem ist die Umwandlung der Texturdaten in ein Filter-kompatibles Format (beim NV40 FP16). Hierbei besonders interessant ist die aufwändige Dekomprimierung (DXT-Dekodierung, also 4x4 Texelblöcke). Im Groben gibt es 3 Ansätze:
1. Ein einziger filter-inkompatibler Cache: Die Daten werden komprimiert gespeichert und bei Bedarf immer wieder "on-the-fly" dekomprimiert.
2. Ein einziger filter-kompatibler Cache: Die Daten werden beim Einlesen immer sofort einmalig dekomprimiert.
3. Ein 2-Stufen Cache: Der L2 Cache speichert die komprimierten Daten, der L1 Cache dekomprimierte Daten.

Ansatz 1 erfordert IMO mehr Dekomprimierer und ggf. Read-Ports und Crossbars.
Ansatz 2 erfordert einen wesentlich grösseren Cache.
Ansatz 3 erfordert eine komplexeren Cache-Controller und ggf. mehr Speicher für den L1 Cache.

Wie Zeckensack bereits schrieb war beim NV38 offensichtlich weniger die Hitrate/Bandbreite/Cachegrösse das Problem, sondern die Dekompression.

Einen Textur-Cache (eigentlich hier eher ein Zwischenspeicher) braucht man zunächst (wie bereits beschrieben), um identische Nachbar-Texel pro Takt effizient zu behandeln. Einen echten, voll ausgebauten Cache braucht man IMO dagegen vor allem, um (benachbarte) Texturblöcke nicht immer wieder neu anzufordern. Hier macht sich dann auch der grössere L2 Cache des NV40 bemerkbar. Ebenso nützlich ist ein grösserer L2-Cache natürlich für verschiedene Texturen, trilineare/anisotrophe Filterung und Dependent-Texture-Reads. Für die Performance bei trilinearer/anisotropher Filterung ist aber in erster Linie die Filter-Logik verantwortlich und weniger das Cache-Design.

[zeckensack]

Original geschrieben von ram
Du meinst, dass der L1 weiterhin nur unkomprimierte Texel cached, der L2 aber auch komprimierte Daten halten kann? Genau.

[GloomY]

Hat man denn bei Texture-Caches nicht auch noch eine gewisse temporäre Lokalität, wenn z.B. die gleiche Textur auf mehreren Poligonen verwendet wird? Normalerweise ist doch z.B. die Bodentextur immer die gleiche, die sich vom "Standort" bis zum Horizont erstreckt?

edit: :bonk: Blödsinn. Das sind natürlich unterschiedliche Mip-Maps und damit andere Daten.

[zeckensack]

Original geschrieben von GloomY
Hat man denn bei Texture-Caches nicht auch noch eine gewisse temporäre Lokalität, wenn z.B. die gleiche Textur auf mehreren Poligonen verwendet wird? Normalerweise ist doch z.B. die Bodentextur immer die gleiche, die sich vom "Standort" bis zum Horizont erstreckt?

edit: :bonk: Blödsinn. Das sind natürlich unterschiedliche Mip-Maps und damit andere Daten. So blödsinnig ist das garnicht :)

Das sind nur dann unterschiedliche Mipmaps, wenn gerade eine LOD-Grenze überschritten wird.

Das ist so ähnlich wie mit der "Kompression" von Multisampling-Buffern ... Effizienz geht an den Kanten verloren, aber die Kanten machen nur einen sehr geringen Teil des Bildes aus.

Nur dass in dem Fall die Kanten eben keine Polygonkanten sind, sondern die Übergänge zwischen zwei Mipmap-Levels. Selbst eine 2048x2048-Textur hat nur 12 Levels, insofern ist das wirklich kein Grund zur Sorge. Beim trilinearen Filter laufen dann btw einfach zwei Mip-Levels parallel, ansonsten spielt das keine grosse Rolle ob bilinear oder trilinear.

[ram]

Original geschrieben von zeckensack
Genau.

Ich würde nun vermuten, dass der "L1 Cache" beim NV40 einfach die vier grad benötigten Texel pro TMU speichert und die 8 KB des L2 für alle Pipelines genutzt wird. Gibt es denn Hinweise, dass der L1 oder der L2 pro Quad zur Verfügung steht?

Werden der Shader-Code nun eigentlich auch im L2 abgelegt wie mal von Demi angesprochen?

[aths]

Original geschrieben von ram
Du meinst, dass der L1 weiterhin nur unkomprimierte Texel cached, der L2 aber auch komprimierte Daten halten kann? Das hat NV so gesagt, ja. Über die Cache-Größen wollten sie dann nicht mehr reden, ich bekam ein Grinsen und "You will find out." Ich hoffe, dass zeckensack mal einen NV40 zum Spielen bekommt =) und sein Archmark die Details liefert.

[GloomY]

Zeckensack,

Wie du schon richtig sagtest, müssen die Texturcaches oft umgefüllt werden, da diese ziemlich klein (und die zu cachenden Daten groß) sind. Damit sinkt automatisch die Hitrate auf Grund von temporärer Lokalität. Die Daten bleiben einfach nicht lang genug im Cache, um von einem anderen Dreieck wieder benutzt zu werden (meist irgendein LRU-ähnlicher Rauschmeisser-Algorithmus ;) )

Das ist ähnlich wie beim P4 Celeron: Die Zugriffe von Programmen haben teilweise eine recht gute temporäre Lokalität, aber der Cache ist einfach zu klein. Damit werden automatisch nach und nach wieder einzelne Daten rausgeworfen, die später doch nochmal gebraucht werden.
Solange genug Speicherbandbreite da ist (wie bei einem Grafikchip), ist das aber nicht so schlimm.
Original geschrieben von zeckensack
So blödsinnig ist das garnicht :)

Das sind nur dann unterschiedliche Mipmaps, wenn gerade eine LOD-Grenze überschritten wird.Das mag sein, aber temporäre Lokalität beschreibt das Wiederverwenden nach einer gewissen Zeit. Die Wahrscheinlichkeit, dass ein anderes Dreieck nach einiger Zeit gerendert wird, welches exakt die gleiche Textur (und die gleiche Mip-Map) verwendet wie ein vorheriges und diese Daten sich dann noch im Textur-Cache befinden, ist einfach nicht sehr groß (s.o.).

Vergleiche das mal mit der temporären Lokalität bei einer CPU: Wie viele Dreiecke gibt es, die die gleiche Textur und die gleiche Mip-Map benutzen? 10? 100? Vielleicht 1000? Bei einem Programm innerhalb einer CPU kann es sein, dass durch eine Schleife 10000000 Mal auf die gleiche Variable zugegriffen wird. Der Unterschied sollte klar sein... :)

Temporäre Lokalität ist bei Texturzugriffen nicht sehr ausgeprägt, wohl aber die erwähnte räumliche Lokalität ("gleich nochmal, nämlich direkt daneben" ;) ). Diese ist im Allgemeinen bei Grafikchips deutlich besser, da der Rasterizer ja Zeilenweise arbeitet, also immer benachbarte Pixel bearbeitet (Ich hoffe ich liege hier richtig; wie war das mit den "Quads" :???: )

[Blutgrätsche]

Original geschrieben von ram
Ich würde nun vermuten, dass der "L1 Cache" beim NV40 einfach die vier grad benötigten Texel pro TMU speichert und die 8 KB des L2 für alle Pipelines genutzt wird. Gibt es denn Hinweise, dass der L2 oder der L2 pro Quad zur Verfügung steht?

Werden der Shader-Code nun eigentlich auch im L2 abgelegt wie mal von Demi angesprochen?
Als du das geschrieben hast, kannst du weder Zeit zum Nachdenken gehabt haben noch (Selbst-)Vertrauen in deine eigene(s) Argumentation bzw. Wissen. Passiert mir auch gelegentlich, wenn ich verwirrt bin und jeden Unsinn mit minimaler Wahrscheinlichkeit für möglich halte, um verzweifelt Klarheit zu bekommen.

Da der L1 dekomprimierte DXT-Daten speichert, ist der L1 Cache notwendigerweise mindestens 4x4 Texel gross und nicht TMU (pro Pipe) gesteuert.

L2 pro Quad macht wie gesagt (noch?) wenig Sinn. Wer im Pixelshader in einer if-then-else Anweisung unbedingt unterschiedliche Texturen benutzen will, muss halt mit einem Performance-Verlust rechnen. Auch bei deutlich unterschiedlichen Befehlslängen in der If-then-else Anweisung und anschliessendem Texturezugriff werden sehr wahrscheinlich beider Pfade erst durchlaufen und die Texel dann gemeinsam in einem Rutsch ausgelesen.

Warum sollte man Shader-Code im Texture-Cache ablegen? Und warum braucht man einen Cache für Shader? Reicht nicht einfach ein Double-Buffer (aktiver Shader, nächster ladener Shader)?

[ram]

Original geschrieben von Blutgrätsche
[...blabla...]
Da der L1 dekomprimierte DXT-Daten speichert, ist der L1 Cache notwendigerweise mindestens 4x4 Texel gross und nicht TMU (pro Pipe) gesteuert.

Guter Punkt.

Warum sollte man Shader-Code im Texture-Cache ablegen? Und warum braucht man einen Cache für Shader? Reicht nicht einfach ein Double-Buffer (aktiver Shader, nächster ladener Shader)? [/SIZE]

Das war ein Gedanke, der Demi mal in die Runde geworfen hat:

http://www.3dcenter.de/artikel/cinefx/index7.php

Möglicherweise ist das auch der Grund, warum nVidia den Pixelshadercode im RAM der Grafikkarte speichert. Über den breiteren Datenbus lässt sich ein Programm viel schneller einladen. Hierzu noch ein kleines interessantes Detail: Zum Einladen von Pixelshaderprogrammen wird die bereits über die TMUs vorhandene Verbindung der Pixelpipeline zum Speicher benutzt. nVidia wollte scheinbar für diese relative selten durchgeführte Operation des Programmwechsels keine eigene Einheit verbauen, um Transitoren zu sparen. Interessant dabei ist sicherlich noch die Frage, ob der Texturencache auch für Pixelshaderprogramme benutzt wird.

[Blutgrätsche]

Da das Speicherinterface eine gemeinsam genutzte Resource ist, bietet sich eine Mehrfachnutzung von Bussen oder Leitungen automatisch an. Shader im Video-RAM zu speichern ist ebenfalls relativ naheliegend. (Mehr fällt mir dazu nicht ein.)