gpus verbraten bald 120w?

[Unregistered]

http://www.xbitlabs.com/news/video/display/20030320043812.html

haben die einen an der Waffel?

falls schon ein thread zu diesem Thema existiert bitte closen. (hab jetzt nichts dazu gefunden)

[zeckensack]

Ich hab's auch gestern gesehen, und mit Verlaub, NVIDIA hat sie nicht mehr alle wenn das ernst gemeint sein soll :|

[Richthofen]

ich denke eher sie bilden den technischen Fortschritt bei GPUs auf die Fertitungsmöglichkeiten ab.

Da die Technik momentan der Fertigung voll wegrennt, ist es doch nur logisch, dass es dazu kommen wird. Da wird man sich einiges an Kühlmethoden einfallen lassen müssen.

Das hat nix damit zu tun, dass sie se nicht mehr alle haben, sondern dass sie der Ansicht sind, dass weder TSMC noch UMC noch irgendein anderer das liefern kann was benötigt wird, wenn man das Tempo ungefähr beibehalten will.
Also alle 18 Monate ein neu Design mit doppelt so vielen Transistoren.

[Lost Prophet]

das führt dann dazu das solche karten nur noch mit lüftern betrieben werden können die gleich in die ersten 2 pci steckplätze mit reingesteckt werden (simultan mit der karte, da sonst gewicht zu groß) müssen
:D

@ richthofen: irgenwie gibts immer eine rechtfertigung für das was nv tut oder ?:naughty:

cya axel

[Richthofen]

das ist doch keine Rechtfertigung.
Die müssen sich für nix rechtfertigen.

Wenn sie ihr Tempo beibehalten wollen und der Ansicht sind das die Foundries da nicht mitkommen, dann werden sie über gute Kühlung ernsthaft nachdenken müssen. Die werden schon sehr gut wissen ob die Foundries das liefern können was sie brauchen werden.

Eine andere Lösung gibts nicht.
Wenn die Foundries nicht mitkommen, bliebe sonst nur Tempo akut verlangsamen und das kann kaum das Ziel sein.

Natürlich ist Kühlung nicht alles. Man wird auch an den Architekturen tüfteln müssen aber das wird derjenige in seiner Betrachtung schon mit eingeschlossen haben.
Die werden schon wissen sie brauchen werden.

[zeckensack]

Originally posted by Richthofen
ich denke eher sie bilden den technischen Fortschritt bei GPUs auf die Fertitungsmöglichkeiten ab.

Da die Technik momentan der Fertigung voll wegrennt, ist es doch nur logisch, dass es dazu kommen wird. Da wird man sich einiges an Kühlmethoden einfallen lassen müssen.

Das hat nix damit zu tun, dass sie se nicht mehr alle haben, sondern dass sie der Ansicht sind, dass weder TSMC noch UMC noch irgendein anderer das liefern kann was benötigt wird, wenn man das Tempo ungefähr beibehalten will.
Also alle 18 Monate ein neu Design mit doppelt so vielen Transistoren. Die einen nennen es technischen Fortschritt, ich nenne es Unfähigkeit und pure Panik.
NV muß die Hosen bis oben hin voll haben, wenn sie sowas offiziell verbreiten lassen.

[Spake]

auch wenn ichs schon mal wo anders gesagt habe:
grafikkarten werden den weg von cpus nehmen und können nur noch direkt auf dem mainboard verbaut werden

wie das aussieht sieht man hier schlecht dargestellt:

[Spake]

also quasi hier:

[Pussycat]

Originally posted by Richthofen
das ist doch keine Rechtfertigung.
Die müssen sich für nix rechtfertigen.

Wenn sie ihr Tempo beibehalten wollen und der Ansicht sind das die Foundries da nicht mitkommen, dann werden sie über gute Kühlung ernsthaft nachdenken müssen. Die werden schon sehr gut wissen ob die Foundries das liefern können was sie brauchen werden.

Eine andere Lösung gibts nicht.
Wenn die Foundries nicht mitkommen, bliebe sonst nur Tempo akut verlangsamen und das kann kaum das Ziel sein.

Natürlich ist Kühlung nicht alles. Man wird auch an den Architekturen tüfteln müssen aber das wird derjenige in seiner Betrachtung schon mit eingeschlossen haben.
Die werden schon wissen sie brauchen werden.

Der Kerl geht wirklich darauf ein. Unglaublich.

[Mehrpack]

hi,
120 watt, goil entlich kann ich spagetti kochen wärent ich ne runde spiele ;D.

also da muss man sich schon fragen, nenene.

wahrscheinlich wird es dann wohl so aussehn wie die G3-cpu (hoffe ich hab das richtig im gedächtnis) für den MAC die aufs mainboard gesteckt wurden und dann nen fatzen kühler ala P4 druff aus voll küpfer, na denne.
bloss muss man auf passen das net die daus versuchen dann die cpu dort reinzuprügeln....

Mehrpack

[Muh-sagt-die-Kuh]

120 W?

lol....das sind Itanium 2 Dimensionen....passende Kühler sind ersten verdammt groß und zweitens sackschwer....da muss NVidia ja schon aufpassen, dass es den AGP Slot nicht abreisst ;)

[StefanV]

Originally posted by Muh-sagt-die-Kuh
120 W?

lol....das sind Itanium 2 Dimensionen....passende Kühler sind ersten verdammt groß und zweitens sackschwer....da muss NVidia ja schon aufpassen, dass es den AGP Slot nicht abreisst ;)
...oder einfach nur verdammt laut *eg*

ein 'normaler' AMD Kühler müsste auch 120W schaffen, wenn man 'nen EHE da draufschraubt...

[Ailuros]

Originally posted by zeckensack
Die einen nennen es technischen Fortschritt, ich nenne es Unfähigkeit und pure Panik.
NV muß die Hosen bis oben hin voll haben, wenn sie sowas offiziell verbreiten lassen.

Oder sie setzen dass vorhandene Gigapixel Talent effektiver ein im Notfall (d.h. wohl sie koennen aber sie moechten nicht).

Zumindest brauchen sie dann nicht Taktraten und Pipeline-Anzahl so grob erhoehen fuer dx9 MRT mit FP32 oder hoeher (in der Zukunft).

Trotzdem stimmt hier an der ganzen Geschichte etwas nicht; R300 mit 110M Transistoren auf 0.15nm verbraucht umso einiges weniger Strom als NV30. Ich halte es fuer verstaendlich dass NV30 fuer low-K ausgelegt war, musste aber im letzten Moment auf high-K wechseln. Ich bin ja neugierig wie es bei NV35 dann aussieht.

Mal angenommen NV40 kommt mit umso einiges hoeherer Taktrate und zweimal so viel Pipelines wie NV35, gibt es einen anderen Grund dafuer als den den ich oben aufgefuehrt habe? ***edit: (dx9MRT + (=/>)FP32).

[robbitop]

bei 20-30Mio Transistoren mehr?

da kann mann nicht VS/PS30 und noch 4 Pipes reinbekommen, denk ich.
Mit diesem Variablen Pipedesign können sie die Units die sie brauchen einfach erhöhen, oder wie siehst du das Ailuros?

[Exxtreme]

120 Watt? :o

Das sind 4 Elektronik-Lötkolben.

Also wie sie hier die Wärme abführen wollen, das will ich sehen.

[robbitop]

bei CPUs ist der Trend leider genauso zu beobachten gewesen. 1998: 20-30W heute: 60-85W. Klasse oder?

Ich denke 120W sind wohl mittelfristig geplant, dazu benötigt man ne gute WaKü oder eben neue Formfaktoren. Denn die sind mit heute denkbaren Kühlmassnahmen nicht abzuführen.

