Das Problem bei Mipmapping, wenn Textur-Speicher knapp wird

[Matti]

Es geht hier zwar besonders um die Voodoo2/3, aber ich denke es paßt am besten ins Technologie-Forum:

Folgende Standatd-Situation auf meiner Voodoo3: der Textur-Speicher reicht nicht, und es müssen Texturen in den RAM ausgelagert werden. Wenn jetzt eine ausgelagerte Textur gebraucht wird, muß die gesamte Textur (incl. aller Mipmaps) in den Grafikkarten-Speicher zurückgeholt werden (die Voodoo kann ja kein AGP-Texturing), was bei meinem jetzigen Treiber auch so gemacht wird.

Besser wäre es natürlich, wenn man nur die gerade benötigten Mipmaps in den Grafikkarten-Speicher zurückholt. Nur in seltenen Fällen wird ja die Original-Textur gebraucht, meist kommen nur die 1.-3. Mipmap vor, die ja wesentlich kleiner als die Original-Textur sind.

Allerdings ist das im Treiber wahrscheinlich ziemlich aufwendig unzusetzen, denn die Entscheidung, welche Mipmap verwendet wird, macht ja die Grafik-Hardware und nicht der Treiber. Es wäre aber möglich, daß der Treiber vorher ausrechnet, welche Mipmaps gebraucht werden, und nur die wirklich benötigten in den Grafikkarten-Speicher zurückholt.


Gibt es schon einen Treiber, der das kann?

Würde diese Technologie überhaupt was bringen? - Wenn ja, ist das ein Aufruf an alle 3dfx-Treiber-Programmierer, das umzusetzen! ;)

[Gast]

IMHO;

können das nur 2; Der Flipper im Gamecube und ein/einige 3DLabs - Chips.

Beide machen das aber etwas anders. Sie zerteilen die Texturen in kleine Abschnitte 2KB(?) beim Flipper und 4KB bei den 3DLabs-Chips und laden immer nur diese kleinen gerade benötigten Teile einer Textur nach. Dadurch gibt es dann keine Aussetzer mehr, weil der Chip gerade wieder Texturen über den AGP-Bus laden muss, sondern der Bus wird gleichmäßig ausgelastet. Der Chip muss das ganze aber in Hardware beherrschen da sonst der Aufwand zu groß wird.

Mich wundert es jetzt aber, warum ATi sowas nicht bei seinen neueren 3D-Chips benutzt. Vor allem der IGP9100 würde sehr stark davon provitieren, oder???


Gast_Troll ;)

[Demirug]

Es bringt im Prinzip natürlich durchaus etwas nur die Mip-Maps einer Texture in den Grafikkarten speicher zu laden die wirklich gebraucht werden.

Damit es aber wirklich was bringt muss der Chip in der Lage sein damit umzugehen. Bei einer Voodoo gehe ich jetzt mal davon aus (keine Lust die Spec zu durchsuchen) das der Chip immer davon ausgeht das die Texture komplett im RAM liegt. Durch ein Teilweise laden würde man also bestenfalls etwas Bandbreite auf dem AGP/PCI Bus sparen können.

Der zweite Punkt ist das die CPU dann vor dem übergeben eines Polygons prüfen müsste welche Mip-Maps überhaupt gebraucht werden und diese bei Bedarf in den Chip laden. Der Treiber würde also CPU lastiger.

In Summe würde ich jetzt mal sagen das die Kosten höher als der Nutzen sind.

PS: Voodoos gehören in den Schrank oder die Glasvitrine aber nicht mehr in einen Rechner. ;)

[Exxtreme]

Original geschrieben von Gast
IMHO;

können das nur 2; Der Flipper im Gamecube und ein/einige 3DLabs - Chips.

Beide machen das aber etwas anders. Sie zerteilen die Texturen in kleine Abschnitte 2KB(?) beim Flipper und 4KB bei den 3DLabs-Chips und laden immer nur diese kleinen gerade benötigten Teile einer Textur nach. Dadurch gibt es dann keine Aussetzer mehr, weil der Chip gerade wieder Texturen über den AGP-Bus laden muss, sondern der Bus wird gleichmäßig ausgelastet. Der Chip muss das ganze aber in Hardware beherrschen da sonst der Aufwand zu groß wird.

Mich wundert es jetzt aber, warum ATi sowas nicht bei seinen neueren 3D-Chips benutzt. Vor allem der IGP9100 würde sehr stark davon provitieren, oder???


