Archiv verlassen und diese Seite im Standarddesign anzeigen : sind 8 Renderpipelines NOTWENDIG für die Ausschöpfung eines 256bit DDR Interfaces??
robbitop
2002-09-19, 19:41:12
Überschrift sagt meine Frage...
wenn ja, warum?
ist ein 4 Pipe a 2 TMU Design nicht ähnlich effektiv wie ein 8x1 ??
Braucht man wirklich mind 8 Pipes damit 4 Vertexshader und 256bit DDR aufgehen??? Ist es das was der P512 das Rückrad brach (ein CBMC hatte der R200 auch nich und es schien ihm nich sonderlich "wehzutun")....auch wenn das bei 256bit DDR kritischer is
Exxtreme
2002-09-19, 20:01:22
Ey, üsch krass schüben ins konkrett korrekte Forum.
Gruß
Alex
GloomY
2002-09-19, 20:23:53
Ein 8x1 Design ist einem 4x2 imho schon überlegen, weil bei der Verwendung von Singletexturing (was ja bei transparenten Sachen wie z.B. dem "Blutnebel" in Q3A durchaus vorkommt) eben die doppelte Füllrate zur Verfügung steht.
Wenn es allerdings darum geht, möglichst viele Texturen in einem Pass aufzutragen, dann ist das 4x2 Modell sicher die bessere Wahl. Allerdings beherrschen die heutigen Chips alle Loop-Back, womit dieses Thema vom Tisch ist.
Ob man für 8 TMUs nun umbedingt ein 256 Bit DDR Speicherinterface braucht, ist imho nicht so einfach zu beantworten. Es kommt auch drauf an, wie effizient die vorhandene Bandbreite genutzt wird, bzw. wie viele Einsparungsmaßnahmen getroffen werden (Hyper-Z, LMA, Tiling usw.).
Wie wäre es denn mit 8 Pipeline die via Pipeline Combining zu 4x2 geschaltet werden könnten?
Pitchfork
2002-09-19, 21:35:39
Originally posted by aths
Wie wäre es denn mit 8 Pipeline die via Pipeline Combining zu 4x2 geschaltet werden könnten?
Mal ne ganz dumme Frage: was hat die Menschheit (bzw. die Grafikperformance) davon, 8x1 Pipes mit Loopback Fähigkeit zu 4x2 zu schalten? Irgendwelche Vorteile? Doch wohl nicht, weil selbst mit 4x2 braucht man Loopback. Man verkompliziert sich doch nur das Design.
Ausserdem haben tests doch gezeigt, dass die Radeon 9700 trotz 325 chiptakt eher füllraten und nich Bandbreitenlimitiert ist.
Ausserdem ist ein 8*1 system in jedem fall besser als eins mit 4*2, ersten wird teils noch singletexturing verwendet, zweitens kann der R300 16 texturen gleichzeitig auftragen, was in jedem fall langen sollte, und drittens wird eine höhere pixelshader leistung erreicht.
Das wird auch der grund sein weil alle zukünftigen designs eher mehr pixelpipes bekommen als mehrere TMUs.
Demirug
2002-09-19, 21:55:28
burk23,
das mit den 16 Texturen ist unabhängig von Pipeline Design. Es geht dabei nur um den Loopback. Die Pixelshader Leistung ist ebenfalls unabhängig von der Anzahl der Pipelines. Dort zählt nur die Anzahl der verfügbaren PS-Alus
Beim Singletexturing gebe ich dir recht. Hinzu kommen noch die 0-Textur passes (Z-Only, Stencil). In beiden Fällen zählt nur die Anzahl der Pipelines.
Originally posted by Demirug
burk23,
das mit den 16 Texturen ist unabhängig von Pipeline Design. Anzahl der Pipelines.
Das stimmt schon, aber imo sind 2 TMUs schon weniger effektiv als doppelte pipes, wenn schon 16 texturen per pass aufgetragen werden können. Erst wenn mehr als 16 textur schichten benutzt werden ist ein doppelt TMU design wieder im vorteil, weil dann wieder in einem pass die text. aufgetragen werden können. Bei allem unter 16 texturschichten ist ein "mehr" pipe design einfach besser, selbst wenn es mehr transistoren frisst.
Auch nicht zu vergessen, dass die GF4 bei AF die 2. TMU abschaltet und bei 8*1 pipes wäre bei AF einfach deutlich weniger leistungsverlust.
Und diese altlast wird beim NV30 bestimmt mitgeschleppt (wie auch sonst es ist ja schließlich NVidia), deshalb wird der NV30 auch warscheinlich mit 8*1 kommen, einfach weil heute ohne AF nix mehr zu holen ist.
zeckensack
2002-09-19, 22:32:15
Originally posted by burk23
Erst wenn mehr als 16 textur schichten benutzt werden ist ein doppelt TMU design wieder im vorteil, weil dann wieder in einem pass die text. aufgetragen werden können.Häh???
Wie kommst du auf 16?
Und überhaupt, eine TMU pro Pipe ist immer überlegen (sofern der Loopback 'for free' ist), weil flexibler.
*edit*
Meine Begründung dazu gibt's hier:
http://www.rage3d.com/board/showthread.php?postid=1331413309#post1331413309
Originally posted by zeckensack
Häh???
Wie kommst du auf 16?
Und überhaupt, eine TMU pro Pipe ist immer überlegen (sofern der Loopback 'for free' ist), weil flexibler.
Genau des hab ich doch auch gesagt! Du brauchst nicht immer was gegen meine posts nur aus prinzip zu sagen :P
Und falls du des mit den mehr als 16 textur schichten net verstehst, dann denk erst mal drüber nach bevor du rumspamst.
Demirug
2002-09-19, 22:38:49
ähm burk23 um ehrlich zu sein verstehe ich deinen Post auch nach mehrmaligem lesen nicht.
zeckensack hat schon recht das eine TMU pro Pipe bei gleicher gesamtzahl der TMUs immer besser ist (ausser wenn es um die Anzahl der Transitoren geht).
zeckensack
2002-09-19, 22:42:33
Originally posted by burk23
Genau des hab ich doch auch gesagt! Du brauchst nicht immer was gegen meine posts nur aus prinzip zu sagen :P
Und falls du des mit den mehr als 16 textur schichten net verstehst, dann denk erst mal drüber nach bevor du rumspamst. Die Frage steht: Wieso 16?
Nächste Frage: Wieso soll es überhaupt eine Zahl geben, ab der ein X*2-Design besser als ein X*1-Design wird?
Originally posted by Demirug
ähm burk23 um ehrlich zu sein verstehe ich deinen Post auch nach mehrmaligem lesen nicht.
zeckensack hat schon recht das eine TMU pro Pipe bei gleicher gesamtzahl der TMUs immer besser ist (ausser wenn es um die Anzahl der Transitoren geht).
Genau des hab ich versucht zu sagen, aber vielleicht hab ich mich net so doll ausgedrückt :eyes:, mir läuft des deutsch einfach noch net so, weil ich fast nur english spreche zur zeit, vielleicht ist mein ganzer post einfach zu verschachtelt ;)
Originally posted by zeckensack
Die Frage steht: Wieso 16?
Nächste Frage: Wieso soll es überhaupt eine Zahl geben, ab der ein X*2-Design besser als ein X*1-Design wird?
1) weil ab 16 texturschichten der R300 nicht mehr singlepass die texturen auftragen kann.
2) X*2 design nur besser als X*1 wenn X= konstant
Das habe ich auch nie bestritten.
P.S.: Sorry hab wohl ein bissle überreagiert bei meinem letzten post.
Ist wohl meine Schlud weil ich nicht alles so klar formuliert habe :eyes:
Desti
2002-09-20, 00:39:04
Originally posted by zeckensack
[...]
Nächste Frage: Wieso soll es überhaupt eine Zahl geben, ab der ein X*2-Design besser als ein X*1-Design wird?
Voodoo² ?
Originally posted by burk23
1) weil ab 16 texturschichten der R300 nicht mehr singlepass die texturen auftragen kann.
Na das ist aber eine Beschränkung des R300, nicht von 1-TMU-Architekturen allgemein. Außerdem wird das durch die Anzahl der Texturestage-State-Register beschränkt, und wenn die nur in 16facher Ausführung vorhanden sind, ändern auch mehr TMUs nichts daran, dass nur 16 Texturen pro Pass möglich sind.
Demirug
2002-09-20, 09:17:44
Xmas, was hat dich den da geritten?
Texturestage-State-Register sind eine DX7 Erfindung. Seit DX8 haben wir PS-ALUs und bei NVIDIA heisen die Teile schon immer Register Combinder. Aber in dem Zusammenhang ist die Nahmensgebung auch egal. Denn auch bei diesen Einheiten ist ein Loopback ohne Probleme möglich.
Die Frage die viel wichtiger ist wäre: "Über wieviele ALUs verfügen R300 und NV30 pro Pipe?" Die von ATI bisher veröffentlichten bilder lassen auf eine ALU pro Pipe schliessen. Das wäre in gewisser weise auch logisch da ja nur maximal ein TMU wert pro takt pro Pipe zu Verfügung steht. Mit mehr als einer ALU könnten zwar die nicht texturabhängingen Rechnungen beschleunigt werden nur würden diese bei den derzeitigen Pixelshader wohl oft untätig sein.
Da reden wir wohl aneinander vorbei, weil ich wohl den falschen Begriff verwendet hab. Ich meinte damit die Register für die Settings, die man pro "virtueller Textureinheit" setzt, nicht per Shader. Also z.B. welche Textur (Adresse im Speicher), Texturformat, Auflösung, Anzahl der Mipmaps, Filtermodus, Aniso-Settings, Wrap/Clamp/Mirror.
Demirug
2002-09-20, 10:46:05
OK was du meinst sind die Texturesampler und davon gibt es bei R300 und NV30 wie schon gesagt 16 Stück.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.