Ich freu mich dann ja schon auf die Mobile generation von den Karten.
5Min akkuzeit und ein Laptop, dass aussieht wie eine mobile Koffer-A-Bombe. SUPER... :-(

[Endorphine]

Originally posted by robbitop
bei CPUs ist der Trend leider genauso zu beobachten gewesen. 1998: 20-30W heute: 60-85W. Klasse oder?
Naja, nicht ganz. Es hat mehr mit der Fertigungstechnik zu tun. Der PPro 200 mit 1 MB L2-Cache nimmt 47 Watt auf, ein PII-300 "Klamath" setzt 43 Watt in Wärme um. Das war noch deutlich vor 1998.

Alte Server- und Workstation-CPUs genehmigten sich ebenfalls seit Jahren regelmässig deutlich mehr als 50 Watt. Das geht langfristig betrachtet doch sehr langsam aufwärts, wenn man auch die extreme Steigerung der Rechenleistung im selben Zeitraum in Betracht zieht.

Bei Grafikkarten steigt die Leistung noch in deutlich kürzerer Zeit wesentlich stärker an. Und dabei werden die GPUs noch nicht mal von darauf spezialisierten Herstellern gefertigt, sondern von Foundries wie TSMC oder UMC.

Was wollt ihr? Schnelle Grafikkarten und schnelle Weiterentwicklung in kurzer Zeit? Dann müsst ihr auch damit leben, dass die Fertigungstechnik sich nicht so schnell weiterentwickelt wie die ASIC-Architektur der GPUs.

[x-dragon]

Originally posted by robbitop
...
Ich denke 120W sind wohl mittelfristig geplant, dazu benötigt man ne gute WaKü oder eben neue Formfaktoren. Denn die sind mit heute denkbaren Kühlmassnahmen nicht abzuführen.
... Also heute "denkbare" Kühlmaßnahmen gibts denke ich einige. Wie wärs z.B. mit Stickstoffkühlung im Taschenformat? :)

[Endorphine]

Übrigens bringen die für Grafikkartenverhältnisse extremen Leistungsaufnahmen auch positive Seiteneffekte mit sich: da der Kunde bei Desktopgrafikkarten Temperatur-, Spannungs- und Powermanagement allgemein nicht fordert und bezahlt, dies aber bei einer so hohen Leistungsdichte bei den schlechten Bedigungen heutiger Erweitertungskartenformfaktoren langsam essentiell für stabilen Betrieb wird, werden nach und nach Powermanagement & Co. wohl auch in alle Grafikkarten Einzug halten.

Das könnte dann den Lärm und die Leistungsaufnahme erheblich senken, wenn die volle 3D-Leistung der Karte nicht gefordert wird.

Fraglich ist nur, ob der Vorteil noch bestehen bleibt, wenn moderne Betriebssysteme in Zukunft die 3D-Beschleunigung für GUI-Spielereien nutzen werden (Microsoft z.B. will das)... :|

[x-dragon]

Originally posted by Endorphine
Übrigens bringen die für Grafikkartenverhältnisse extremen Leistungsaufnahmen auch positive Seiteneffekte mit sich: da der Kunde bei Desktopgrafikkarten Temperatur-, Spannungs- und Powermanagement allgemein nicht fordert und bezahlt, dies aber bei einer so hohen Leistungsdichte bei den schlechten Bedigungen heutiger Erweitertungskartenformfaktoren langsam essentiell für stabilen Betrieb wird, werden nach und nach Powermanagement & Co. wohl auch in alle Grafikkarten Einzug halten.

Das könnte dann den Lärm und die Leistungsaufnahme erheblich senken, wenn die volle 3D-Leistung der Karte nicht gefordert wird.

Fraglich ist nur, ob der Vorteil noch bestehen bleibt, wenn moderne Betriebssysteme in Zukunft die 3D-Beschleunigung für GUI-Spielereien nutzen werden (Microsoft z.B. will das)... :| Bis Longhorn kommt müssen die Grafikkartenhersteller sich wohl auf jeden Fall ein besseres Powermanagement einfallen lassen, als es bisher bei der FX zum Einsatz kommt. Wie du ja schon angedeutet hast, wird Direct3D wahrscheinlich in den nächsten Windows-Versionen auch schon auf dem normalen Desktop zum Einsatz kommen. Und wenn man das FX-Geräusch dann auch schon beim einfachen Texte schreiben hat ...

[Endorphine]

Originally posted by X-Dragon
Bis Longhorn kommt müssen die Grafikkartenhersteller sich wohl auf jeden Fall ein besseres Powermanagement einfallen lassen, als es bisher bei der FX zum Einsatz kommt. Wie du ja schon angedeutet hast, wird Direct3D wahrscheinlich in den nächsten Windows-Versionen auch schon auf dem normalen Desktop zum Einsatz kommen. Und wenn man das FX-Geräusch dann auch schon beim einfachen Texte schreiben hat ... Wenn Microsoft sich mit den GPU-Herstellern zusammensetzt könnten sie ja zusammen ein Subset der 3D-Funktionalität der 2D-Einheit zuordnen. Dieses Subset muss als zukünftiger kleinster gemeinsamer Nenner dann in allen Grafikkarten vorhanden sein und nicht zu viel Saft fressen. Dann könnte man auch beim normalen arbeiten den restlichen 3D-Teil abschalten und den Chip und Speicher auf jeweils 100 MHz runtertakten und den Lüfter zum Stillstand bringen :)

[ethrandil]

zeckansack, demirug, wie siehts aus mit dual-gpu-karten?
[Voodoo :D]
Da ließe sich die Wärmequelle teilen und wäre nichtmehr ein sogroßer Hotspot. also quasi 2x60 W.
Natürlich müssten die dies andere Aufgaben übernehmen ... zB jeweils 4 Renderinpipelines und 2 Pixelshader ... Zentrale Dinge müsste man entweder doppelt einbauen, oder man behilf sich eines schnellen BUS-Systems, für den Austausch.
Gibt es Überlegungen in diese Richtung?

[Endorphine]

Viel zu teuer (2x IC-Verpackung, unnötige Platinenfläche, interner Bus nötig usw.) und würde allen Grundsätzen von modernem IC-Design entgegenlaufen. Je höher die Integration, desto besser. Ausserdem verlagert sich das Problem dann nur. Ursachenbekämpfung ist immer besser als Symptomlinderung =)

Des weiteren sinkt die Geschwindigkeit, wenn du einen vorher hochintegrierten Chip nun auf mehrere aufteilst. Das Gegenteil ist praktisch immer das optimalere.

[Ailuros]

Originally posted by robbitop
bei 20-30Mio Transistoren mehr?

da kann mann nicht VS/PS30 und noch 4 Pipes reinbekommen, denk ich.
Mit diesem Variablen Pipedesign können sie die Units die sie brauchen einfach erhöhen, oder wie siehst du das Ailuros?

Nein ich meinte ganz was anderes. Um akzeptable Leistung mit dx9 multiple render targets und FP32 (oder hoeher) zu erreichen, werden IMR's in der vorsehbaren Zukunft gezwungen sein Taktraten und Pipeline-Anzahl drastisch zu erhoehen; wobei ein TBDR dieser Notwendigkeit wenn es zu interner Farbengenauigkeit kommt wohl nicht haben sollte (theoretisch zumindest).

Ich hatte nicht 4 pipes im Kopf, sondern 1GHz oder hoehere Taktraten und 16 pipes z.B; wenn man dann mit viel niedriger Taktrate und nur die Haelfte von pipes auf einem TBDR davonkommt, dann macht es auch einen nenneswerten Unterschied.

Uebrigens meinte ich nicht unbedingt VPU's in 2003; eher ein Stueck weiter. Wenn NV35 100-120W verbraten sollte, dann sieht es nochmal schlecht fuer NV aus, was ich aber momentan bezweifle.

***edit: wieso kann man theoretisch zumindest nicht PS/VS3.0 auf einem 4*2 setup bekommen? Leistung ist dann wohl ein ganz anderes Bier :D

[Demirug]

Ailuros, ich verstehe dein Problem nicht. einen VS/PS 3.0 Chip bekommt man auch mit einer Pipeline und einer TMU hin. Von Performances braucht man aber dann nicht mehr unbeding zu sprechen.

Deine überlegung bezüglich der benötigten Rechenleistung bei einem IMR im vergleich zu einem DR (ob jetzt TB oder irgendwas anderes) kann ich nicht unbedingt Teilen. Bei einem IMR jagt man eben vorher mal schnell einen Z-Pass durch und das Early-Z erledigt den Rest. IMRs brauchen also in Zukunft eine schnelle Logik für Z-Only Passes und ein gutes Early-Z und in der Pixelpipeline entsteht nicht mehr Rechenbedarf als bei einem DR.