Gast_Troll ;)
Das nennt sich Virtual Texturing. Es erhöht auch die Effektivität von HSR. Die Texturteile, die verdeckt sind, werden auch nicht geladen.

Ich denke, daß VT ein nützliches Feature ist wenn man wenig Speicherplatz zur Verfügung hat.

[Demirug]

Original geschrieben von Gast
IMHO;

können das nur 2; Der Flipper im Gamecube und ein/einige 3DLabs - Chips.

Beide machen das aber etwas anders. Sie zerteilen die Texturen in kleine Abschnitte 2KB(?) beim Flipper und 4KB bei den 3DLabs-Chips und laden immer nur diese kleinen gerade benötigten Teile einer Textur nach. Dadurch gibt es dann keine Aussetzer mehr, weil der Chip gerade wieder Texturen über den AGP-Bus laden muss, sondern der Bus wird gleichmäßig ausgelastet. Der Chip muss das ganze aber in Hardware beherrschen da sonst der Aufwand zu groß wird.

Mich wundert es jetzt aber, warum ATi sowas nicht bei seinen neueren 3D-Chips benutzt. Vor allem der IGP9100 würde sehr stark davon provitieren, oder???


Gast_Troll ;)

SGI hat auch noch Systeme die sowas in der Art können.

Bei einem Grafikchip/Core der sich sowieso das RAM mit der CPU teilen muss bringt das nichts. Hätte der Chip/Core noch einen eigenen Speicher wäre die Sache sicherlich interesant.

[Matti]

Original geschrieben von Demirug
Der zweite Punkt ist das die CPU dann vor dem übergeben eines Polygons prüfen müsste welche Mip-Maps überhaupt gebraucht werden und diese bei Bedarf in den Chip laden. Der Treiber würde also CPU lastiger.


weil die Voodoo kein T&L hat, muß die CPU die 3D-2D-Umrechnung übernehmen, also kennt die CPU die Größe des Polygons auf dem Bildschirm sowieso schon. Und dann mit Hilfe der Textur-Größe die Mipmap auszurechnen, dürfte kein großer Aufwand sein...


Original geschrieben von Demirug
PS: Voodoos gehören in den Schrank oder die Glasvitrine aber nicht mehr in einen Rechner. ;)

Ich will mich aber nicht von meiner Voodoo trennen! Klar, ich könnte auch ne GF2MX reinpacken, aber dann hab ich mit meinem Analog-TFT sicherlich ein Sch***-Bild, weil das Ausgangs-Signal der alten NV-Karten (angeblich) ziemlich mies ist.

[Demirug]

Original geschrieben von Matti
weil die Voodoo kein T&L hat, muß die CPU die 3D-2D-Umrechnung übernehmen, also kennt die CPU die Größe des Polygons auf dem Bildschirm sowieso schon. Und dann mit Hilfe der Textur-Größe die Mipmap auszurechnen, dürfte kein großer Aufwand sein...

Ein Trisetup haben die Voodoos aber schon und genau diese Arbeit inkl ermitteln die benutzten Mip-Map Stufen müsste die CPU dann auch nochmal erledigen.

Ich will mich aber nicht von meiner Voodoo trennen! Klar, ich könnte auch ne GF2MX reinpacken, aber dann hab ich mit meinem Analog-TFT sicherlich ein Sch***-Bild, weil das Ausgangs-Signal der alten NV-Karten (angeblich) ziemlich mies ist.

Schneller wäre die GF2MX bestimmt und etwas kompatibler zu neueren Spielen bestimmt auch. Aber der grosse Spieler scheinst du ja sowieso nicht unbedingt zu sein. ;)

Bei den alten nv-Karten ist es durchaus ein Glückspiel mit dem Analogausgang.

[Matti]

Original geschrieben von Demirug
Schneller wäre die GF2MX bestimmt und etwas kompatibler zu neueren Spielen bestimmt auch. Aber der grosse Spieler scheinst du ja sowieso nicht unbedingt zu sein. ;)



Zocken kann ich bei nem Kumpel, der hat 2 Rechner im LAN und das macht mehr Spaß, als alleine zu Hause zu zocken :)

[LOCHFRASS]

GF2 MX ist wirklich nicht zu gebrauchen und je nach Game langsamer als eine Voodoo3, in UT ist das extrem, da kommt die V3 teilweise schon in GF2 Regionen.

