PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : "Effektivere" Berechnug der Grafikkarten möglich?


Karümel
2003-05-07, 20:20:44
Öhm, zuerst muß ich mich entschuldigen, beim Titel des Topics ist mir leider nichts besseres eingefallen, sorry.

Ich habe folgende Frage: Gibt es eigentlich Verfahren, Methoden, Bauteile oder was auch immer die die Leistungsfähigkeit vom Grafikkarten oder GPU´s erhöhen, welche aber nicht auf dem Markt sind, da sie z.B. zu teuer, zu „experimentel“ oder sonstwas sind?
Zur Zeit ist es doch in den meißten Fällen so, das die Karten nur schneller werden indem der Takt hochgeschraubt wird, die PS/ VS mehrfach ausgelegt werden oder die Anzahl der Renderpieplines erhöht wird. Von den eigentlichen Grundzügen haben sich die Karten in den letzten Jahren ja nicht so verändert.
Aber gibt es eigentlich Technologien, also bestehende, die die Effeziens der Garten erhöhen würde, ohne das man z.B. den Takt erhöhen muß? Welche aber nicht von ATI oder Nvidia eingebaut werden (können), da z.B. eine andere Firma für diese Sache das Patent hat, oder man mit Einbau der Technologie die GPU praktisch von Null an wieder neu designen müßte. Ich meinte mal was gelesen zu haben, das man z.B. TBR nicht „einfach so“ in die GPU´s von NVidia oder ATI einbauen könnte, da man dann das Triangle.Setup komplett ändern müßte.



Puhhh, ich hoffe man versteht meine Frage?

MadManniMan
2003-05-08, 12:43:52
hm, mir persönlich fallen zwei elementare dinge ein...

einmal das bereits von dir benannte deferred(wichtig! weil die für die folgende abkürzung stehende technologie auch imediate geht) TBR, zum anderen embedded ram. ersteres benötigt wohl zu krasses redesign (aber ich hoff ja auf die PVR-series 5) und letzteres ist (noch) zu teuer.


demi?

zeckensack
2003-05-09, 16:45:18
"Bauteile" wohl eher nicht, aber effizienzsteigernde Konzepte gibt es trotzdem ;)

1)Caches. Klar. Texturcache, post transform vertex cache, FIFOs zwischen Trisetup und Pixel pipes, etc ...
2)Early Z. Spart mindestens Texturbandbreite (und Cacheverunreinigung) und ALU-Laufzeit, kann bei perfekter Implementierung auch echte Füllrate sparen.
3)Speicherzugriffe in (komprimierten) Tiles. Senkt den Verschnitt am Speichercontroller durch längere Bursts, ist aber nicht ganz trivial.
4)Hirarchical Z. Kann die verbrauchte Z-Bandbreite nochmals erheblich senken.
5)Multisampling+AF statt Supersampling. Dazu muß man hoffentlich nicht mehr viel sagen. Merke: Multisampling eröffnet weitere Ansatzpunkte für Kompression.
6)Schnelle Clear-Operationen. Anstatt einen 'Pixel Shader' konstante Werte ausspucken und in den Framebuffer schreiben zu lassen, kann man diese 'niedere' Tätigkeit auch dem Speichercontroller selbst auferlegen. Dadurch kann man die Begrenzung der maximalen theoretischen Füllrate durchbrechen.
7)Infinite Guardband clipping. Anstatt relativ aufwendiges und teures 'richtiges' Clipping zu machen (wobei faktisch Geometrieleistung vernichtet wird, wenn Objekte die Bildschirmkanten überlappen), kann man das auch im oder nach dem Triangle Setup auf Pixelbasis machen.

Demirug
2003-05-09, 17:28:59
Noch ein Zusatz zu dem Fast Clear und Compression.

Da man für den Kompressionsfall sowieso eine Zusatzinformation braucht kann man dort auch die Information gelöscht hinterlegen. Wird nun bei der Anforderung dieses Speicherblocks erkannt das dieser gelöscht wurde braucht man in nicht über die Speicherbus zu holen sondern füllt die Block mit dem zuletzt benutzten Löschwert. Diese Löschwerte (für Color Z und Stencil) brauchen ja nicht viel Platz und können ohne Probleme im Chip gepsichert werden.

Zum Löschen muss man dann nur noch die Blockzustandliste beschreiben.