IMR könnten dabei sogar etwas was ein DR niemals tun könnte. Es geht hier um eine Technik die ich als Early-Object Culling bezeichne. Bei gelegenheit stelle ich das ganze mal im Technologie Forum vor. Kurz gesagt es geht dabei darum den Z-Pass dahingehend zu benutzten nicht nur verdeckte Pixel zu finden sondern ganze Objekte noch vor dem durchlaufen der Vertexshader zu verwerfen.

[Pussycat]

Warscheinlich ist das Problem erst mal am besten zu lösen durch den Kauf einer ATI-karte :)

[zeckensack]

Originally posted by Ailuros
Oder sie setzen dass vorhandene Gigapixel Talent effektiver ein im Notfall (d.h. wohl sie koennen aber sie moechten nicht).

Zumindest brauchen sie dann nicht Taktraten und Pipeline-Anzahl so grob erhoehen fuer dx9 MRT mit FP32 oder hoeher (in der Zukunft).

Trotzdem stimmt hier an der ganzen Geschichte etwas nicht; R300 mit 110M Transistoren auf 0.15nm verbraucht umso einiges weniger Strom als NV30. Ich halte es fuer verstaendlich dass NV30 fuer low-K ausgelegt war, musste aber im letzten Moment auf high-K wechseln. Ich bin ja neugierig wie es bei NV35 dann aussieht.An der Geschichte stimmt noch was ganz anderes nicht:
Ich sehe überhaupt keinen sinnvollen Grund, warum der NV30 überhaupt 110Mio Transistoren hat. Bei der albernen Leistung pro Takt verstehe ich einfach nicht, wie man diese Menge erreichen konnte. Nochmal:
acht Textursampler
FP16-ALUs, Anzahl momentan unklar
acht*vier Einheiten für Z/Stencil-Tests. Die Duplikate sind für's Multisampling.
Der R300 hat 48 solcher Einheiten. Außerdem FP24-ALUs und auch acht Textursampler. Und er hat sowohl weniger Transistoren, als auch die höhere Performance pro Takt :|

[zeckensack]

Originally posted by ethrandil
zeckansack, demirug, wie siehts aus mit dual-gpu-karten?
[Voodoo :D]
Da ließe sich die Wärmequelle teilen und wäre nichtmehr ein sogroßer Hotspot. also quasi 2x60 W.
Natürlich müssten die dies andere Aufgaben übernehmen ... zB jeweils 4 Renderinpipelines und 2 Pixelshader ... Zentrale Dinge müsste man entweder doppelt einbauen, oder man behilf sich eines schnellen BUS-Systems, für den Austausch.
Gibt es Überlegungen in diese Richtung? Die Idee ist shice, weil zu viele Daten verdoppelt werden müssen.

Ich habe mir früher schonmal 'ne Alternativ-Lösung zurechtgesponnen: Klick mich (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=27580)

[Xmas]

Originally posted by zeckensack
An der Geschichte stimmt noch was ganz anderes nicht:
Ich sehe überhaupt keinen sinnvollen Grund, warum der NV30 überhaupt 110Mio Transistoren hat. Bei der albernen Leistung pro Takt verstehe ich einfach nicht, wie man diese Menge erreichen konnte. Nochmal:
vier Textursampler
FP16-ALUs, Anzahl momentan unklar
acht*vier Einheiten für Z/Stencil-Tests. Die Duplikate sind für's Multisampling.
Der R300 hat 48 solcher Einheiten. Außerdem FP24-ALUs und acht Textursampler. Und er hat sowohl weniger Transistoren, als auch die höhere Performance pro Takt :|
Wie kommst du auf die 4 Textursampler? Beim Multitexturing zeigt sich doch deutlich, dass es 8 sind.

[zeckensack]