Hat sich eigentlich was in Sachen HSR getan? Der Source Code ist ja schon länger öffentlich zugänglich. Damals wars bei mir in Q3 mit HSR fast schon gut spielbar, ~80 FPS mit demo001 und der V3 2k @ 183/183.

[Ailuros]

Damals wars bei mir in Q3 mit HSR fast schon gut spielbar, ~80 FPS mit demo001 und der V3 2k @ 183/183.

Bitte nicht schon wieder mit dem irrsinnigem Zeug. Software HSR ist zwar schon moeglich, aber das Ding war nie zur Veroeffentlichung geplant. Herr <censored> :D wollte die Gigapixel Kerle ver**schen.

Ganz ganz vereinfacht das Konzept dahinter war dass wenn das rendering zu lange dauert bei 60Hz, dass dann Geometrie einfach verworfen wird. Auf der V3 gabs selbst mit konservativen Einstellungen an manchen Stellen Artifakte. Da der voerwaehnte Herr heute bei NV arbeitet, wuerde es mich nicht wundern wenn er fuer so manche clipping planes verantwortlich ist LOL.

Spass beiseite: ich hab kein grosses Problem mit 16/22bits solange die Qualitaet gut ist. Aber heutzutage noch 256*256 grosse Texturen?

[zeckensack]

Original geschrieben von Matti
Besser wäre es natürlich, wenn man nur die gerade benötigten Mipmaps in den Grafikkarten-Speicher zurückholt. Nur in seltenen Fällen wird ja die Original-Textur gebraucht, meist kommen nur die 1.-3. Mipmap vor, die ja wesentlich kleiner als die Original-Textur sind.

Allerdings ist das im Treiber wahrscheinlich ziemlich aufwendig unzusetzen, denn die Entscheidung, welche Mipmap verwendet wird, macht ja die Grafik-Hardware und nicht der Treiber. Es wäre aber möglich, daß der Treiber vorher ausrechnet, welche Mipmaps gebraucht werden, und nur die wirklich benötigten in den Grafikkarten-Speicher zurückholt.Genau da liegt der Knackpunkt ;)

Moderne Grafik-APIs sind 'state machines', dh es wird unterschieden zwischen Konfiguration und Daten. Ersteres verändern die Art der Datenverarbeitung, letztere 'triggern' logischerweise diese Verarbeitung.

Um das ganze nun schnell zu bekommen, ist das ganze darauf optimiert, möglichst große Sätze von Daten durchzuschieben, bevor man die Konfiguration wieder ändert. Wir haben's logisch betrachtet mit einer wahnsinnig tiefen Pipeline zu tun, die bei Umkonfiguration ausgeleert werden muß.

Damit die Daten schnell da durchkommen, sind Daten-abhängige Anpassungen der Konfiguration strikt verboten. Andersrum betrachtet, wenn eine bestimmte Eigenschaft eines Dreiecks (eben zB "benutzt mip-level 1") die Konfig ändern könnte, dann müßte man die Pipeline ständig ausleeren. Anstatt wie aktuell möglich sorglos tausende von Dreiecken auf einen Schlag in die Pipeline stopfen zu können, wäre der Treiber ständig nur mit Umfüllen beschäftigt.

Schlimmer noch, nicht nur die Untersuchung der Geometriedaten auf die benutzten mips hin (die btw durchaus möglich ist) wird CPU-Last erzeugt, sondern eben auch durch die Umkonfiguration. In diesen Fällen werden CPU und Grafik nämlich idR 'synchronisiert', dh Parallel-Arbeit auf beiden Seiten des Zauns muß beendet und angehalten werden. Wärend die Hardware leerläuft, muß die CPU warten, denn erst wenn die Grafik-Pipeline leer ist, kann man wieder gefahrlos an den Texturspeicher gehen.

Bereits in der Grafik-Pipeline befindliche Geometrie kann ja beliebigen Texturspeicher referenzieren ... hoffentlich nicht gerade das Stück, das wir ändern wollen ;)

[micki]

die unreal jungs haben sowat in ihrer engine implementiert, weil in relation zur voodoo2 die tnt langsam beim textur upload war. Für weit entfernte objekte haben die extra speicher angelegt mit kleinen texturen.
(das scheint HL2 auch so zu machen, bei manchen scenen kann man erkennen wie die texturen switchen... oder liegt das am gepackten video? :D)

ist wohl auch das einfachste diese informationen mit einer engine vorzubereiten, dann müllt man den AGP speicher nicht voll mit größtenteils garnicht benötigten daten.

MfG
micki