Japp, tschuldigung, hast Recht: Beweis (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=766442#post766442)

Ich werd's schnell editieren, bevor's noch jemand sieht :bäh:

[egdusp]

Nochmal zum Topic zurück:

Ich sehe 2 recht einfach umsetzbare Lösungen für das nette Hitzeproblem:
1: Da zukünftige Mainboards sowieso fast alle Funtkionen onboard mitbringen (zumindest die Markenboards, die man wohl auch so bei Käufern von High End Grafikkarten erwartet), sollte der Verzicht auf 2 PCI Plätze nicht schwerfallen. Lan, USB, Firewire, High Quallity 5.1 Sound, etc... finden sich alle schon auf aktuellen nForce Boards. 3 PCI Slots sollten dann für den Rest (TV Karte, Wireless Lan, etc..) ausreichend sein, besonders da ein solcher Spielecomputer wohl kaum für aufwändigere Tätigkeiten (Videoschnitt, Soundbearbeitung) eingestzt werden dürfte.
==> Der AGP Port wird durch eine Art Sockel ersetzt, auf den die Grafikkarte dann parallel zum Mainboard aber mehrere Zentimter höher plaziert wird (inklusive stabiler Besfestigung).
Die Lüftung kann dann über 3 Slots an der Rückseite erfolgen in ATX Gehäusen, möglich wäre auch die Einführung einer erweiterten Norm mit vollständiger Öffnung an dieser Stelle und entsprechenden Verkleidungen.

2: Ganz einfach, eine nach außen geführte Flüssigkeitskühlung.
Wer den Verbrauchern einen Dustbuster zumutet, wird auch keine Probleme haben eine leise und Leistungsfähige Lüftung zu vermittlen.
Eine seperate Pumpe und außenliegenden Kühlkörper mit langsam drehenden Lüftern sollten einen Freak nicht wirklich stören. Der hat sowieso schon ein Haufen Adapter, Router und Kabelgewirr hinter seinem Computer.
Alternativ wäre auch eine Kühlung über einen 5 1/4 Schat denkbar. Sozusagen ein ausgelagerter Dustbuster mit größeren = langsameren = leiseren Lüftern. Auch wäre das Verstaubungsproblem dort wohl geringer.

Eure Einschätzung?

mfg
egdusp

[csjunkie]

hmm 120+ Watt? Wieviel das wohl in Dezibel ist?http://www.planet3dnow.de/vbulletin/images/smilies/lachen70.gifhttp://www.planet3dnow.de/vbulletin/images/smilies/lachen70.gifhttp://www.planet3dnow.de/vbulletin/images/smilies/lachen70.gifhttp://www.planet3dnow.de/vbulletin/images/smilies/lachen70.gif
http://www.aceshardware.com/read_news.jsp?id=65000393

[INTRU]

Ups... hatte den Thread hier nicht gesehen.

Habe im Gehäuseforum den Thread "Wird es in naher Zukunft einen neuen ATX Gehäuse Standard geben? (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=61349)" eröffnet!

[Ailuros]

Originally posted by Demirug
Ailuros, ich verstehe dein Problem nicht. einen VS/PS 3.0 Chip bekommt man auch mit einer Pipeline und einer TMU hin. Von Performances braucht man aber dann nicht mehr unbeding zu sprechen.[/b]

Irrelevant. Ich hab auch nicht von Anfang an PS/VS3.0 erwaehnt sondern meinte ganz was anderes.

Deine überlegung bezüglich der benötigten Rechenleistung bei einem IMR im vergleich zu einem DR (ob jetzt TB oder irgendwas anderes) kann ich nicht unbedingt Teilen. Bei einem IMR jagt man eben vorher mal schnell einen Z-Pass durch und das Early-Z erledigt den Rest. IMRs brauchen also in Zukunft eine schnelle Logik für Z-Only Passes und ein gutes Early-Z und in der Pixelpipeline entsteht nicht mehr Rechenbedarf als bei einem DR.


Also haben Deiner Meinung nach TBDR's keinerlei nenneswerte Vorteile im Vergleich zu IMR's im Bereich "high precision floating point pipelines"?

So wie ich es momentan sehe hat weder NV30 noch R300 die Bandbreite/Fuellrate fuer FP32 mit akzeptabler Leistung. Wo ist dann meine Spekulation fehlgeraten, wenn ich denke dass es notwendig sein wird dass Taktraten und Anzahl von Pipelines intensiver nach oben skalieren werden in absehbarer Zeit?

Wieviel Bandbreite braucht theoretisch eine R300 mit 2.6GPixels/sec Fuellrate fuer 128bit intern? Wieviel braeuchte sie mit 1024x768/4xAA/128bits? Ich meine nicht hier und heute sondern in der Zukunft wenn wir endlich mal dx9 Applikationen sehen werden.

Bleiben vielleicht IMR's bei 500MHz und 8 pipelines fuer immer stecken?

IMR könnten dabei sogar etwas was ein DR niemals tun könnte. Es geht hier um eine Technik die ich als Early-Object Culling bezeichne. Bei gelegenheit stelle ich das ganze mal im Technologie Forum vor. Kurz gesagt es geht dabei darum den Z-Pass dahingehend zu benutzten nicht nur verdeckte Pixel zu finden sondern ganze Objekte noch vor dem durchlaufen der Vertexshader zu verwerfen.

Klingt aeusserst interessant. Lass es mich bitte wissen da ich eigentlich selten in andere Foren hier reinschaue.

Dabei hab ich nicht die Effizient von den beiden Architekturen im Ganzen gemeint, sondern nur einen Teil davon.

Eigentlich hab ich auch eine Frage gestellt; ob und wenn Taktraten und Pipeline-Anzahl radikal erhoeht werden, high precision floating point der ausschlagende Grund sein wird, oder mehr dahinter steckt.

Mehr Annahmen/Hypothesen als Fakten; schau her:

Ich hatte nicht 4 pipes im Kopf, sondern 1GHz oder hoehere Taktraten und 16 pipes z.B; wenn man dann mit viel niedriger Taktrate und nur die Haelfte von pipes auf einem TBDR davonkommt, dann macht es auch einen nenneswerten Unterschied...

[Demirug]

Originally posted by Ailuros

Also haben Deiner Meinung nach TBDR's keinerlei nenneswerte Vorteile im Vergleich zu IMR's im Bereich "high precision floating point pipelines"?

Bei den Pipelines nichts. Was beim IMR zusätzlich anfällt ist die Bandbreite und Rechenleistungs für den Z-Pass. Dafür hat ein TBDR die Bandbreite und Rechenleistung für das Binning aufzubringen. Die Vorteile eines TBDR (zb. bessere Auslastung durch stärker Entkopplung) die es schon aus Integer Zeiten gibt bleinen bestehen. Aber durch "high precision floating point pipelines" kommen keine neuen hinzu.

So wie ich es momentan sehe hat weder NV30 noch R300 die Bandbreite/Fuellrate fuer FP32 mit akzeptabler Leistung. Wo ist dann meine Spekulation fehlgeraten, wenn ich denke dass es notwendig sein wird dass Taktraten und Anzahl von Pipelines intensiver nach oben skalieren werden in absehbarer Zeit?

Taktrate erhöhen ist immer ein gutes Mittel um die Leistung zu erhöhen der Leistung. Auch die Anzhal der Pipelines zu vergrössern hört sich erst mal gut an bringt allerdings mehr probleme mit sich als gut ist. Jede Pipelines (im klassischen Sinn) bedingt voher und Nachher bestimmte Einheiten damit sie richtig funktionieren kann. Bei 16 vollständigen Pipelines müsste man zum Beispiel jede Pipeline mit AA-Sampler ausstatten. Zudem kommt noch das Bandbreiten Problem dazu.16 Pipelines könnten 16*64 Bit= 1024 Bit Daten pro Takt erzeugen (ohne AA) dafür bäuchte man einen 512 Bit Bus mit DDR Speicher bei gleichem Takt und dann währe keine Bandbreite mehr übrig. Deswegen gehe ich davon aus das wir die 8 Pipelines noch eine Zeit lang haben werden. Allerdings wird man die Rechenleistung dieser Pipelines noch erhöhen. Die Taktraten werden natürlich weiterhin im Rahmen des möglichen steigen.

Wieviel Bandbreite braucht theoretisch eine R300 mit 2.6GPixels/sec Fuellrate fuer 128bit intern? Wieviel braeuchte sie mit 1024x768/4xAA/128bits? Ich meine nicht hier und heute sondern in der Zukunft wenn wir endlich mal dx9 Applikationen sehen werden.

Die Bandbreite inerhalb eines Chips kann man kaum definieren da es dort eine grosse Menge an Datenbussn gibt. So muss ja zum Beispiel jede bi-TMU (32bit RGBA) ja schon mit 128 Bit angebunden werden. Bei TMUs sind das 1024 Bit. Bei FP32 bi-TMUs würden sich sogar 4096 Bit ergeben. Auch die Anbindung der AA-Sampler zu den Kompressioneinheiten ist richtig heftig. Jeder AA-Sampler kann jeweils einen Z, Stencil und Farbwert von der Kompressionseinheit empfangen und auch wieder schreiben. macht also 2*(24+8+32) = 128 Bit. Bei 8 Pipelines mit jeweils 6 Samplern (R300) kommen wir also auf 8*6*128 = 6144 Bit. Bei einer umstellung auf fp32 AA-Sampler sind es dann sogar 24576 Bit. Glücklicherweise sind Datenwege auf einem DIE nicht so teuer wie die externen.

Bleiben vielleicht IMR's bei 500MHz und 8 pipelines fuer immer stecken?

Bei den Taktraten wie gesagt sicher nicht. Ob allerdings nach dem 8 Pipelines wirklich noch 16 kommen werden bezweifle ich etwas. Ich persönlich gehe eher davon aus das man mit den 8 Pipes bis ans ende der sinnvollen Leistungsfähigkeit geht und dann etwas ganz anderes kommt.

Klingt aeusserst interessant. Lass es mich bitte wissen da ich eigentlich selten in andere Foren hier reinschaue.

http://www.forum-3dcenter.de/vbulletin/showthread.php?s=&threadid=61271

Dabei hab ich nicht die Effizient von den beiden Architekturen im Ganzen gemeint, sondern nur einen Teil davon.

Eigentlich hab ich auch eine Frage gestellt; ob und wenn Taktraten und Pipeline-Anzahl radikal erhoeht werden, high precision floating point der ausschlagende Grund sein wird, oder mehr dahinter steckt.

Taktraten werden erhöht wenn es der Prozess zuläst und die Konkurrenz es erfordert. Ist bei den CPUs ja auch nicht anders. Ob und wann man die Pipeline zahl erhöht hängt in gewisser Weisse auch davon ab ob es im technischen Gesamtbild (speziel peicheranbindung) überhaupt sinn macht. Mit einem 256 Bit DDR Bus machen eben mehr als 8 Pipelines nicht wirklich Sinn. Da ich persönlich nicht glaube das man auch noch 512 Bit Busse bauen möchte muss also von der Speichertechnologie was neues kommen. FP Framebuffer werden die Situation an dieser Stelle noch schlimmer machen.

Mehr Annahmen/Hypothesen als Fakten; schau her:

Takt kann man kaum sparen weil man ja eine vergleichbare Vertexshaderleistung braucht. Auch bei den Pipelines sehe ich nicht wirklich grosses Einsparmöglichkeiten. Und beides Zusammen ist IMHO nicht drin. Aufgrund der besseren Auslastung durch die Entkopplung sollte ein TBR einem technologisch gleichwertigem IMR bei gleichem Takt etwas überlegen sein solange man die Finger von einseitigen Benchmarks läst. Bleibt nur noch die Bandbreite. Dummerweise werden die Dreiecke immer kleiner und die Datenmenge pro Vertex immer höher. Der Bandbreiten und speicherbedarf für das Binning steigt also stärker an.

[Unregistered]

Ähem... naja, ein TBR wäre doch in der Lage die gleiche End-Leistung bei geringerer Leistungsaufnahme (weil nicht soviel Rohpower nötig) zu bieten, oder nicht?
Da könnten dann auch die Foundries wieder mithalten, oder nicht?

Wenn diese Vermutungen stimmen sollten, warum steckt NV dann einen Haufen Schmott in eine Technologie, die anscheinend langsam an Grenzen zu stossen scheint, und beschreitet dabei anscheinend auch ziemlich neue Wege, die aber insgesamt trotzdem nicht das Optimum darstellen?

Grüße
Gaestle
---
Rock and Roll aint noise pollution...

[Unregistered]

Originally posted by Demirug
Dummerweise werden die Dreiecke immer kleiner und die Datenmenge pro Vertex immer höher. Der Bandbreiten und speicherbedarf für das Binning steigt also stärker an.

*räusper*
DAS erklärt natürlich einiges...

*doppelräusper*
Genaues lesen hilft eben doch manchmal...

Grüße
Gaestle
---
Rock and Roll aint noise pollution...

[Ailuros]

Danke Demirug fuer die ausfuehrliche Erklaerungen.

Was beim IMR zusätzlich anfällt ist die Bandbreite und Rechenleistungs für den Z-Pass. Dafür hat ein TBDR die Bandbreite und Rechenleistung für das Binning aufzubringen.

Bleibt nur noch die Bandbreite. Dummerweise werden die Dreiecke immer kleiner und die Datenmenge pro Vertex immer höher. Der Bandbreiten und speicherbedarf für das Binning steigt also stärker an.


Kann auf beiden Z-data Komprimierung nicht helfen?

Danke auch fuer den Link. Nur ein kleiner Kommentar dazu:

Ein TBDR (z.B. Kyro) kann dieses Problem leider auch nicht lösen da die die Verfahren ja erst greifen können wenn die Geometrie vollständig vorliegt.

Ist es das Verfahren dass einen TBDR dazu zwingen sollte, oder gehst Du vom Ideal-Fall eines TBDR mit Geometrie aus? Soweit ich weiss ist es keine absolute Vorraussetzung bei PVR, zumindest nach deren eigenen Behauptungen (keine Ahnung ob intermediate renders bei KYRO mit Geometrie moeglich sind).

[Ailuros]

Wenn diese Vermutungen stimmen sollten, warum steckt NV dann einen Haufen Schmott in eine Technologie, die anscheinend langsam an Grenzen zu stossen scheint, und beschreitet dabei anscheinend auch ziemlich neue Wege, die aber insgesamt trotzdem nicht das Optimum darstellen?

Ich weiss Du hasst danach Demi's Post genauer durchgelesen, aber ich glaube an den sogenannten "IMR-bandwidth wall" gar nicht (hab ja auch was darueber in einem anderen Thread gepostet).

Als Laie hab ich mir mal schnell vorgestellt, dass wenn in der Vergangenheit Tilers viel weniger Bandbreite/Fuellrate brauchten fuer 32bit rendering, dass sich das auch weitertraegt auf hoehere interne Praezision.

Was ich wohl uebersehen habe ist, dass zu GF2 Zeiten kein occlussion culling vorhanden war.

Uebrigens mal ganz ehrlich gesagt, wenn man das Interesse von Leuten die wissen wo es lang geht nicht anspornt, kommt man selten auf genauere Informationen (nur mal in Relation zu einigen Zweifeln die ich in letzter Zeit hatte und bestaetigen wollte).

[Demirug]

Originally posted by Ailuros

Kann auf beiden Z-data Komprimierung nicht helfen?

Z-Daten fallen beim Binning ja nicht an. Man könnte aber durchaus auch die Binning Daten komprimieren. Aufgrund der Art der Daten lässt sich ein Z-Buffer aber viel einfacher als ein Binning Buffer komprimieren. Ich kann da wenn es gewüscht wird gerne in die Details gehen.


Danke auch fuer den Link. Nur ein kleiner Kommentar dazu:

Ist es das Verfahren dass einen TBDR dazu zwingen sollte, oder gehst Du vom Ideal-Fall eines TBDR mit Geometrie aus? Soweit ich weiss ist es keine absolute Vorraussetzung bei PVR, zumindest nach deren eigenen Behauptungen (keine Ahnung ob intermediate renders bei KYRO mit Geometrie moeglich sind).

Meine Aussage bezog sich auf einen TBDR der streng nach dem Verfahren der Serie3 arbeitet und keine IMR Option hat. Natürlich könnte man sonst das füllen der Object ID Buffer auch in einem IMR mode durchführen. Allerdings braucht man dann auch bei einem TBDR einen Z-Buffer und damit hätte sich der Bandbreitenvorteil gegenüber einem IMR endgültig erledigt. Es sollte aber denoch im Bereich des möglichen sein auch einen DR zu bauen der dieses Verfahren beherscht. Für einen der nur das ausführen der Pixelshader verzögert könnte ich sofort ein Konzept bauen. Für einen der nach einem TB Verfahren arbeitet wird es schon etwas komplizierter. Weil man zu Tilen ja nun leider die Positionen aus dem Vertexshader braucht Das bringt mich aber gerade noch auf eine andere Idee. Spliten der Vertexshaderprogramme in die Positionsberechnung und den Rest. Den Rest dann nur für Verticen ausführen die zu sichtbaren Dreiecken gehören.

[Ailuros]

Meine Aussage bezog sich auf einen TBDR der streng nach dem Verfahren der Serie3 arbeitet und keine IMR Option hat. Natürlich könnte man sonst das füllen der Object ID Buffer auch in einem IMR mode durchführen. Allerdings braucht man dann auch bei einem TBDR einen Z-Buffer und damit hätte sich der Bandbreitenvorteil gegenüber einem IMR endgültig erledigt.

Du meinst wohl einen genauso grossen Z-Buffer auf einem TBDR wie auf einem IMR?

Weil man zu Tilen ja nun leider die Positionen aus dem Vertexshader braucht. Das bringt mich aber gerade noch auf eine andere Idee. Spliten der Vertexshaderprogramme in die Positionsberechnung und den Rest. Den Rest dann nur für Verticen ausführen die zu sichtbaren Dreiecken gehören.

Kannst Du vielleicht das fettgedruckte etwas einfacher fuer den armen Laien machen? ;(

[halllo_fireball]

Nochmal zur Kühlung zurück:

Ich denke über kurz oder lang wird die Luftkühlung, zumindest in den Highend-PCs keinen Platz mehr finden. Dann werden wohl Wasserkühlungen ihren Dienst verrichten. Erste Ansätze konnte man bei Corsair (Kühlköfferchen) und Gainward schon beobachten. Der Trend sollte sich auch in Zukunft dahingehend verstärken.

Vor längerem (ich weiß nicht mehr wann und warum) wurde schon das Ende der Luftkühlung Prophezeit, doch Kupferkühler und Heatpipes, die gar keine waren (Coolermaster Heatpipe :D), waren die Rettung der Luftkühlung. Will diese auch in Zukunft noch eine Rolle spielen, werden sich die Kühlspezialisten wohl neue Metallblockkonstrucktionen ausdenken müssen (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=61282)

Auch die Lüfterkonstruktionen sind noch lange nicht ausgereizt. Wenn man sich einmal Industrielüfter anschaut, gibt es da Teile mit ganz netten Fördermengen ;)

Zurück zu den Grafikkarten: In Zukunft werden wir uns wohl auf Ganzkartenkühlungen wie von Winfast einlassen müssen, da ja auf der Rückseite der Karte ja auch schon fast ein Spiegelei gekocht werden kann :D

Die Kühllösung im 5,25" Format ist natürlich auch noch ein Weg. Vielleicht sogar ein sehr wahrscheinlicher. Man möchte ja in Zukunft seine Highendkarten nicht ausschließlich an Freaks verkaufen die ein Köfferchen neben dem Computer stehen haben. Dafür würde vor allem der mehr oder weniger leichte Einbau sprechen, andererseits müsste dafür eigentlich schon fast ein Bigtower her, und da Miditower doch die am weitesten verbreiteten Gehäuse sind...

Die Histerie um die 1-3 PCI Plätze kann ich nicht nachvollziehen. Da doch selten mehr als 2 Karten in einem Rechner stecken und alle guten Boards 5 oder 6 PCI-Slots haben.

Jan :-)

[Demirug]

Originally posted by Ailuros Du meinst wohl einen genauso grossen Z-Buffer auf einem TBDR wie auf einem IMR?

Ja pro AA-Sample einen Z Wert. Kompression ist natürlich möglich. Ist aber unsinnig sowas zu machen. Der "Vorteil" bei meinem Verfahren ist ja das es einen Hint Charakter hat. Soll heissen ein Chip könnte das ganze auch einfach ignorieren und wie bisher rendern un würde zum gleichen ergeniss kommen.

Kannst Du vielleicht das fettgedruckte etwas einfacher fuer den armen Laien machen? ;(

Ein Vertexshader berechnet ja neben der Position der Verticen auch noch andere Dinge (Farben, Koordinaten, Fogwerte). All diese Dinge sind aber für Pixel die am Ende nicht sichtbar sind eigentlich vollkommen uninteresant. Bei einem TBDR wird für das Tilling lediglich die Position gebraucht. Und hier kommt jetzt meine spontane Idee zu tragen. Der Treiber müsste das Vertexshaderprogramm zu auseinadernehmen das es nur noch die zum Berechen der Position notwendigen Anweisungen enthält. Das könnte dann zum Beispiel nur noch eine Vektor Matrix Multipilkation sein. Die Anweisungen zum Berechnen des Rests werden in ein eigenes Programm verpackt.

Bekommt der Chip nun ein Object übergeben berechnet er nur die Positionen und führt das Tilling durch. Nachdem die ganze Szene übergeben ist wird wie bekannt das HSR verfahren durchgeführt. Nun haben wir die Information aus welchen Dreiecken Pixel sichtbar sind. Für jedes dieser Dreiecke ermitteln wir nun welche Verticen zu diesem Dreieck gehören und welches Programm dazu benutzt wird. Für alle Verticens die man dabei findet führt man dann den zweiten Teil des Vertexshaders durch. Nachdem alle Verticens berechnet sind geht es mit diesen Daten weiter in die Pixelshader.

Der Vorteil dabei ist:

- Man spart Rechenleistung für Verticens die gar nicht benutzt werden weil die entsprechenden Dreiecke verdeckt sind.
- Man spart Bandbreite für die Vertexinputdaten die zu Verticen gehören die nicht gebraucht werden.

Nachteil:
- Der Treiber muss eine zusätzliche Codeanalyse bei den Vertexshadern durchführen.
-Der zweite Teil der VS-Programme muss im Videospeicher hinterlegt werden.
-Man braucht entweder Vertexshader vor und nach dem HSR oder muss die Vertexshader so verschalten das man sie wahlweise einsetzten kann. In beiden Fällen besteht die Gefahr von neuen Flaschenhälse.

Wie gesagt die Idee kam mir vorhin spontan beim schreiben und ist deshalb noch nicht sehr weit entwickelt.

PS: Wir beide haben die Tendenz immer wieder oftopic zu werden.

[Unregistered]

Würde man so auch pixelshader-power sparen (weil: sind ja weniger texturen zu bearbeiten)? Und damit transistoren, die man in die beseitigung von flaschenhälsen investieren kann?

Für wie effizienzsteigernd hältet Ihr die aktuellen OC-Techniken?


Grüße
Gaestle
---
Rock and Roll aint noise pollution...

[Crazytype]

Das Problem ist, dass Nvidia auch gesagt hat, dass Investitionen in SOI und Co nicht machbar sind, da der Grafikkartenmarkt zu flexibel ist und langjährige Entwicklungen und Investitionen nicht wirtschaftlich sind.

ati kann ja noch einiges machen zum runtersetzen der verlustleistung.
130 nm und CU, angepasstes Design.

[Ailuros]

Originally posted by Unregistered
Würde man so auch pixelshader-power sparen (weil: sind ja weniger texturen zu bearbeiten)? Und damit transistoren, die man in die beseitigung von flaschenhälsen investieren kann?

Für wie effizienzsteigernd hältet Ihr die aktuellen OC-Techniken?


Grüße
Gaestle
---
Rock and Roll aint noise pollution...

Soweit ich weiss ist HSR mit Pixel shadern kein Problem (zumindest nicht auf TBDR's, aber ich kann mir schlecht vorstellen warum dass nicht auch der Fall bei IMR's sein sollte.

PS: Wir beide haben die Tendenz immer wieder oftopic zu werden.

Demirug,

Ist es wirklich soooo schlimm? ;)

[maz]

Originally posted by Mehrpack
hi,
120 watt, goil entlich kann ich spagetti kochen wärent ich ne runde spiele ;D.

also da muss man sich schon fragen, nenene.

wahrscheinlich wird es dann wohl so aussehn wie die G3-cpu (hoffe ich hab das richtig im gedächtnis) für den MAC die aufs mainboard gesteckt wurden und dann nen fatzen kühler ala P4 druff aus voll küpfer, na denne.
bloss muss man auf passen das net die daus versuchen dann die cpu dort reinzuprügeln....

Mehrpack

habe hier einen imacdv aus 1999 mit einem g3 400
alles passiv gekühlt - sogar das netzteil (nix umgebaut, alles org.)

es sind zwar schon einige aluminium teile für die passive kühlung im imac drinnen, dafür hat das ding keinen einzigen lüfter und ist dementsprechend leise bis zum geht nicht mehr ;)

die g3's verbrauchen sehr wenig strom und geben auch wenig abwärme ab
weiss nicht von wo du deine infos hast...

[Unregistered]

Originally posted by Ailuros
Soweit ich weiss ist HSR mit Pixel shadern kein Problem (zumindest nicht auf TBDR's, aber ich kann mir schlecht vorstellen warum dass nicht auch der Fall bei IMR's sein sollte.


Ist schon klar, nur Demirug sprach davon, dass durch die Teilung der Arbeitsschritte des Vertexshaders Nachteile entstehen. wenn nun aber nur die Dreiecke "ausgemalt" werden, die sichtbar sind, braucht man bei einem TBDR wahrscheinlich bei entsprechendem Takt und Bauweise eine geringere Anzahl an Pixelshadern als IMR (so stell ich mir's zumindest vor), man hat zwar dann eine theoretisch geringere "Füllrate", allerdings braucht man ja auch nicht soviel "Füllrate" (vgl. Füllrate von KyroII und GF2 und die daraus resultierenden fps). Die dadurch eingesparten Transistoren könnten doch z.B. dafür eingesetzt werden, die von Demirug angesprochenen Flaschenhälse (die z.B. durch den notwendigen Traffic der Dreieckdaten - bei "geteiltem" Vertexshader - entstehen) zu "entkorken".

Grüße
Gaestle
---
Rock and Roll aint noise pollution...

[Demirug]

Sorry Gaestle, ich hatte deine Frage da oben übersehen.

Die Idee mit dem spliten des Vertexshadings würde keine weitere Einsparungen bei den Pixelshadern bringen. Das ist ja auch nicht möglich weil ein TBDR ja schon nur noch die Pixel wirklich im Pixelshader berechnet die auch wirklich sichtbar sind.

Was die Füllrate angeht so muss man inzwischen auch bei IMRs von mehreren Grössen sprechen.

Früher gab es nur die Pixel und texel füllrate. Inzwischen haben wir zwar immer noch die Texelfillrate aber die Pixelfillrate hat sich in mehrer Werte zerteilt. Wir haben die die maximale Anzahl sichtbarer Pixel/s sowie die maximale Anzahl unsichtbarer Pixel/s und dank NVIDIA (wenn man es genau nimmt ist aber PowerVR schon schuld) müssen wir jetzt auch noch mit unterschiedlichen Füllraten in abhängigkeit aus welchen DetailInfos (Farbe, Z und/oder Stencilwert) ein Pixel besteht herumschlagen. Zu guter letzt kommt hier auch noch die Rechenleistung in den Pixel-ALUs ins Spiel.

[Ailuros]

Wieso sind IHV's daran schuld? Haben IHV's vielleicht Carmack oder anderen Entwicklern vorgeschrieben stencilops zu benutzen?

Das mit der Fuellrate oder Bandbreite + Overdraw Berechnung haette PVR schon vor Jahren zu ihren Gunsten ausnutzen koennen; haben sie aber Gott sei Dank die Finger davon weggelassen bis jetzt.

Im Lichte vom normalem Marketing mambo-jumbo, wenn PVR behauptet dass K2 eine maximale stencil-Fuellrate von 5.6GPixels/sec hat (nur ein Beispiel was ich aber noch nicht in oeffentlichen Dokumenten gesehen habe), ist es dann nicht so viel schlimmer als die von anderen IHV's gehypten theoretischen Nummern.

...man hat zwar dann eine theoretisch geringere "Füllrate", allerdings braucht man ja auch nicht soviel "Füllrate" (vgl. Füllrate von KyroII und GF2 und die daraus resultierenden fps). Die dadurch eingesparten Transistoren könnten doch z.B. dafür eingesetzt werden, die von Demirug angesprochenen Flaschenhälse (die z.B. durch den notwendigen Traffic der Dreieckdaten - bei "geteiltem" Vertexshader - entstehen) zu "entkorken".

K2 und GF2 sind schlechte Vergleichsmassnahmen zu dem was heute vorliegen kann. Ausser dass es sich um veraltete Architekturen handelt, hat K2 weder eine T&L Einheit und hat dazu ein ernstes Problem mit der Bandbreite wenn es zum vertex data througput kommt, was den Vorsprung in Sachen Bandbreite im Vergleich zu einem IMR der gleichen Klasse oft fast ausgleichen kann.

Theoretisch zumindest (da es sich um Vapourware handelt), waere eine auf 200MHz getaktete K3 ein besserer Vergleich zu einer GF3, wo Vergleiche natuerlich eher die dx7 Routinen der GF3 betreffen sollten (GF2 hat ja kein occlussion culling).

Heutzutage braucht ein vergleichbarer TBDR zu einen IMR, fast genauso viel Transistoren und Spezifikationen. Demirug's Idee klingt gut, nur leider kann niemand solche Details wissen, bis PVR ein neues Produkt veroeffentlicht. Daher kann es sein dass sie entweder gar keine aehnliche Methode haben, oder im Idealfall auf eine noch bessere Alternative in der Zwischenzeit gekommen sind. In Patenten nachstoebern hilft auch nicht viel, im besten Fall findet man nur dass was bis jetzt bekannt ist und es dauert auch viel zu lange bis Patente veroeffentlicht werden.

Ich wage mich mal auf eine andere Art von Spekulation: wuerde ein TBDR heute NV30 als Konkurrenz entgegenstehen, muesste eine 3.2GTexels/sec Fuellrate auf einem 128bittigen bus genug sein.

[Demirug]

Originally posted by Ailuros
Wieso sind IHV's daran schuld? Haben IHV's vielleicht Carmack oder anderen Entwicklern vorgeschrieben stencilops zu benutzen?

Das mit der Fuellrate oder Bandbreite + Overdraw Berechnung haette PVR schon vor Jahren zu ihren Gunsten ausnutzen koennen; haben sie aber Gott sei Dank die Finger davon weggelassen bis jetzt.

Im Lichte vom normalem Marketing mambo-jumbo, wenn PVR behauptet dass K2 eine maximale stencil-Fuellrate von 5.6GPixels/sec hat (nur ein Beispiel was ich aber noch nicht in oeffentlichen Dokumenten gesehen habe), ist es dann nicht so viel schlimmer als die von anderen IHV's gehypten theoretischen Nummern.

Das mit dem schuld war etwas ironisch gemeint. Früher gab es einen Wert und der war für alles da. Dann gab es unterschiedliche Pixel und Texelfüllraten. Dann spielte es auch noch eine Rolle welchen Filter man benutzt. Dann ... Früher war halt alles einfacher ;)

Nochmal es ging mir nur darum das es heute viel mehr Kenngrössen gibt was aber durch den fortschritt auf dem Gebiet nicht zu vermeiden war.

Heutzutage braucht ein vergleichbarer TBDR zu einen IMR, fast genauso viel Transistoren und Spezifikationen. Demirug's Idee klingt gut, nur leider kann niemand solche Details wissen, bis PVR ein neues Produkt veroeffentlicht. Daher kann es sein dass sie entweder gar keine aehnliche Methode haben, oder im Idealfall auf eine noch bessere Alternative in der Zwischenzeit gekommen sind. In Patenten nachstoebern hilft auch nicht viel, im besten Fall findet man nur dass was bis jetzt bekannt ist und es dauert auch viel zu lange bis Patente veroeffentlicht werden.

Ja in der Regel erst 2 Jahre nach Produktveröffentlichung.

Ich wage mich mal auf eine andere Art von Spekulation: wuerde ein TBDR heute NV30 als Konkurrenz entgegenstehen, muesste eine 3.2GTexels/sec Fuellrate auf einem 128bittigen bus genug sein.

Die Füllrate sollte reichen. Beim Coretakt müsste man bei gleicher Auslegung der VS aber auf NV30 Level gehen. Beim Speichertakt ist es schwer zu sagen in wie weit man dort möglichkeiten gefunden hat die Datenmenge für das Binning zu reduzieren.

[Ailuros]

Das mit dem NV30 Niveau war ja nur ein theoretisches Beispiel Demirug :)

[Quasar]

NVIDIA on Next Generation nForce and 120W+ GPUs (HARDWARE)
By Brian Neal
Wednesday, March 19, 2003 10:41 AM ESTAs Johan has already hinted, our CeBit report is on the way. But first, I'd like to take a moment to highlight some interesting information P4man has collected during his visit at CeBit regarding a new version of nForce featuring FX5200 graphics. NVIDIA also indicates that extremely high power GPUs are not out of the question. P4man's comments follow:

Had a good chat with the product manager of the nForce; very nice chap. He told me a few things: Incorporating a GF4 Ti engine was almost impossible, because it was too big to be economically feasable. Socketed GPU's on the motherboard where also a nice idea, but impossible due to space constraints, trace lenghts for the memory, and fact MB's usually only have 4 layers, as opposed to the 12(?) layers an FX Ultra requires.
Expect 120+W (!) GPUs to appear in the near future. Though nVidia was actively researching SOI and Germanium oxide (?) to reduce power requirements, he didnt expect it any time soon, saying the graphics market changes too fast to warrant that sort of investments for now. So nVidia was concentrating on cooling solution to be able to use that sort of power-hogs.


Very interesting indeed. For comparison, the current GeForce FX 5800 Ultra dissipates a maximum of 75W, while the Radeon 9700 Pro dissipates 54W (maximum). Will the power requirements of future GPUs outpace even the highest performance desktop processors, and if so, what kind of power and cooling solutions will be necessary to enable such high performance graphics chips?

Update: The accuracy of this information has come into question. This post will be updated accordingly as we get more details.

Ace's, Urheber dieses Gerüchtes, hat sich wohl ein wenig verschätzt und die News geradegerückt....
Nur, wie gesagt, der erste Eindruck ist hiermit geschaffen und bis der wieder aus den Köpfen raus ist... *ärger*

[ow]

Originally posted by Quasar


Ace's, Urheber dieses Gerüchtes, hat sich wohl ein wenig verschätzt und die News geradegerückt....
Nur, wie gesagt, der erste Eindruck ist hiermit geschaffen und bis der wieder aus den Köpfen raus ist... *ärger*

Die Info ist schon deshalb inaccurat, weil hier die 54 bzw. 75 Watt den GPUs zugerechnet werden. Die Bauteile und RAM will ich mal sehen, die keine Energie umsetzen.:D
Und btw. wurden diese Zahlen, die iirc von tecchannel sind, nirgendwo sonst bestätigt.

[Ailuros]

Und btw. wurden diese Zahlen, die iirc von tecchannel sind, nirgendwo sonst bestätigt.

Uebertrieben klingen beide Zahlen aber trotzdem nicht (R300/NV30); ueberhaupt wenn die GF4Ti schon an =/>40W verbraucht.

[Endorphine]

Originally posted by Ailuros
Uebertrieben klingen beide Zahlen aber trotzdem nicht (R300/NV30); ueberhaupt wenn die GF4Ti schon an =/>40W verbraucht. Auch der Wert stammt wieder von TecChannel - jetzt könnte man Verschwörungstheorien lostreten ;)

Bei der FX 5800 Ultra ist es aber auch ein spezieller Fall, da der Speicher allein schon ingesamt rund 30 Watt in Wärme umsetzt. Die GPU läuft auch am äussersten Limit, dann kommt noch die Leistungsaufnahme des Lüfters hinzu. Und dann wollen die einzelnen Bauteile auf der Karte auch noch stabil mit verschiedenen Spannungen versorgt werden. Wenn man das alles zusammenrechnet sind die 75 Watt noch relativ wenig aus meiner Sicht.

Die hohe Leistungsaufnahme ist ein konzeptbedingtes Problem. nVidia hat aus einer 128-Bit Speicheranbindung die Performance einer 256-Bit Speicheranbindung der Konkurrenz herausholen müssen. Dazu kommt noch, dass der NV30 an Rohleistung (4x2 TMUs?) spart, dafür anderswo zukunftsweisender als der R300 ist (Programmierbarkeit).

Der NV35 wird alles wieder geraderücken, da bin ich sehr zuversichtlich.

[robbitop]

wens interessiert :


Ausblick auf den NV35 (http://www.seijin.de/index2.php?page=Artikel/nv35speks.php) .

In einer kleinen aber simplen Benchmarksimulation haben wir einen NV35 mal in diesen Bench eingebracht.

@Endorphine

die 75W von Techchannel werden doch als Gesamtleistung der Karte gemassen (oder irre ich mich? )...bist du dir dessen sicher?

bist du dir auch sicher dass der Speicher 30W verbrät (is ne ganze Menge).

Wobei ich ehrlich gesagt dem kleinen R300 Kühler niemals 54W Abwärmeleistung zutraue. Wenn man bei CPU schaut, was da für Kühler notwendig sind um 50-70W zu kühlen....

[Unregistered]

Originally posted by robbitop
Wobei ich ehrlich gesagt dem kleinen R300 Kühler niemals 54W Abwärmeleistung zutraue.
Die 54W sind IIRC wiederum für die gesamte Karte zu sehen, die IMO auch vollständig zur Wärmeableitung genutzt wird (keine andere Karte, die ich bisher hatte, wurde an so vielen Stellen so warm. Bsw. Kühlblech auf der Rückseite, PCB, Teile der Spannungswander und auch das RAM).

Quasar@Work

[Demirug]

Endorphine, ich komme nur auf maximal 29.12 W für den Speicher. Der Durchsnitt sollte aber < 25 W sein.

robbitop, in deiner Festure-Liste habe ich zwei Fehler endeckt:

Gatter != Transistoren. Ein Gatter besteht in der Regel aus mehr als einem Transitor.

PS 1.4 sind keine Floatingpoint Shader

[robbitop]

danke Demi ;-)

[Ailuros]

Originally posted by Endorphine
Auch der Wert stammt wieder von TecChannel - jetzt könnte man Verschwörungstheorien lostreten ;)

Bei der FX 5800 Ultra ist es aber auch ein spezieller Fall, da der Speicher allein schon ingesamt rund 30 Watt in Wärme umsetzt. Die GPU läuft auch am äussersten Limit, dann kommt noch die Leistungsaufnahme des Lüfters hinzu. Und dann wollen die einzelnen Bauteile auf der Karte auch noch stabil mit verschiedenen Spannungen versorgt werden. Wenn man das alles zusammenrechnet sind die 75 Watt noch relativ wenig aus meiner Sicht.

Die hohe Leistungsaufnahme ist ein konzeptbedingtes Problem. nVidia hat aus einer 128-Bit Speicheranbindung die Performance einer 256-Bit Speicheranbindung der Konkurrenz herausholen müssen. Dazu kommt noch, dass der NV30 an Rohleistung (4x2 TMUs?) spart, dafür anderswo zukunftsweisender als der R300 ist (Programmierbarkeit).

Der NV35 wird alles wieder geraderücken, da bin ich sehr zuversichtlich.

Keine Ahnung ueber Verschwoerungstheorien, aber mein Klotz errr Leadtek A250 TD, sieht auch nicht nach weniger aus um ehrlich zu sein (schon mal deren "TwinTurbo" design von Leadtek auf NV25 gesehen?). Selbst 100W wuerden mir bei dem derzeitigen 400W Heralchi PSU wenig sorgen machen um ehrlich zu sein.

Ich hatte uebrigens immer den Eindruck dass NV30 auf low K 13nm ausgelegt war und dass NV dann auf high K 13nm umgestiegen ist. Wenn das tatsaechlich der Fall sein sollte, muesste natuerlich logischerweise das Problem mit NV35 nicht vorhanden sein. Uebrigens schaetze ich dass tecchannel NV30 mit dem ersten FX-Brummer gemessen hat.

[robbitop]

ja ersteinmal war der NV30 auf LowK Dielectric aus gelegt und 2. für 400Mhz Chiptakt.

Man munkelt eben, dass man, um konkurenzfähig bleiben zu können, die Ultra erschaffen hat (500Mhz)....

[Demirug]

aleine beim Speicher hat der wechsel von 400 auf 500 Mhz schon mal ca 5 Watt zusätzlich eingebracht.

[Endorphine]

Originally posted by robbitop
Die 75W von Techchannel werden doch als Gesamtleistung der Karte gemassen (oder irre ich mich? )...bist du dir dessen sicher?

bist du dir auch sicher dass der Speicher 30W verbrät (is ne ganze Menge).

Wobei ich ehrlich gesagt dem kleinen R300 Kühler niemals 54W Abwärmeleistung zutraue. Wenn man bei CPU schaut, was da für Kühler notwendig sind um 50-70W zu kühlen....
Ja, die Gesamtleistungsaufnahme der Karte wurde von TecChannel gemessen. Alles andere wäre wohl auch wenig praktikabel ;)

Der Speicher setzt insgesamt maximal knapp 30 Watt in Wärme um. Wenn man das als Designentscheidung berücksichtigt relativieren sich die insgesamt 75 Watt doch schon erheblich, das meinte ich ja... :)

Und wie Quasar schon sagte: die 54 Watt beim R300 Pro verteilen sich ganz gut.

[Endorphine]

Originally posted by Demirug
Endorphine, ich komme nur auf maximal 29.12 W für den Speicher. Der Durchsnitt sollte aber < 25 W sein.Sind doch rund 30 Watt. Eine Erbse ... und noch eine ;)

Bei der thermischen Belastung sollte man aus meiner Sicht immer vom worst-case ausgehen. Es nützt wenig, wenn man irgendwas dimensioniert, was auf Durchschnittswerte ausgelegt ist, und dann unter Dauerlast unter Bedingungen an der Spezifikationsgrenze Probleme auftreten.

Man kann nur hoffen, dass nVidia wirklich den Schritt zu DDR-I mit 256-Bit breiter Anbindung zurückgeht. Man sieht ja auf den 9700/9800ern sehr schön, dass dort der Speicher nicht mal passiver Kühlung bedarf.

Und dann kann man bei BGA ja auch die Platine zur Kühlung mitnutzen, wenn diese nicht schon durch die GPU zu heiss sein sollte. Ich vermute, dass beim NV30 die GPU schon derart viel Wärme an das PCB abgibt, dass diese den Speicher über die Kühlungsballs eher aufheizen als kühlen würde unter Last. Deshalb war die extreme Speicherkühlung beim NV30 wohl notwendig geworden.

[Demirug]

Endorphine, wenn ich richtig gelesen habe ist es technisch gar nicht möglich die Speicherchips so zu betreiben das sie ständig die 30 Watt ziehen. Es kann aber trotzdem sicher nicht falsch sein die Kühlung dafür auszulegen.

Was die ganze Kühlsituation angeht vermute ich fast mal das NVIDIA das sowohl von TSMC wie auch von Samsung etwas zu optimitische Aussagen bezüglich der Leistungsaufnahme bekomme hat.