-dp- Board

das deutsche PowerVR Forum
Aktuelle Zeit: 19 Sep 2018 20:04

Alle Zeiten sind UTC + 1 Stunde




Ein neues Thema erstellen Auf das Thema antworten  [ 109 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: 08 Nov 2003 04:02 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
Ailuros hat geschrieben:
Wie oft und wie lange hast Du persoenlich schon mit einer R3xx Spiele wirklich durchgespielt?

Nichts. Ich habe einen NV25, wie du weißt.

Ich weiß, dass das dumm klingt, aber ich sehe nunmal jeden "flaw". Auf Screenshots von Spielen fällt die AF-Winkelabhängigkeit auf, in Bewegung wird es wohl noch etwas schlimmer sein. Wie sehr das stört, ist dann eine individuelle Sache.

Meine Ansprüche an die Auflösung sind nicht so extrem, dafür verlange ich beste Texturen, und beste Kantenglätte (was ein NV25 allerdings nicht liefert.)

Ailuros hat geschrieben:
Was fuer entsprechende Logik und bei welcher Anzahl von Transistoren? Ich moechte genaue Details hoeren und nicht "was weiss ich" Stichpunkte oder schamlose Kopien von Kirk's Marketing-Geblubber.

Wieviele Transistoren Kyro für's HSR braucht, weiß ich nicht. Dass Transistoren für die HSR-Berechnung gebraucht werden (für die infinite Planes z.B., und für das Sammeln der Listen) steht ja außer Frage.

Nun magst du sagen, jahaa, Hyper-Z oder LMA verballern auch Transistoren. Das ist natürlich richtig. Auf der anderen Seite, bei einer MSAA-Pipe ist es nicht mehr sehr teuer, dann gleich noch Early Z zu integrieren. Z-Compression bzw. Color-Compression senken die erforderliche Bandbreite deutlich, afaik hat Kyro noch nicht komprimiert.

Ailuros hat geschrieben:
Es wird trotzdem Fuellrate gespart mit portal rendering.

Natürlich wird es das. Trotzdem sinkt der TBDR-Vorteil, je besseres HSR die Engine hat. Deferred Rendering darf z.B. nicht bedeuten, wenig Rohfüllrate zu bieten, weil sich das bei transparentem Overdraw rächt. First-Z-Pass-Engines haben abgesehen vom Z-Pass praktisch keinen opaquen Overdraw mehr (stimmt zumindest für GeForce nicht ganz, afaik ist das Early Z hier recht primitiv, da immer auf volle Quads beschränkt. Ob Radeon pixelgenaues Early-Z bietet, weiß ich nicht.)

Ailuros hat geschrieben:
NV30 hat eine theoretische Fuellrate von 4.0GigaTexels/sec (nicht trilinear). Nun vergleiche mal die gemessenen effektiven Fuellraten von NV30 oder NV35 gegen die realen Fuellraten die ein jeglicher R3xx erreicht. Nur ein Wort: Effizienz.

Für mich zählt nur noch trilineare Füllrate :)

Ailuros hat geschrieben:
Im gegebenen Fall ist nicht die Frage wie hoch die theoretische Fuellrate des NV40 auf Papier sein wird, sondern sein reale Fuellraten Effizienz.

Das ist auch eine wichtige Frage, ja. Zunächst möchte ich die Rohleistung, welche dann natürlich auch effizient eingesetzt werden muss.

Ailuros hat geschrieben:
Ich hab schon einen Vorschlag gemacht fuer ein interessantes zukuenftiges demo: ein flight sim demo mit extrem komplizierten und Polygon-reichem terrain, am Besten mit dynamischem LOD.

Hier wäre Displacement Mapping ideal :) Übrigens eine Technologie, für die ich Zukunft sehe. EMBM hat sich ja auch nicht gleich mit dem G200 durchgesetzt...


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 08 Nov 2003 05:38 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Zitat:
Ich weiß, dass das dumm klingt, aber ich sehe nunmal jeden "flaw". Auf Screenshots von Spielen fällt die AF-Winkelabhängigkeit auf, in Bewegung wird es wohl noch etwas schlimmer sein. Wie sehr das stört, ist dann eine individuelle Sache.


Au weia da muss ich gleich wieder nach Screenshots fragen und dazu noch vergleichbare auf NV2x oder NV3x. Screenshots von anderen Usern gibt es ja tonnenweise im Netz.

Ausser den Faellen die ich erwaehnte konnte ich bis jetzt keine Unterschiede weder auf screenshots oder in Bewegung sehen.


Zitat:
Wieviele Transistoren Kyro für's HSR braucht, weiß ich nicht. Dass Transistoren für die HSR-Berechnung gebraucht werden (für die infinite Planes z.B., und für das Sammeln der Listen) steht ja außer Frage.


32 Z/stencil units fuer KYRO und da Loewe sich schon darueber geaeussert hat, das naechste Ding "nur" zweimal so viel.

Zitat:
Z-Compression bzw. Color-Compression senken die erforderliche Bandbreite deutlich, afaik hat Kyro noch nicht komprimiert.


Wenn ich wuesste zu was FastColourCalculations in OGL dasteht, koennte ich Dir es auch beantworten. Zukuenftige Produkte werden mit Sicherheit in mehr als nur einer Stelle komprimieren. Aber selbst wenn zu was eigentlich Farben-Komprimierung mit MSAA auf einem TBDR?

Aus dem Eric Demers Thread bei 3DCenter:

Zitat:
In the case of tilers, the pixel color can be computed once and applied to the visible samples in the pixel based on the sample's z values. When the tile is done, the filter can be applied to the tile and the results written to the frame buffer.

On IMRs multisampling is best done using some version of the A buffer. In this case, triangle fragments (those portions of a triangle within a pixel) set the bits of a coverage mask with one bit per sample. A single color and z value is stored for the fragment. Since there are usually only one or two fragments in a pixel, this allows significant compression of the color and z data. For 8x AA it allows up to 4 to 1 compression without loss for two fragments.


Mit MSAA und hoeher als 4xAA ist das Problem heutzutage eher die Bandbreite, wobei ein TBDR keine Bandbreiten-Probleme selbst mit Supersampling hat.


Zitat:
Natürlich wird es das. Trotzdem sinkt der TBDR-Vorteil, je besseres HSR die Engine hat. Deferred Rendering darf z.B. nicht bedeuten, wenig Rohfüllrate zu bieten, weil sich das bei transparentem Overdraw rächt. First-Z-Pass-Engines haben abgesehen vom Z-Pass praktisch keinen opaquen Overdraw mehr (stimmt zumindest für GeForce nicht ganz, afaik ist das Early Z hier recht primitiv, da immer auf volle Quads beschränkt. Ob Radeon pixelgenaues Early-Z bietet, weiß ich nicht.)


Du kommst auch nur zu diesen Schlussvolgerungen weil Du Dich zu stark auf veraltete Produkte konzentrierst. TBDR hat weiterhin seine Vor- und natuerlich aus seine Nachteile, nur kommen mit einem dx9.0 chip noch ein paar Vorteile dazu die bisher nicht existierten; gilt genauso fuer die Nachteile.

Zitat:
Für mich zählt nur noch trilineare Füllrate.




a) Keiner weiss mit Sicherheit ob zukuenftige Produkte single cycle trilinear bieten werden (ausser DeltaChrome).

b) Ich klipp und klar einen Vergleich von existierender HW verwendete und zwar zwischen NV3x und R3xx.

Wobei ich auf meiner Behauptung bestehe dass Fuellraten-Effizienz um einiges wichtiger ist, als oede Nummern die nur auf Papier oder Theorie existieren. TBDRs hatten schon immer die hoechstmoegliche Effizienz mit Fuellraten und obwohl zu 3dfx Zeiten das "Fillrate is King" noch staerker als heute galt, werden zwar Fuellraten nicht an Wichtigkeit verlieren, aber arithmetische Effizienz wird mehr und mehr zunehmen an Wichtigkeit in der absehbaren Zukunft.

In der Abteilung war der NV3x ein absoluter Flop, und ich bezweifle allen Ernstes dass NV Zeit hatte seit Q1 2002 alles so hinzukriegen wie es sein sollte oder wo deren direkte Konkurrenz momentan liegt.

Zitat:
Hier wäre Displacement Mapping ideal Übrigens eine Technologie, für die ich Zukunft sehe. EMBM hat sich ja auch nicht gleich mit dem G200 durchgesetzt...


Ich sehe echtes und schnelles DM leider erst nach dem Advent von VS4.0 oder wie es auch immer heissen soll, also auf keinen Fall vor 2006.

Zitat:
Es ist keinesfalls so, dass TBDR ein Allheilmittel sei.


IMR aber auch nicht. Wie konnten IMRs durch die Jahre ueberleben? In dem sie Bandbreiten schonende Techniken akzeptierten. War das nicht schon immer das Grund-Prinzip eines DR? Wenn ich in privaten Besprechungen mit den einem oder anderem IHV mal spekuliere dass wir irgendwann mal zu einem Punkt kommen wo es schwerer sein wird TBDR von IMR zu unterscheiden, verteidigt der jeder seine eigene Methode natuerlich. Fuer mich ist nicht alles schwarz und weiss. Wenn ich was gern habe dann ist es gute Ideen zu adoptieren und sei Dir sicher dass sich IMR staendig ein bisschen was von TBDR Techniken abschielen, genauso aber auch anders rum. Ein bisschen zu stark vereinfacht, aber so weit weg von der Realitaet ist es nun auch wieder nicht.

***edit:

Zitat:
Q11: We've seen traditional renderers increase quite a bit lately in efficiency, especially those architectures that have included combinations of clever bandwidth saving techniques, some going even as far to tout a memory tiling approach (see XP4/Trident) or deferred rendering through a traditional pipeline (P9/3DLabs).

Do you see IMR's becoming as or almost as efficient over time as TBR's in departments where they have advantages? Could you see in the future a possibility of some sort of amalgamations of architectures, up to the point where it will be difficult for a layman to tell what is a Tiler and what not?


Zitat:
Tiling seems to be a word that Marketing People associate with efficiency so they try to include it wherever possible. Usually the tiling that is referred to is actually nothing more than a tile based memory layout, where rendering is done by splitting a triangle up in tile areas. So in effect the triangle is rendered tile by tile, rather than scan line per scan line, which has a positive effect on caching. This technique is not new and was AFAIK already supported by the age-old Voodoo cards; it seems like marketing is just now starting to hype this basic functionality.

I have not yet seen any independent reviews of the Trident XP4 or the 3Dlabs P9; I am looking forward to some VillageMark numbers to see if there is any real efficiency improvement on these so-called tile-based or deferred renderers.


http://www.pvrgenerations.co.uk/cgi-bin ... &pagenum=3


Zitat:
Mit unoptimiertem Rendering habe ich mal in OpenGL meine GF4 Ti 4600 mit lächerlichen 10000 Vertices in die Knie gezwungen.


Dabei behaupten die Papier-specs wieviel nochmal?


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 09 Nov 2003 14:08 
Offline
User
Benutzeravatar

Registriert: 29 Aug 2001 19:58
Beiträge: 616
aths hat geschrieben:
MTB-ThePsycho hat geschrieben:
nochmal zum mitschreiben:
es ist - meiner auffassung nach - nicht aufgabe der engine, das rendering zu optimieren

hier hast du mich falsch zitiert - nur nebenbei, möchte dir keine absicht unterstellen
Zitat:
Meiner Meinung nach ist es auf alle Fälle auch die Aufgabe der Engine. Man optimiert auch Software für CPUs. Das gute ist, dass die Optimierung im Vorhinein geschieht, und dann auf der CPU bzw. GPU keine extra Optimierungs-Transistoren braucht. Der Aufwand der Programmierung steigt, aber die "Leistung pro Hardware" auch. Siehe z.B. P4, der auf spezielle Optimierung gleich beim Programmieren angewiesen ist — optimierte Software ist dann tatsächlich rasend schnell. Natürlich sollte die Graka der Engine helfen, wo sie nur kann.

ein schlechter vergleich. software wird eigentlich nicht von den programmierern, sondern vom kompiler optimiert.
natürlich kann man programme nun so schreiben, dass sich der kompiler beim optimieren leichter tut, aber auch das ist nicht der eigentliche sinn der sache.
Zitat:
Der First-Z-Pass z.B. ist ja eigentlich "nur" für korrektes Shading notwendig, dank Early Z wird nebenbei noch der Overdraw reduziert. Das hoch trabend "Ultra Shadow" genannte Feature im NV35 ist auch ein Zugeständis an Engines. TBDR ist logischerweise nicht nutzlos, sondern schön — was aber nicht heißt, dass sich der Programmierer deswegen zurücklehnen kann, oder das Rendering gleich optimal sei. Optimiert werden muss sowieso, was fast immer auch erhöhte CPU-Last bedeutet.

nun gut, so gesehen sieht das natürlich anderst aus.
ich gebe zu mich mit etwas zuviel unwissen zuweit aus dem fenster gelehnt zu haben.
Zitat:
Es gibt weitaus mehr Möglichkeiten, eine Engine zu verschnellern, als den opaquen Overdraw zu senken. TBDR adressiert ja praktisch nur dieses Problem. TBDR bringt neue Abhängigkeiten mit sich, man muss auf einen TBDR anders optimieren für das bestmögliche Ergebnis. Es ist keinesfalls so, dass TBDR ein Allheilmittel sei.

nun, es reden hier immer alle von nachteilen bei TBDRs. nur welche sind das denn genau ? das würde mich jetzt schonmal interessieren
Zitat:
Gute Engines sind seit Jahren so weit, dass sie ausgeklügelte Mechanismen haben, unnötiges möglichst nicht zu rendern. Das kostet zunächst CPU-Power, senkt diese an anderer Stelle aber auch.

diesen zusammenhang habe ich übersehen, ja.
allerdings finde ich dieses "filtern" nur solange vertretbar, wie CPU-power unterm strich gespart wird - alles andere sollte logik der grafikkarte bleiben
Zitat:
Kein Prozessor macht "Z-Tests". HSR kann wie gesagt die CPU-Last an anderer Stelle auch wieder senken.

du weisst was ich sagen wollte, ansonsten siehe oben

_________________
Du willst Respekt? Knie nieder und bettle darum!

http://www.notcpa.org
http://www.bpjs-klage.de

http://www.ccc.de/campaigns/boycott-musicindustry
Bild


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 10 Nov 2003 19:20 
MTB-ThePsycho hat geschrieben:
ein schlechter vergleich. software wird eigentlich nicht von den programmierern, sondern vom kompiler optimiert.
natürlich kann man programme nun so schreiben, dass sich der kompiler beim optimieren leichter tut, aber auch das ist nicht der eigentliche sinn der sache.


hoffe das zitieren hat geklappt :)
@psycho: naja, es gibt beim Programmieren immer mehr Wege, ans Ziel zu gelangen. Und wenn man hier den ressourcenschonendsten auswählt hilft das schon sehr viel, bzw. wenn man am Algorythmus herumfeilt. Ich verstehe zwar fast nichts von dem was ihr in diesem Thread schreibt, und ich hab auch noch keine Engine geschrieben, aber zumindest bei normalen Programmen trifft das zu. Und ich denk mir mal das ist bei Spielen nicht anders.
mfg
Flipper


Nach oben
  
 
 Betreff des Beitrags:
BeitragVerfasst: 11 Nov 2003 09:04 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
Ailuros hat geschrieben:
Ausser den Faellen die ich erwaehnte konnte ich bis jetzt keine Unterschiede weder auf screenshots oder in Bewegung sehen.

Dann guck mal genau hin :naughty: Wenn du keine Unterschiede siehst, g00d. Wenn du die Güte hättest, bei 16:1-AF einem Shooter den Boden in einem 22°-Winkel zu betrachten, würdest du dort nur 2:1-AF sehen. Du wirst vielleicht sagen, sowas kommt bei Shootern kaum vor. Stimmt ja auch. Für das meiste ist ATIs Lösung ausreichend. Mich stört jedoch, dass man auf 90°- und 45°-Winkel gebunden ist für maximale Anisotropie. Bei einem sich drehendem Tunnel sieht man das, da sieht man wenn man will sogar die 45°-Winkelabhängigkeit bei 8:1-AF auf GeForce-Karten...

Wenn du mit ATIs AF zufrieden bist, will ich dir das natürlich nicht ausreden. Meine Ansprüche ans AF sind anders. Ich will Lehrbuch-Qualität, was bei >2:1 im Moment meines Wissens keiner anbietet.

Ailuros hat geschrieben:
Aber selbst wenn zu was eigentlich Farben-Komprimierung mit MSAA auf einem TBDR?

Spart Bandbeite.

Ailuros hat geschrieben:
Mit MSAA und hoeher als 4xAA ist das Problem heutzutage eher die Bandbreite, wobei ein TBDR keine Bandbreiten-Probleme selbst mit Supersampling hat.

Supersampling kostet ja auch eher Füllrate :naughty: Supersampling wird teuer, wenn du längere Shader hast. Bandbreite kosten lange arithmetische Shader hingegen fast keine... ich denke, MSAA wird sich auch auf TBDR durchsetzen. Dann steigt die Bandbreitenforderung im Vergleich zu No-AA. Komprimierung hilft, selbst wenn es nur solche Framebuffer-Pseudo-"Komprimierung" ist, die ATI und Nvidia derzeit anbieten. (Ansonsten könnte man auch argumentieren, wozu denn effizient die Füllrate mit TBD-Rendering nutzen, wenn Füllrate eh genug da ist...)

Ailuros hat geschrieben:
Du kommst auch nur zu diesen Schlussvolgerungen weil Du Dich zu stark auf veraltete Produkte konzentrierst. TBDR hat weiterhin seine Vor- und natuerlich aus seine Nachteile, nur kommen mit einem dx9.0 chip noch ein paar Vorteile dazu die bisher nicht existierten; gilt genauso fuer die Nachteile.

Nachteile soweit ich weiß z.B. bei "ungleichen" Shadern.

Ailuros hat geschrieben:
a) Keiner weiss mit Sicherheit ob zukuenftige Produkte single cycle trilinear bieten werden (ausser DeltaChrome).

Ist mir egal, dann zähle ich halt die halbe bilineare Füllrate, um die trilineare zu haben (obwohl diese Rechnung ja leicht zu pessimistisch ist, da bei Vergrößerungen ohnehin nur BF genommen werden kann.) BF inkl. "brilinear" halte ich 2003 für eine Zumutung. Nvidia zählte bei GF2 z.B. die Füllrate auch nur die für 16-Bit-Rendering. Ich verwende lieber Zahlen, die für 32-Bit-Rendering zutreffen.

Ailuros hat geschrieben:
b) Ich klipp und klar einen Vergleich von existierender HW verwendete und zwar zwischen NV3x und R3xx.

Wobei ich auf meiner Behauptung bestehe dass Fuellraten-Effizienz um einiges wichtiger ist, als oede Nummern die nur auf Papier oder Theorie existieren. TBDRs hatten schon immer die hoechstmoegliche Effizienz mit Fuellraten und obwohl zu 3dfx Zeiten das "Fillrate is King" noch staerker als heute galt, werden zwar Fuellraten nicht an Wichtigkeit verlieren, aber arithmetische Effizienz wird mehr und mehr zunehmen an Wichtigkeit in der absehbaren Zukunft.

Das ist halt quasi "arithmetische Füllrate" :D

(Was Effizienz angeht: Hatte ich schon den First-Z-Pass im Zusammenhang mit Early-Z-Occlusion erwähnt...??)

Ailuros hat geschrieben:
In der Abteilung war der NV3x ein absoluter Flop, und ich bezweifle allen Ernstes dass NV Zeit hatte seit Q1 2002 alles so hinzukriegen wie es sein sollte oder wo deren direkte Konkurrenz momentan liegt.

ATI bot mit R100 und R200 die Features, NV bot mit NV15 und NV25 die Leistung. Mit dem R300 bietet ATI die Leistung, NV (ab NV30) die Features. Ok, diese Betrachtung ist etwas sehr vereinfacht.

Aber, von den Möglichkeiten her wirken die R300-Shader gegenüber CineFX geradezu antik. R3xx ist eine Hardware nur für hier und jetzt, weder die 4 Ebenen der Abhängigkeit, noch der Instructioncount, noch FP24 haben Zukunft. (FP32 für Texture-Ops bietet schon GF3.) Die ersten DX9-Enginges wurden auf ATI-HW geproggt (da keine andere HW verfügbar) aber ich bin nicht wirklich nicht sicher, ob die Engines, die wir in 1-2 Jahren sehen werden, noch überwiegend auf Radeon geproggt werden.

Zum anderen Teil deines Postings (nicht gequotet): Scanline basiertes Rendering ist der Tod jeden Caches, das ist klar. In mehreren Ebenen wird längst viel stärker TBR gemacht, als einige vermuten. Weiterhin wird aber Dreieck für Dreieck gerendert, während der TBDR ja Kachel für Kachel rendert. Beide Ansätze haben Vor- und Nachteile, und beide Techniken werden ähnlicher, ja. Unter dem Gesichtspunnkt der Füllrateneffizienz ist kachelweises deferred Rendering im Vorteil. Das wird auch so bleiben. Natürlich gilt es, das Gesamtpaket zu betrachten. Angenommen, Series5 kann pro Takt 8 arithmetische Pixelshader-Ops ausführen. Das wäre einfach zu wenig.

NV40 wird vermutlich mit 8x2 TMUs kommen, und bei FP32 pro Takt 16 arithmetische Ops ausführen können. Vielleicht mit FP16 sogar 32 Ops. Da kann Series5 noch so effizient sein, bei First-Z und Early Z Occlusion würde ich den Anteil an opaquem Shading-Overdraw auf 20-30% schätzen. Das holt Series5 mit 8 Shader-Ops pro Takt nicht raus. Diese 8 Ops sind natürlich reine Spekulation, gleiches gilt für NV40.

Zur Bandbreiten-Problematik: Je länger und je aritmetischer die Shader, desto weniger durchschnittliche Bandbreite fällt pro Takt an. Deshalb wird NV40 mit 256-Bit-DDR-Interface noch gut klar kommen. (Sollte wider erwarten auch NV40 noch auf HRAA setzen, kommt dieser Chip für mich natürlich nicht infrage.)

Ailuros hat geschrieben:
Dabei behaupten die Papier-specs wieviel nochmal?

136 Mio. Diese Zahl ist allerdings nicht messbar, nur ausrechenbar, und gilt nur unter der Annahme bestimmter Vereinfachung beim Transformieren, und natürlich ohne Lighting.


Zuletzt geändert von aths am 11 Nov 2003 10:08, insgesamt 6-mal geändert.

Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 11 Nov 2003 09:44 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
MTB-ThePsycho hat geschrieben:
hier hast du mich falsch zitiert - nur nebenbei, möchte dir keine absicht unterstellen

Es ist natürlich nicht meine Absicht, falsch zu zitieren. Aber ich weiß noch immer nicht, wo ich was falsch zitiert / verstanden habe (bin manchmal schwer von Begriff.)

MTB-ThePsycho hat geschrieben:
ein schlechter vergleich. software wird eigentlich nicht von den programmierern, sondern vom kompiler optimiert.
natürlich kann man programme nun so schreiben, dass sich der kompiler beim optimieren leichter tut, aber auch das ist nicht der eigentliche sinn der sache.

Hm. Ich schreibe gerade ein 2D-Fraktal-Renderer mit dem C++ Builder (da wir für dieses spezielle Fach kein Delphi nehmen dürfen.) Wenn man C++ (oder C) nimmt, muss man mehr mitdenken. Zum Problem: Aus einem TImage-Objekt soll eine Palette erzeugt werden. Die Paletten-Auslese-Routine muss in der Variablenliste ein TImage übergeben bekommen. Ich bekam den Tipp, doch bitteschön das Call by Value sein zu lassen und gefälligst Call by Reference zu nutzen. Eigentlich peinlich, schon mal solche einfachen Optimierungs-Dinge zu übersehen (weil ich aufgrund Unkenntnis nach Möglichkeit vermeide, mit Pointern zu arbeiten.) Der Compilier kompiliert natürlich meinen Source auch, wenn ich Call by Value nehme; nur dass dann zur Laufzeit für jeden Zugriff schön die ganze Objekt-Instanz einmal durch den Speicher geschoben werden muss...

Aus der Praxis könnte ich weitere Beispiele anführen, wo eine meiner glorrenreichen Ideen für quasi nix die CPU unnötig belastet, und was der Compilier prinzipiell nicht wegoptimieren kann.

Zum 3D-Rendering: Man kann mit Vertex Buffern einige Dinge erheblich beschleunigen. Woher soll die Graka wissen, was gebuffert werden sollte? Die kann einen kleinen Cache anbieten (was auch so gemacht wird) aber der Programmierer muss mitdenken und wissen, wie die Hardware konkret arbeitet. Ansonsten kann man in ungünstigen Fällen Größenordnungen an Performance verlieren. Die Graka kann nicht in die Zukunft sehen. Der Programmierer weiß eher, in welcher Reihenfolge was kommen wird. Dementsprechend kann er daraufhin optimieren. In der Praxis kannst du dich als Entwickler einer Enginge z.B. an Nvidias Developer Support werden, die kontrollieren mit ihrem Insider-Wissen, wo der Flaschenhals ist und machen Vorschläge, wie sich die Performance (auf GeForce-Karten) steigern lässt.

MTB-ThePsycho hat geschrieben:
nun, es reden hier immer alle von nachteilen bei TBDRs. nur welche sind das denn genau ? das würde mich jetzt schonmal interessieren

Ein Beispiel: Wenn Tile für Tile gerendert wird, muss öfter mal die Textur / der Shader gewechselt werden. Das kostet Takte, und zwar nicht schlecht... In gewissem Sinne sind IMR längst auch TBR (nur halt keine TBDR). Das hat Vor- und Nachteile, wobei offensichtlich die Vorteile überwiegen.

Sprechen wir von konkreter HW: Kyro2 hat 350 Megatexel Rohfüllrate. GF2 Pro hat (bei 32-Bit-Rendering) 800 Megatexel. Normalerweise ist der opaque Overdraw so hoch, dass die Kyro2 durch effizientere Füllraten-Nutzung das ausgleichen kann. Anders z.B. bei großflächigem halbtransparentem Overdraw (Rauch usw.) wo die Kyro nur wenig sparen kann, dann zahlt sich die brutale Rohfüllrate der GF2 aus. TBDR darf imo nicht heißen, nur wenig Rohfüllrate zu bieten, weil die DR-Effizienz nicht immer ausgespielt werden kann. Von Series5 erhoffe ich eine Beachtung dessen :)

Natürlich, insgesamt spielte Kyro2 doch eher in der GF2 GTS-Liga und war einfach "zu gut", um nur die MX herauszufordern, auch wenn einige Magazine das nicht eingesehen haben, sie hätten ja einfach mal ein paar Benches fahren können... Es geht mir hier nur um die Sache, dass TBDR natürlich kein Allheilmittel ist, bei halbtransparentem Overdraw z.B. kommt es auf die "echte" Füllrate an. Dank First-Z-Pass und Early-Z-Occlusion wird der opaque, also "wegrechenbare" Overdraw-Teil in Zukunft bei IMRs deutlich sinken, ein Grund mehr, warum ein TBDR nicht an der Rohfüllrate sparen darf.

Über Kyro2 würden wir anders reden, wenn es einen Nachfolger (Series4) rechtzeitig gegeben hätte; wäre GF2 das letzte Produkt von NV gewesen... du verstehst, worauf ich hinaus will :) So erstaunlich Kyro war (mit wenigen MHz und Pipes, und den langsamen SDR-SDRAM solche Praxis-Leistungen zu bringen) was hat sie bewirkt? ATI hat mit dem R300 mal kurz den HighEnd-Markt umgekrempelt, und NVs bis auf die Knochen blamiert...

MTB-ThePsycho hat geschrieben:
allerdings finde ich dieses "filtern" nur solange vertretbar, wie CPU-power unterm strich gespart wird - alles andere sollte logik der grafikkarte bleiben

Ich halte optimieren, auch HSR-Optimierungen, für solange für sinnvoll, wie die Grafik insgesamt schneller wird. Erhöhte CPU-Last ist imo hinnehmbar, wenn das Spiel unter'm Strich schneller läuft. Was kostet, sind gar nicht mal so texturierte und später dann übermalte Flächen, eher kosten neue Objekte: Dazu sind neue Vertex-Daten zu benutzen, meist ist eine neue Textur zu laden (die erst mal in den Cache muss), und man muss Renderstates ändern... Soweit ich weiß, geht die Entwicklung u. a. dahin, dass die Graka die CPU dabei unterstützt, welche Objekte sichtbar sind. Afaik ist die Technik (eingeführt mit GF3) aber noch im "Deferred"-Stadium, die CPU weiß also immer nur über das letzte Frame bescheid. Das kann man nur für "träge" Effekte wie Coronas nehmen, ansonsten riskiert man Object Popping. Letztlich wird das immer "deferred" bleiben (geht aus Kausalitätsgründen ja gar nicht andern) nur dass eben ein Deferred Renderer sich das eher zunutze machen kann, als ein Immediate Renderer.

MTB-ThePsycho hat geschrieben:
du weisst was ich sagen wollte, ansonsten siehe oben

Woher soll ich das wissen? :) "Z-Test" ist eine genau definierte Sache, womit die CPU aber nichts zu tun hat. Während Indoor-Engines schon sehr gut optimiert sind, gibts für Outdoor-Engines noch einiges zu tun, da ließen sich einige Lorbeeren verdienen. Also, frisch ans Werk :)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 11 Nov 2003 16:11 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Zitat:
Wenn du mit ATIs AF zufrieden bist, will ich dir das natürlich nicht ausreden. Meine Ansprüche ans AF sind anders. Ich will Lehrbuch-Qualität, was bei >2:1 im Moment meines Wissens keiner anbietet.


Jegliche Form von adaptivem AF = Leistungs-optimierte Loesung. Ich wuerde auch liebend gerne high sample sparse grid Supersampling mit reinem winkel-unabhaengigem high sample AF kombiniert in sehr hoehen Aufloesungen haben, aber Leistung ist leider mal ein wichtiger Faktor.

Wobei es laecherlich ist IMO die negativen tradeoffs von MSAA die fuer bessere Leistung aufgeopfert werden zu uebersehen, und ueber AF zu meckern. Wuerden IHVs heute winkel-unabhaengiges non-adaptive AF benutzen, waeren Fuellraten bzw. Leistung schnell wieder auf SSAA Niveau.

Man kann nicht alles haben und es gibt einen gigantischen Unterschied zwischen Theorie und/oder Wunschdenken und realisierbaren Methoden. Und nein das mit 22 gradigen Winkeln in FPS Spielen ist Schmarren.


Zitat:
Spart Bandbeite.


Siehe nochmal vorigen Post. Wenn SSAA Bandbreiten-frei auf TBDR ist (wo nochmal Colour compression so gut wie nichts bringt), dann ist fuer MSAA auf einem TBDR theoretisch nicht unbedingt notwendig. Fuer andere Situationen vielleicht schon aber nicht unbedingt fuer MSAA.

Zitat:
Supersampling wird teuer, wenn du längere Shader hast.


Devil's Advocate: und MSAA verliert an Nutzen wenn Polygone kleiner werden. So kleine Polygone und so lange Shader sind ja direkt um die Ecke. Ich sehe immer noch dx7 Spiele dort draussen...


Zitat:
Bandbreite kosten lange arithmetische Shader hingegen fast keine... ich denke, MSAA wird sich auch auf TBDR durchsetzen.


Wieso? Ich moehte erinnern das es sich hier nur um eine rein theoretische Debatte handelt.

Zitat:
Nachteile soweit ich weiß z.B. bei "ungleichen" Shadern.


Wie oft muss ich noch sagen, dass auf einem TBDR VS und PS total entkoppelt sind? Wenn Du jetzt shader task switching meinen solltest, die Loesungen sind hier mehr als nur einfach. Hier wiegen sich die Vor- und Nachteile mehr oder weniger genauso aus wie auf einem IMR.

Zitat:
(Was Effizienz angeht: Hatte ich schon den First-Z-Pass im Zusammenhang mit Early-Z-Occlusion erwähnt...??)


Und wie unmoeglich ist eine early-Z abartige Implementierung auf einem TBDR?

Zitat:
ATI bot mit R100 und R200 die Features, NV bot mit NV15 und NV25 die Leistung. Mit dem R300 bietet ATI die Leistung, NV (ab NV30) die Features. Ok, diese Betrachtung ist etwas sehr vereinfacht.


Wo Du bei NV30 die "features" siehst ist mir fremd. Mit nutzlosen checkboard features kann jeder rechnen.

Zitat:
R3xx ist eine Hardware nur für hier und jetzt, weder die 4 Ebenen der Abhängigkeit, noch der Instructioncount, noch FP24 haben Zukunft. (FP32 für Texture-Ops bietet schon GF3.)


Es wird weiterhin variable Werte fuer interne Praezision fuer noch einige Zeit geben. Wenn die Zeit fuer sehr starke FP32 kommt, kann NV3x wohl gar nichts mehr damit anfangen. Natuerlich wenn man alles sehr einseitig sieht dann ist NV3x die Ueberloesung die aber leider nur auf Papier existiert. NV soll sich erstmal sorgen machen ueber MRT bzw MET oder HDR Unterstuetzung; FP32 ist nur fuer Angeber-rechte fuer die heutigen dx7 + ein paar oede dx9 Effekte Zeitraum.

Angenommen ATI unterstuetzt auch weiterhin FP24 und fuegt FP32 noch hinzu, wer hat dann den Vorteil theoretisch?

Zitat:
Angenommen, Series5 kann pro Takt 8 arithmetische Pixelshader-Ops ausführen. Das wäre einfach zu wenig.


Wir werden sehen.

Zitat:
NV40 wird vermutlich mit 8x2 TMUs kommen, und bei FP32 pro Takt 16 arithmetische Ops ausführen können. Vielleicht mit FP16 sogar 32 Ops. Da kann Series5 noch so effizient sein, bei First-Z und Early Z Occlusion würde ich den Anteil an opaquem Shading-Overdraw auf 20-30% schätzen. Das holt Series5 mit 8 Shader-Ops pro Takt nicht raus. Diese 8 Ops sind natürlich reine Spekulation, gleiches gilt für NV40.


Und dazu noch theoretische Spekulation, ohne jegliche handfeste Daten. Aus der Luft greifen kann ich auch viel.

Ich moechte jetzt nicht alles schwarz mahlen aber sehr viele von Euch ueberschaetzen mal wieder NV40, und dass soll jetzt nicht in Relation zur Serie5 gesehen werden. Auf Papier sieht alles toll aus, deshalb bestehe ich darauf dass es weiser ist auf unabhaengige Tests/Analysen nach release zu warten und dann zu sehen wo und wieviele Leichen jeder im Keller hat. Ich betone hier aber nochmal dass ich trotz allem keinen "NV40-Killer" erwarte oder es sogar im Raum des moeglichen halte.

Zitat:
Zur Bandbreiten-Problematik: Je länger und je aritmetischer die Shader, desto weniger durchschnittliche Bandbreite fällt pro Takt an. Deshalb wird NV40 mit 256-Bit-DDR-Interface noch gut klar kommen. (Sollte wider erwarten auch NV40 noch auf HRAA setzen, kommt dieser Chip für mich natürlich nicht infrage.)


Zitat:
By the way, just thought it was a good time to mention that deferred rendering tilers have a big advantage over IMRs for high precision floating point pipelines (as most here already know).

The major problem with floating point textures and pixel pipelines at the moment is that they do not implement what has become the essential features of the integer pipeline (texture filtering, antialiasing, etc.). This substantially limits their usefulness as a general pipeline for realtime 3d graphics. They are, however, very useful for offline work where filtering can be done in (shader) software and performance is not an issue. They are also currently useful for some specialized realtime pixel shaders.

With integers it is easy to implement a large amount of computation directly in hardware in parallel. Floating point requires far more transistors to implement. As a result, it makes no sense to dedicate all those transistors to fixed functions. Allocating all those transistors to floating point only makes sense if you make the pipeline programmable.

The problem is that while you might do dozens of operations in parallel in a single clock per pipe for integer vectors, you are generally limited to as little as one (or a few) for floating point.

This was a lesson learned long ago for other types of hardware. As soon as you increase the sophistication of the data types and the computations, direct hardware implementation is no longer feasible. You must rely on software. As soon as you do this the entire hardware design picture changes dramatically. It becomes extremely important to maximize frequency, data availability, and software computation parallelism to squeeze the most out of all those transistors in each pipe. Since you can perform far fewer operations per pipe per cycle, you must increase the number of cycles and the number of pipes dramatically.

In the future, I expect to see much more emphasis on frequency and the number of pipelines than in the past.


http://www.beyond3d.com/forum/viewtopic ... t%2A#61943

Zitat:
136 Mio. Diese Zahl ist allerdings nicht messbar, nur ausrechenbar, und gilt nur unter der Annahme bestimmter Vereinfachung beim Transformieren, und natürlich ohne Lighting.


Noe nur theoretische PR-Quatsch Nummern, was aber bei NV normal ist. 136M vertices vielleicht mit wireframe oder etwas das verdammt nahe an wireframe kommt, also bitte....


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 11 Nov 2003 16:25 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Zitat:
Sprechen wir von konkreter HW: Kyro2 hat 350 Megatexel Rohfüllrate. GF2 Pro hat (bei 32-Bit-Rendering) 800 Megatexel. Normalerweise ist der opaque Overdraw so hoch, dass die Kyro2 durch effizientere Füllraten-Nutzung das ausgleichen kann. Anders z.B. bei großflächigem halbtransparentem Overdraw (Rauch usw.) wo die Kyro nur wenig sparen kann, dann zahlt sich die brutale Rohfüllrate der GF2 aus. TBDR darf imo nicht heißen, nur wenig Rohfüllrate zu bieten, weil die DR-Effizienz nicht immer ausgespielt werden kann. Von Series5 erhoffe ich eine Beachtung dessen.


Nochmal das Problem von KYRO liegt primaer im vertex data throughput Bereich, das zu diesem Zeitpunkt fast den ganzen Effizienz-Vorteil von KYRO gegenueber GF2 GTS z.B. eliminierte.

KYRO bricht viel weniger mit Rauch ein als eine GF2 mit stencil ops. Wie war das nochmal mit den Vor- und Nachteilen? Ach ja die fehlenden cube maps und T&L sollte man auch nicht vergessen.

Zitat:
Über Kyro2 würden wir anders reden, wenn es einen Nachfolger (Series4) rechtzeitig gegeben hätte; wäre GF2 das letzte Produkt von NV gewesen... du verstehst, worauf ich hinaus will So erstaunlich Kyro war (mit wenigen MHz und Pipes, und den langsamen SDR-SDRAM solche Praxis-Leistungen zu bringen) was hat sie bewirkt? ATI hat mit dem R300 mal kurz den HighEnd-Markt umgekrempelt, und NVs bis auf die Knochen blamiert...


Quatsch. Nochmal ST Micro haette die K2 nie veroeffentlichen sollen und anstatt die erste 175MHz K3 Variante in Q1 2001. Danach haette man leicht auf 13nm gehen koennen um 250-300MHz zu erreichen. Selbst dann haetten sie eine groessere Anzahl von Karten verkauft, aber nur ein paar Prozent von NV's oder anderen IHV's Verkaufsvolumen abgehackt.

Market-penetration passiert nicht von einem Tag auf den anderen und fuer effektive Konkurrenz braucht man eine volle top to bottom Produktlinie.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 11 Nov 2003 19:22 
Offline
User
Benutzeravatar

Registriert: 29 Aug 2001 19:58
Beiträge: 616
aths hat geschrieben:
MTB-ThePsycho hat geschrieben:
hier hast du mich falsch zitiert - nur nebenbei, möchte dir keine absicht unterstellen

Es ist natürlich nicht meine Absicht, falsch zu zitieren. Aber ich weiß noch immer nicht, wo ich was falsch zitiert / verstanden habe (bin manchmal schwer von Begriff.)

eigentlich nichts grosses: der satz "nochmal zum mitschreiben" gehört zu einer anderen textstelle
dadurch liest sich ein falscher tonfall heraus

Zitat:
Hm. Ich schreibe gerade ein 2D-Fraktal-Renderer mit dem C++ Builder (da wir für dieses spezielle Fach kein Delphi nehmen dürfen.) Wenn man C++ (oder C) nimmt, muss man mehr mitdenken. Zum Problem: Aus einem TImage-Objekt soll eine Palette erzeugt werden. Die Paletten-Auslese-Routine muss in der Variablenliste ein TImage übergeben bekommen. Ich bekam den Tipp, doch bitteschön das Call by Value sein zu lassen und gefälligst Call by Reference zu nutzen. Eigentlich peinlich, schon mal solche einfachen Optimierungs-Dinge zu übersehen (weil ich aufgrund Unkenntnis nach Möglichkeit vermeide, mit Pointern zu arbeiten.) Der Compilier kompiliert natürlich meinen Source auch, wenn ich Call by Value nehme; nur dass dann zur Laufzeit für jeden Zugriff schön die ganze Objekt-Instanz einmal durch den Speicher geschoben werden muss...

Aus der Praxis könnte ich weitere Beispiele anführen, wo eine meiner glorrenreichen Ideen für quasi nix die CPU unnötig belastet, und was der Compilier prinzipiell nicht wegoptimieren kann.

auch @flipper
nagut, erwischt, wieder etwas zu eng betrachtet

das eigentliche thema war aber auch ein anderes, aber darum gehts weiter unten
Zitat:
Es geht mir hier nur um die Sache, dass TBDR natürlich kein Allheilmittel ist, bei halbtransparentem Overdraw z.B. kommt es auf die "echte" Füllrate an. Dank First-Z-Pass und Early-Z-Occlusion wird der opaque, also "wegrechenbare" Overdraw-Teil in Zukunft bei IMRs deutlich sinken, ein Grund mehr, warum ein TBDR nicht an der Rohfüllrate sparen darf.

hier stellt sich die frage, ob die transparenz-effektze nicht etwas überbewertet werden
dass aber ein TBDR nicht an füllrate sparen sollte ist klar, man sollte jedoch auch eines bedenken:
die kyro2 hatte zwar nur 350 MTexel/s, jedoch ist der chip von 99 (oder 98 ?) - damals waren diese 350 MTexel/s noch deutlich mehr
was ich damit sagen will: man sollte aufgrund eines vergleiches kyro2 <-> geforce2 nicht schliessen, dass ein TBDR automatisch weniger füllrate haben muss
die beiden chips waren zwar die direkten konkurrenten, wurden aber zu verschiedenen zeiten entwickelt
Zitat:
Ich halte optimieren, auch HSR-Optimierungen, für solange für sinnvoll, wie die Grafik insgesamt schneller wird. Erhöhte CPU-Last ist imo hinnehmbar, wenn das Spiel unter'm Strich schneller läuft.

nun, das ist wohl meinungssache - ich bin eigentlich eher für strikt getrennte aufgaben
wie siehst du denn ein gesundes cpu- / renderleistungsverhältnis ? denn wenn du von "insgesamt schneller" redest, muss man ein eben solches verhältnis im kopf haben, da heute beinahe jede grafikkarte mit jedem board, und damit auch cpu, zusammenarbeiten kann.
dann stellt sich noch die frage: wieviel mehr cpu-last nimmt man für wieviel render-optimierung in kauf ? das lässt sich schlecht gegeneinander hochrechnen
da denke ich ist eine trennung und evtl ein ungewöhnliches erforderliches cpu/graka-gespann besser, da sich hier die systemanforderungen (vermute ich) leichter abschätzen lassen

und den anderen punkt habe ich bereits angesprochen: es geht bei den neuen 3d-shootern in nächster zeit (nunja, auch vermutung, aber ich halte es für wahrscheinlich) nicht mehr primär um grafikpracht, sondern eher um sachen wie physik, ki und andere sachen, die bisher nur nebenher liefen oder an die noch gar nicht gedacht wurde - diese brauchen aber ausschließlich die cpu.
hier machen sich pro-graka und kontra-cpu optimierungen negativ bemerkbar, sicher stellt sich hier auch wieder die frage nach dem verhältnis

aths hat geschrieben:
MTB-ThePsycho hat geschrieben:
du weisst was ich sagen wollte, ansonsten siehe oben

Woher soll ich das wissen? :) "Z-Test" ist eine genau definierte Sache, womit die CPU aber nichts zu tun hat. Während Indoor-Engines schon sehr gut optimiert sind, gibts für Outdoor-Engines noch einiges zu tun, da ließen sich einige Lorbeeren verdienen. Also, frisch ans Werk :)

nunja, die smilies zeigen, dass du mich durchaus hättest richtig vertsehen können ;) aber ok, recht hast du natürlich schon
was ich aber nicht verstehe, warum alle welt immer so begeistert von outdoor-sachen ist, haben mir noch nie gefallen, so vom spielgefühl her - sicher geschmackssache, aber ich finds merkwürdig, dass ich mit meinem geschmack immer alleine dastehe ;)
und arbeit ist immer da, auch bei indoor noch :)

_________________
Du willst Respekt? Knie nieder und bettle darum!

http://www.notcpa.org
http://www.bpjs-klage.de

http://www.ccc.de/campaigns/boycott-musicindustry
Bild


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 12 Nov 2003 04:47 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
Ailuros hat geschrieben:
Jegliche Form von adaptivem AF = Leistungs-optimierte Loesung.

Wenn der "echte" Filterkernel (also das Pixel in den Texture Space transformiert) um weniger als 2:1 in eine Richtung gestreckt ist, bringt mehr als 2:1 AF keinen Qualitätsvorteil mehr. Während "sparsed" gut für's FSAA ist, sollten die AF-Samples auf einer Linie gesampelt werden. Bei Stauchungen <= Faktor 2 bringen mehr als 2 AF-Samples keine zusätzliche Qualität mehr.

Ailuros hat geschrieben:
Ich wuerde auch liebend gerne high sample sparse grid Supersampling mit reinem winkel-unabhaengigem high sample AF kombiniert in sehr hoehen Aufloesungen haben, aber Leistung ist leider mal ein wichtiger Faktor.

Unter dem Gesichtspunkt "Füllrate pro Qualität" hat Lehrbuch-AF den besten Trade-Off. Jede "Optimierung" kostet mehr BQ, als sie Leistung bringt. Das jedenfalls sind das Ergebnis meiner bisherigen Beschäftigung mit AF.

Ailuros hat geschrieben:
Wobei es laecherlich ist IMO die negativen tradeoffs von MSAA die fuer bessere Leistung aufgeopfert werden zu uebersehen, und ueber AF zu meckern. Wuerden IHVs heute winkel-unabhaengiges non-adaptive AF benutzen, waeren Fuellraten bzw. Leistung schnell wieder auf SSAA Niveau.

Dann wär's streng genommen kein AF mehr. AF muss adaptiv sein, damit es Sinn macht, und sollte jeden Winkel gleich gut behandeln.

Ailuros hat geschrieben:
Man kann nicht alles haben und es gibt einen gigantischen Unterschied zwischen Theorie und/oder Wunschdenken und realisierbaren Methoden. Und nein das mit 22 gradigen Winkeln in FPS Spielen ist Schmarren.

Du spielst vermutlich nicht nur FPS (oder TPS), oder?

Ailuros hat geschrieben:
Siehe nochmal vorigen Post. Wenn SSAA Bandbreiten-frei auf TBDR ist (wo nochmal Colour compression so gut wie nichts bringt), dann ist fuer MSAA auf einem TBDR theoretisch nicht unbedingt notwendig. Fuer andere Situationen vielleicht schon aber nicht unbedingt fuer MSAA.

Bei MSAA steigen ggü. No-AA die Bandbreiten-Forderungen, weil es pro Pixel mehr Daten gibt, die in den Framebuffer müssen. Will man sich "AA for Free" annähern, wäre Color Compression eine Idee.

Ailuros hat geschrieben:
Devil's Advocate: und MSAA verliert an Nutzen wenn Polygone kleiner werden. So kleine Polygone und so lange Shader sind ja direkt um die Ecke. Ich sehe immer noch dx7 Spiele dort draussen...

Für DX7-Spiele braucht's keine Series5. Haben wir erst mal viele Shader, brauchts auch neue Filter-Algorithmen, u.U. werden bestimmte Dinge direkt im Shader gefiltert. "Stures" SSAA bliebe weiterhin recht ineffizient, da man die zusätzlichen Samples eigentlich immer nur in Richtung der Anisotropie braucht.

Ailuros hat geschrieben:
Wieso? Ich moehte erinnern das es sich hier nur um eine rein theoretische Debatte handelt.

Na weil MSAA einen besseren Trade-Off hat, als MSAA. Das gilt auch für TBDR.

Ailuros hat geschrieben:
Wie oft muss ich noch sagen, dass auf einem TBDR VS und PS total entkoppelt sind? Wenn Du jetzt shader task switching meinen solltest, die Loesungen sind hier mehr als nur einfach. Hier wiegen sich die Vor- und Nachteile mehr oder weniger genauso aus wie auf einem IMR.

Ich habe nicht von VS und PS geredet, sondern meinte hier nur unterschiedliche PS. Da kannste in relativ kurzen Abständen die Pipeline flushen...

Ailuros hat geschrieben:
Und wie unmoeglich ist eine early-Z abartige Implementierung auf einem TBDR?

Das weiß ich nicht. Was ich weiß, ist, dass bei solchen First-Z-Passes dank Early-Z-Occlusion sich die Füllraten-Nutzung auf IMRs verbessert.

Ailuros hat geschrieben:
Wo Du bei NV30 die "features" siehst ist mir fremd. Mit nutzlosen checkboard features kann jeder rechnen.

Nutzlos?! Warum bist du plötzlich so im hier und jetzt verhaftet? Was ist nutzlos an FP32, was an dem Instruction Count, was an den praktisch unbegrenzten Ebenen der Abhängigkeit, oder an den 8 Bit LOD-Fraction, oder an der Möglichkeit, als Rendertarget einen Vertex Buffer zu nehmen?

Weil du davon im Moment noch nichts in Spielen siehst? Wäre auch verwunderlich, weil die Features noch nicht sehr lange exisiteren... warum geißelst du nicht FP24 als nutzlos für das verrechnen von Farben? Oder den F-Buffer? Oder das 10-10-10-2-Framebuffer-Format, was leider kein FSAA mehr erlaubt?

Ailuros hat geschrieben:
Es wird weiterhin variable Werte fuer interne Praezision fuer noch einige Zeit geben. Wenn die Zeit fuer sehr starke FP32 kommt, kann NV3x wohl gar nichts mehr damit anfangen. Natuerlich wenn man alles sehr einseitig sieht dann ist NV3x die Ueberloesung die aber leider nur auf Papier existiert. NV soll sich erstmal sorgen machen ueber MRT bzw MET oder HDR Unterstuetzung; FP32 ist nur fuer Angeber-rechte fuer die heutigen dx7 + ein paar oede dx9 Effekte Zeitraum.

In Dingen HDR steht NV natürlich sogar besser da, als ATI. Die meisten Effekte, die mit MRT machbar sind, lassen sich auch anderweitig realisieren.

FP32 ist kein reines Angeber-Feature. Für Farben ist FP24 quasi ein Angeber-Feature, da FP16 ist fast allen Fällen ausreicht. Es ist eigentlich eine gute Idee, Int12, FP16 und FP32 anzubieten, um für jeden Zweck ein geeignetes Datenformat zu haben. Weil Vertexdaten seit eh und je mit FP32 gerechnet werden, wird das früher oder später auch für Pixelshader gelten (spätestens, wenn die Shader vereinigt werden.) Was hast du gegen vorausschauendes Denken bei der HW-Entwicklung?

Ailuros hat geschrieben:
Angenommen ATI unterstuetzt auch weiterhin FP24 und fuegt FP32 noch hinzu, wer hat dann den Vorteil theoretisch?

Wenn ATI FP32 böte, bestünde kein Grund, länger FP24 zu nutzen.

Man kann mit Texture-Ops (seit Pixelshader 1.0, übrigens) z.B. EMBM machen, oder auch Textur-Koordinaten mit einer Matrix modifizieren. Diese Rechnungen sollten imo wenn's geht mit FP32 gemacht werden. Texturen werden im Bereich 0..1 adressiert, womit nicht die vollen 24 oder 32 Bit effektiv zur Verfügung stehen. Bei großen Texturen von z.B. 2048² braucht man bereits 11 Bit, um jedes Texel ansprechen zu können. Für vernünftige Filterung müssen natürlich noch ein paar "Nachkomma-Stellen" übrig bleiben. Das geht mit FP24 noch, allerdings wird die Koordinate beim AF ja noch mal weiterverrechnet.

Ailuros hat geschrieben:
Und dazu noch theoretische Spekulation, ohne jegliche handfeste Daten. Aus der Luft greifen kann ich auch viel.

Es sind Spekulationen, ja, aber imo nicht völlig aus der Luft gegriffen.

Ailuros hat geschrieben:
Noe nur theoretische PR-Quatsch Nummern, was aber bei NV normal ist. 136M vertices vielleicht mit wireframe oder etwas das verdammt nahe an wireframe kommt, also bitte....

Ja, und? Du wolltest doch die Zahl wissen, die NV angibt...


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 12 Nov 2003 06:42 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
MTB-ThePsycho hat geschrieben:
hier stellt sich die frage, ob die transparenz-effektze nicht etwas überbewertet werden
dass aber ein TBDR nicht an füllrate sparen sollte ist klar, man sollte jedoch auch eines bedenken:
die kyro2 hatte zwar nur 350 MTexel/s, jedoch ist der chip von 99 (oder 98 ?) - damals waren diese 350 MTexel/s noch deutlich mehr

Ansichtssache: Voodoo3 hatte 333 Megatexel, GF2 hatte (mit 16-Bit-Rendering) 1600 Megatexel. GF2 MX hat im 16-Bit-Modus immerhin 700 Megatexel. Dass man besser bei 32 Bit vergleichen sollte, um die Vorteile der Kyro zu unterstreichen, ist natürlich zumindest aus heutiger Sicht kein Nachteil.

MTB-ThePsycho hat geschrieben:
nun, das ist wohl meinungssache - ich bin eigentlich eher für strikt getrennte aufgaben

Die CPU ist im Gegensatz zur Graka frei programmierbar. Die Engine selbst (die ja nicht nur die Grafik umfasst) läuft auf der CPU, die Graka stellt dedizierte Hardware dar, um das Rendering zu beschleunigen. Mit diesem Ansatz (dem man natürlich nicht in allen Punkten folgen muss) soll die Graka "nur" rendern. Dies am besten, so effizient wie möglich. Andererseits zählt doch das Gesamtpaket: Ist der P4 im Nachteil, weil er pro MHz so wenig rechnet? Na, das gleicht er ja durch die Taktrate wieder aus. Der Nachteil besteht eher darin, dass er auf seine Leistung gerechnet teurer ist, als ein Athlon. Wie die Leistung nun zustande kommt, ist egal. Wichtig ist, dass die gebrauchte Leistung zur Verfügung gestellt wird. Eine Graka "muss" nicht möglichst effizient rendern, wenn sie auch so schnell genug ist. Geht das ineffiziente Rendern überproportional auf den Geldbeutel (GeForce2 Ultra) kann man den Sinn solcher Hardware infrage stellen. Letztlich kauft man die Graka aber aufgrund ihrer Leistung in bestimmten Spielen, da ist es Wurscht, ob Kyro1 nur 230 Megatexel hat, wenn sie für die Praxis schnell genug ist, andererseits ist es wurscht, dass die GF2 MX ziemlich ineffizient rendert, sofern die Leistung ausreicht.

MTB-ThePsycho hat geschrieben:
wie siehst du denn ein gesundes cpu- / renderleistungsverhältnis ? denn wenn du von "insgesamt schneller" redest, muss man ein eben solches verhältnis im kopf haben, da heute beinahe jede grafikkarte mit jedem board, und damit auch cpu, zusammenarbeiten kann.

In welcher Maßzahl willst du es denn haben? MHz pro Texelfüllrate?? Das hängt doch ganz stark von der Engine ab, vom aktuellen Spiel-Level, von den Forderungen ans Grafik-Detail, den mehr oder minder großen Vorlieben für FSAA und AF...

MTB-ThePsycho hat geschrieben:
dann stellt sich noch die frage: wieviel mehr cpu-last nimmt man für wieviel render-optimierung in kauf ? das lässt sich schlecht gegeneinander hochrechnen

Eine CPU ist frei programmierbar, eine Graka kann praktisch nur das 3D-Rendering beschleunigen. Hätte ich ein ausgewogenes System, und könnte wählen zwischen stärkerer CPU und stärkerer Graka, wäre mit mehr CPU-Power letztlich mehr anzufangen.

MTB-ThePsycho hat geschrieben:
da denke ich ist eine trennung und evtl ein ungewöhnliches erforderliches cpu/graka-gespann besser, da sich hier die systemanforderungen (vermute ich) leichter abschätzen lassen

Die 3D-Graka braucht man ja vorwiegend zum spielen. Da man kaum nur ein einziges Spiel auf der Platte hat, gibt es eine ziemliche Bandbreite an Lastverteilungen. Hier ist dieses der Flaschenhals, dort jenes...

MTB-ThePsycho hat geschrieben:
und den anderen punkt habe ich bereits angesprochen: es geht bei den neuen 3d-shootern in nächster zeit (nunja, auch vermutung, aber ich halte es für wahrscheinlich) nicht mehr primär um grafikpracht, sondern eher um sachen wie physik, ki und andere sachen, die bisher nur nebenher liefen oder an die noch gar nicht gedacht wurde - diese brauchen aber ausschließlich die cpu.

Natürlich wird es auch um eine Grafikpracht gehen. Doom3, HL2, andere Engines... ich sehe wirklich nicht, dass die Entwicklung ausgerechnet jetzt innehalten sollte. Natürlich werden auch andere Aspekte verbessert, die natürlich eine stärkere CPU brauchen. Die CPU-Leistung verdoppelt sich etwa alle 18 Monate...

MTB-ThePsycho hat geschrieben:
hier machen sich pro-graka und kontra-cpu optimierungen negativ bemerkbar, sicher stellt sich hier auch wieder die frage nach dem verhältnis

Ich meine, keine Limitierung ist positiv. Die Frage ist nur, ab welcher Framerate man von keiner (schmerzlichen) Limitierung mehr spricht, eine Frage des indivduellen Geschmacks. Bei CPU-Limitierung gibts "AA for free". Was gibts "for free" bei Graka-Limitierung?


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 12 Nov 2003 06:57 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Zitat:
Unter dem Gesichtspunkt "Füllrate pro Qualität" hat Lehrbuch-AF den besten Trade-Off. Jede "Optimierung" kostet mehr BQ, als sie Leistung bringt. Das jedenfalls sind das Ergebnis meiner bisherigen Beschäftigung mit AF.


Dann beschaeftige auch bitte mal mit Transistoren-Anzahl wenn es zu ATI's Loesungen kommt.


Zitat:
Du spielst vermutlich nicht nur FPS (oder TPS), oder?


Und Du uebertreibst basierend alleine auf Theorie und Screenshots. Nichts und bei keiner Loesung ist alles perfekt. Wenn ich zu NV3x oder was auch immer anderem gerade auf Regalen rueberschaue finde ich sicher mehr Macken als diese. Und ja ich bestehe darauf dass die Unterschiede nie so gigantisch sind wie sie jeder ausmachen will.

Zitat:
Für DX7-Spiele braucht's keine Series5. Haben wir erst mal viele Shader, brauchts auch neue Filter-Algorithmen, u.U. werden bestimmte Dinge direkt im Shader gefiltert.


Bitte an Spiel-Entwickler weiterreichen. Siehst Du vielleicht irgendwelche reine dx9.0 games? Ich auf jeden Fall nicht. Das hat nichts mit Serie5/NV40 oder anderen zu tun. Hartware ist immer der Software voraus und nicht anders rum.


Zitat:
Na weil MSAA einen besseren Trade-Off hat, als MSAA. Das gilt auch für TBDR.


Ein "M" zuviel und es verbleibt eine theoretische Debatte.

Zitat:
Ich habe nicht von VS und PS geredet, sondern meinte hier nur unterschiedliche PS. Da kannste in relativ kurzen Abständen die Pipeline flushen...


Ja und? Wie oft muss ich Dir noch sagen dass es dafuer logische Loesungen gibt? Und lange PS mit kurzen VS kombiniert (oder umgekehrt) ist auch nicht gerade irrelevant mit flushing. Bis die Shader vereint werden ist es auch ein Nachteil im Nacken von IMRs.

Zitat:
Das weiß ich nicht. Was ich weiß, ist, dass bei solchen First-Z-Passes dank Early-Z-Occlusion sich die Füllraten-Nutzung auf IMRs verbessert.


Patentierte Technologie die auch weiterentwickelt wurde.

Zitat:
Nutzlos?! Warum bist du plötzlich so im hier und jetzt verhaftet? Was ist nutzlos an FP32, was an dem Instruction Count, was an den praktisch unbegrenzten Ebenen der Abhängigkeit, oder an den 8 Bit LOD-Fraction, oder an der Möglichkeit, als Rendertarget einen Vertex Buffer zu nehmen?


Ja sicher ist FP32 eine sehr tolle Sache auf NV30 ganz speziell. Lass das Ding lieber im schlimmsten Fall mit FX12 oder FP16 laufen sonst sieht's grauenhaft aus. Was soll da gerade so toll dran sein?

Zitat:
Weil du davon im Moment noch nichts in Spielen siehst? Wäre auch verwunderlich, weil die Features noch nicht sehr lange exisiteren... warum geißelst du nicht FP24 als nutzlos für das verrechnen von Farben? Oder den F-Buffer? Oder das 10-10-10-2-Framebuffer-Format, was leider kein FSAA mehr erlaubt?


Weil meine zeitige Karte nicht unter Shader ops so stark zu leiden scheint und weil ich eh naechsten Fruehling wieder aufruesten werde. Noch ne Frage dazu?

Zitat:
In Dingen HDR steht NV natürlich sogar besser da, als ATI. Die meisten Effekte, die mit MRT machbar sind, lassen sich auch anderweitig realisieren.


METs not currently supported in drivers, oder doch schon nach "nur" 10 Monaten?

Zitat:
FP32 ist kein reines Angeber-Feature. Für Farben ist FP24 quasi ein Angeber-Feature, da FP16 ist fast allen Fällen ausreicht.


FP24 ist eben nur genau die Mitteloesung dazwischen und es ist nicht der einzige Teil der R3xx Architektur wo man versucht hat die hoechstmoegliche Qualitaet mit kleinstmoeglichem Leistungsverlust herauszuquetschen.

Ja R3xx ist ein "middle-road" Produkt; was gutes tut mir wenn ich 4*4 mit 8xS auf einer NV3x erreiche wenn es schneckenlangsam ist?

Zitat:
Es ist eigentlich eine gute Idee, Int12, FP16 und FP32 anzubieten, um für jeden Zweck ein geeignetes Datenformat zu haben. Weil Vertexdaten seit eh und je mit FP32 gerechnet werden, wird das früher oder später auch für Pixelshader gelten (spätestens, wenn die Shader vereinigt werden.) Was hast du gegen vorausschauendes Denken bei der HW-Entwicklung?


Vorrausschauend inwiefern. Lass einen Entwickler gerne eine Applikation entwickeln der 50 Instruktionen lange Shader mit nur FP32 fordert und dann koennen wir ja sehen wie toll das ganze aussieht in Leistung. Ach ja theoretisch unterstuetzt ja NV3x bis zu 512 Instruktionen.

NV uebertreibt traditionell mit uebertriebenen checkboard features. Ich moechte mal sehen wie eine NV2x mit 4096*4096 Texturen reagieren wuerde.

Ich hab gar nichts gegen FP32, ich bin von Grund und schon seit langer Zeit dafuer dass FP16 fuer die heutigen und 2004 Spielen ausreichend sein wird und hab es auch schon wiederholt gepostet in anderen Situationen. Ja sie haben es, aber der Vorteil es zu haben ist fuer die Lebenszeit jeniger Karten nicht unbedingt von grosser Wichtigkeit im Vergleich zu FP24. Jeder hat sein bestes getan und auss damit.

Zitat:
Wenn ATI FP32 böte, bestünde kein Grund, länger FP24 zu nutzen.


Momentan ist der Bandbreiten-Anspruch fuer 128bit immer noch enorm. Haetten sie Transistoren fuer FP32 aufopfern wollen nur um es auch zu haben, dann waere grundsaetzlich aus Leistungsgruenden entweder FP16 oder FP24 noetig gewesen.

Zitat:
Es sind Spekulationen, ja, aber imo nicht völlig aus der Luft gegriffen.


Spekulationen sind Spekulationen, da kannst Du lange versuchen die Definierung zu verdrehen. Sonst moechte ich bitte alle drei komplette Feature-listen von den high end chips von 2004.

http://www.notforidiots.com/ULE3.php

Bitte bis zum Ende durchlesen. Uttar hat zwar des oefteren falsches Zeug gepostet und obwohl so einige wichtige Information noch fehlt, so etwa sieht die Situation tatsaechlich in den internas von NV momentan aus. Hinter den Kulissen wird zugegeben dass NV3x total verpatzt wurde und dass auch cheats bei 3dmark benutzt wurden, aber was PR nach aussen schaufelt ist eine ganz andere Geschichte. Und dabei wird dem management konstant versprochen dass das naechste Produkt alles wieder gleichsetzen wird, schon fuer NV35...

Zitat:
In the 44.03 driver there were two optimizations, that some have argued are overly-aggressive. One was a clip plane optimization, and the second was a back-buffer clearing optimization. While these optimizations still produced the correct image, in order to end this debate we simply removed them. The shader optimization that resulted in nearly all of our performance gains was left in. This form of optimization is generally accepted as legitimate, in fact recognized developers in the industry, such as John Carmack and Tim Sweeney have all come forward with statements that support the legitimacy of these types of optimizations.


Eine so "kompetente" Karte wie NV30 hatte das wohl unbedingt noetig und alle konspirieren gegen NVIDIA in letzter Zeit.


Zitat:
Ja, und? Du wolltest doch die Zahl wissen, die NV angibt...


Und Du denkst wohl dass ich sie nicht wusste oder was? 12M tris/sec bei 8 Lichtern und ich haette nichts zu meckern. Oft hab ich das Gefuhl mit Dir dass Du nur argumentierst um zu argumentieren.

Dabei wird tonnenweise Bloedsinn aufgeschaufelt, aber wenn ich Dich fragen wuerde welche Karte Du Anfang von 2003 gekauft haettest, dann kann ich die Antwort schon vorhersehen; ja so relevant ist das alles.

2001/2 waren die besten Produkte NV20 und NV25 "hands down", wobei R200 im besten Fall ein Hartwaren Virus war und 2002/3 ist eben von der R3xx Familie dominiert, aber nur weil NVIDIA's inkompetent nach Jahren zur Konkurrenz stand. Irgendwann hat es auch passieren muessen und ATI oder jeglicher andere IHV der Zukunft wird es auch nicht anders gehen. Rekapitulieren kann NV natuerlich und dass auch relativ schnell, aber dann erst mit voller Pulle im DX-Next Zeitraum.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 12 Nov 2003 20:22 
Offline
User
Benutzeravatar

Registriert: 29 Aug 2001 19:58
Beiträge: 616
aths hat geschrieben:
Ansichtssache: Voodoo3 hatte 333 Megatexel, GF2 hatte (mit 16-Bit-Rendering) 1600 Megatexel. GF2 MX hat im 16-Bit-Modus immerhin 700 Megatexel. Dass man besser bei 32 Bit vergleichen sollte, um die Vorteile der Kyro zu unterstreichen, ist natürlich zumindest aus heutiger Sicht kein Nachteil.

ist die voodoo3 von '99 ? ich weiss es nicht mehr...
wenn ja, ist das genau was ich sagen wollte: vom zeitpunkt der entwicklung her war die kyro2 mit ihrer füllrate voll auf höhe der zeit - bei besserer effizienz
die zahlen von gf2 interessieren ja nicht, sie wurde ja später entwickelt, die zahlen von tnt1/tnt2 wären vielleicht noch ganz interessant, falls du sie weisst
Zitat:
Die CPU ist im Gegensatz zur Graka frei programmierbar. Die Engine selbst (die ja nicht nur die Grafik umfasst) läuft auf der CPU, die Graka stellt dedizierte Hardware dar, um das Rendering zu beschleunigen. Mit diesem Ansatz (dem man natürlich nicht in allen Punkten folgen muss) soll die Graka "nur" rendern. Dies am besten, so effizient wie möglich.

andererseits könnte man sagen: wenn die cpu frei programmierbar ist und die graka "nur" rendern kann, dann lasten wir die graka doch so weit wie möglich aus
Zitat:
In welcher Maßzahl willst du es denn haben? MHz pro Texelfüllrate?? Das hängt doch ganz stark von der Engine ab, vom aktuellen Spiel-Level, von den Forderungen ans Grafik-Detail, den mehr oder minder großen Vorlieben für FSAA und AF...

genau das wollte ich ja sagen: es wäre unsinnig das auf irgendeine art und weise gegeneinander hochzurechnen
im umkehrschluss heisst das aber, dass optimierungen zu irgednwelchen ungunsten selten sinn machen
Zitat:
Eine CPU ist frei programmierbar, eine Graka kann praktisch nur das 3D-Rendering beschleunigen. Hätte ich ein ausgewogenes System, und könnte wählen zwischen stärkerer CPU und stärkerer Graka, wäre mit mehr CPU-Power letztlich mehr anzufangen.

dann sind wir ja mal einer meinung ;)
bliebe nur noch ein streitpunkt: was ist ausgewogen ? (rhetorische frage)
Zitat:
Die 3D-Graka braucht man ja vorwiegend zum spielen. Da man kaum nur ein einziges Spiel auf der Platte hat, gibt es eine ziemliche Bandbreite an Lastverteilungen. Hier ist dieses der Flaschenhals, dort jenes...

es ging um das programmieren von enginges, nicht um fertig programmierte...
Zitat:
Natürlich wird es auch um eine Grafikpracht gehen. Doom3, HL2, andere Engines... ich sehe wirklich nicht, dass die Entwicklung ausgerechnet jetzt innehalten sollte. Natürlich werden auch andere Aspekte verbessert, die natürlich eine stärkere CPU brauchen.

bei doom3 und hl2 ja, dort wird es nochmal eine wahre grafikpracht geben.
aber danach ? ich denke das thema grafik ist ab einem bestimmten punkt ausgereizt - außerdem haben spieler und teilweise auch entwickler inzwischen eingesehen, dass grafik nicht alles ist
ich sage nicht, dass es im bereich grafik einen stillstand geben wird, aber ich vermute, dass dieser nicht mehr vorrangig sein wird
Zitat:
Die CPU-Leistung verdoppelt sich etwa alle 18 Monate...

dürfte bei grafikkarten nicht viel anderst sein - aber du bist derjenige, der die zahlen kennt
mach doch mal ein "aths-law" zu grafikkarten :) dann kann man dich bei gelegenheit zitieren
Zitat:
Ich meine, keine Limitierung ist positiv. Die Frage ist nur, ab welcher Framerate man von keiner (schmerzlichen) Limitierung mehr spricht, eine Frage des indivduellen Geschmacks. Bei CPU-Limitierung gibts "AA for free". Was gibts "for free" bei Graka-Limitierung?

nanu ? hast du eine meinung bezüglich "for free" geändert ?

_________________
Du willst Respekt? Knie nieder und bettle darum!

http://www.notcpa.org
http://www.bpjs-klage.de

http://www.ccc.de/campaigns/boycott-musicindustry
Bild


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 13 Nov 2003 05:51 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Fuer die die es bis jetzt noch nicht gelesen haben mal durchlesen:

http://www.beyond3d.com/forum/viewtopic.php?t=8959

Vielleicht hilft es Euch die VPU - CPU Relationen in der absehbaren Zukunft zu verstehen. Noch besser waere es die ganze PPT herunterzuladen und diese durchzulesen.

Ich linke auch nicht darauf aus reinem Zufall.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 13 Nov 2003 13:09 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
Ailuros hat geschrieben:
Dann beschaeftige auch bitte mal mit Transistoren-Anzahl wenn es zu ATI's Loesungen kommt.

Meiner Meinung nach sind Transistoren sehr gut eingesetzt, wenn damit AF möglichst nahe an der Lehrbuch-Qualität realisiert wird. Du kannst, damit habe ich ja kein Problem, da natürlich anderer Meinung sein. Meine Haltung ist jedenfalls, supertolle Pixelshader sind ok, aber ich hätte gerne auch supertolle Texturfilter.

Ailuros hat geschrieben:
Und Du uebertreibst basierend alleine auf Theorie und Screenshots. Nichts und bei keiner Loesung ist alles perfekt.

Ja, schon TF ist alles andere als perfekt. Bei 16°AF teilweise nur 2° zu filtern, halte ich für sehr weit entfernt von Perfektion. Wenn dir sowas nichts ausmacht, schlafe ich deshalb nicht schlechter :) Auf der anderen Seite bietet ATI ja konkurrenzlos gutes MSAA.

Ailuros hat geschrieben:
Wenn ich zu NV3x oder was auch immer anderem gerade auf Regalen rueberschaue finde ich sicher mehr Macken als diese. Und ja ich bestehe darauf dass die Unterschiede nie so gigantisch sind wie sie jeder ausmachen will.

Hier habe ich nicht ganz verstanden, was du meinst.

Ailuros hat geschrieben:
Bitte an Spiel-Entwickler weiterreichen. Siehst Du vielleicht irgendwelche reine dx9.0 games? Ich auf jeden Fall nicht. Das hat nichts mit Serie5/NV40 oder anderen zu tun. Hartware ist immer der Software voraus und nicht anders rum.

HL2 wird wohl einen reinen DX9-Path haben. Witzigerweise tut NV im Moment mehr, um DX9-Spielen eine Basis zu geben, als ATI.

Ailuros hat geschrieben:
Ein "M" zuviel und es verbleibt eine theoretische Debatte.

Was bleibt theoretisch? MSAA-Vorteile gibt's auch ganz praktisch, da sich MSAA effizienter implementieren lässt, als SSAA. Es wäre ja auch etwas unsinnig, mit TBDR erst mal Füllrate zu sparen, um sie beim AA dann ineffizient wieder zu verschleudern.

Ailuros hat geschrieben:
Ja und? Wie oft muss ich Dir noch sagen dass es dafuer logische Loesungen gibt? Und lange PS mit kurzen VS kombiniert (oder umgekehrt) ist auch nicht gerade irrelevant mit flushing. Bis die Shader vereint werden ist es auch ein Nachteil im Nacken von IMRs.

Da weniger oft die Shader gewechselt werden, ist der Nachteil natürlich geringer. Du kannst noch so oft sagen, dass es logische Lösungen gäbe, die will ich sehen, nicht nur darüber reden :)

Ailuros hat geschrieben:
Ja sicher ist FP32 eine sehr tolle Sache auf NV30 ganz speziell. Lass das Ding lieber im schlimmsten Fall mit FX12 oder FP16 laufen sonst sieht's grauenhaft aus. Was soll da gerade so toll dran sein?

Frag nggalai, der einen NV30 für Offline-Rendering einsetzt. Was an FP32 so toll ist, habe ich doch schon gesagt: Bestimmte Texture Ops führt bereits GF3 mit FP32 aus. Diese Präzision zahlt sich aus, wenn man große Texturen einsetzt.

Hätte NV wegen ATI von FP16/32 ablassen sollen und schnell noch in einigen Wochen alles auf FP24 umstellen?? Wohl kaum. Natürlich kann man auf das Gesabbel von D.K. pfeifen, der bei FP24 davon faselt, dass das kein Standard sei (FX12 und FP16 sind ja auch kein Standard) aber schon alleine weil NV30 "Render to Vertexbuffer" beherrscht, und Vertexdaten als FP32 vorliegen, ist FP32 eine nette Option für CineFX.

Ailuros hat geschrieben:
Weil meine zeitige Karte nicht unter Shader ops so stark zu leiden scheint und weil ich eh naechsten Fruehling wieder aufruesten werde. Noch ne Frage dazu?

Wann und was du dir für Hardware kaufst, geht mich wirklich nichts an.

Ailuros hat geschrieben:
METs not currently supported in drivers, oder doch schon nach "nur" 10 Monaten?

Erst redest du von HDR und MRT, jetzt plötzlich von MET... Was ist nun dein Ansatz? Fragst du, welche Features man für die Spiele hier und jetzt brauchst, oder guckst du auf die Features die die anderen gerade nicht haben?

Ailuros hat geschrieben:
FP24 ist eben nur genau die Mitteloesung dazwischen und es ist nicht der einzige Teil der R3xx Architektur wo man versucht hat die hoechstmoegliche Qualitaet mit kleinstmoeglichem Leistungsverlust herauszuquetschen.

Es ging ATI darum, Transistoren zu sparen wo es nur geht. Das fängt bei den 5 Bit LOD-Fraction an, geht über die simplifizierte AF-Formel und betrifft auch Pixelshader, wo auf eine Unterscheidungsmöglichkeit zwischen mehreren Datenformaten verzichtet wurde, und eine Präzision gewählt wurde, die für hier und jetzt noch reicht, der aber ansonsten keine große Zukunft beschieden sein wird. ATI wollte offenbar mit aller Macht die Leistungskrone, was sie ja auch mit Bravour erreicht haben: Mit prinzipiell dem gleichen Chip verweisen sie den Noch-Marktführer seit über einem Jahr auf den zweiten Platz.

Ailuros hat geschrieben:
Ja R3xx ist ein "middle-road" Produkt; was gutes tut mir wenn ich 4*4 mit 8xS auf einer NV3x erreiche wenn es schneckenlangsam ist?

Ich war gerade beim Pixelshader... warum holst du jetzt das FSAA heraus? Im 3DC-Forum wollen einige Radeon-Besitzer unbedingt Supersampling haben. (Du nicht, ich weiß.) Diese Leute (die ich nicht so recht verstehe) müssten mit 8xS doch glücklich sein...

Ailuros hat geschrieben:
Vorrausschauend inwiefern. Lass einen Entwickler gerne eine Applikation entwickeln der 50 Instruktionen lange Shader mit nur FP32 fordert und dann koennen wir ja sehen wie toll das ganze aussieht in Leistung. Ach ja theoretisch unterstuetzt ja NV3x bis zu 512 Instruktionen.

Ich weiß nicht, wieso du immer auf FP32 herumreitest. FP32 kostet zunächst nur mehr Transistoren, nicht mehr Leistung. Mit FP16 kann CineFX ja nicht schneller rechnen, dieses Feature wird vielleicht beim NV40 mal kommen...

Es gibt praktisch keinen Grund, alle Farbrechnungen mit 32 Bit FP zu rechnen. 2006 werden 50 Instruktionen lachhaft sein, 100-200 kommt wohl eher hin. Auf NV30+ wird das vom Instruction Count immerhin noch laufen, wenn natürlich auch sehr langsam. Der hohe Instruction Count ist nun wirklich kein Nachteil, finde ich, auch wenn man ihn heute für Spiele nicht braucht.

Ailuros hat geschrieben:
NV uebertreibt traditionell mit uebertriebenen checkboard features. Ich moechte mal sehen wie eine NV2x mit 4096*4096 Texturen reagieren wuerde.

Kann ich dir sagen: 4k² ist arschlahm. Aber es geht. Sollte man deiner Meinung nach auf Features verzichten, nur weil sie für das Echtzeitrendering noch nicht performant genug sind? Hat man zwei ansonsten völlig gleichwertige Chips, einer unterstützt 2k², einer 4k² Texturen, welcher wäre vorzuziehen?

In eine ähnliche Kerbe schlug ich seinerzeit bei T&L. Es ist bei einer GF2 MX200 nicht lächerlich, dass sie T&L hat, sondern es ist lächerlich, wie wenig sie damit in der Praxis gewinnt. Ansonsten, dank NSR (quasi ja auch schon "Pixelshading") kann man mit einer GF2 MX200 viele nette Sachen rendern (solange keine dependend read erforderlich sind, was bei NV ja erst ab NV20 möglich ist.)

Reden wir noch kurz über die Pixelshader bei NV20 und NV25: 4 Texture-Ops + 8 arithmetische Ops. Eigentlich ausreichend, wenn man die Leistung der Hardware betrachtet. Doch ehrlich, 8 Texture- und 16 arithmetische Ops, das wäre mir deutlich lieber. Dank Pass Reduction kann man aus hohem Instruction Count ja sogar auch noch Performance-Vorteile gewinnen. Ich sehe keinen Grund, über den Instruction Count bei CineFX zu lästern.

Ailuros hat geschrieben:
Momentan ist der Bandbreiten-Anspruch fuer 128bit immer noch enorm. Haetten sie Transistoren fuer FP32 aufopfern wollen nur um es auch zu haben, dann waere grundsaetzlich aus Leistungsgruenden entweder FP16 oder FP24 noetig gewesen.

96 vs 128 Bit ist kein so großer Schritt.

Ailuros hat geschrieben:
Spekulationen sind Spekulationen, da kannst Du lange versuchen die Definierung zu verdrehen. Sonst moechte ich bitte alle drei komplette Feature-listen von den high end chips von 2004.

Meine Spekulationen sollten als Beispiel dienen, an diesem Beispiel wollte ich meine Argumentation erläutern. Wenn dir meine Spekulationen nicht passen, dann nimm an, ich hätte über die Hardware in einem Parallel-Universum geredet. Für das Beispiel waren Zahlen notwendig, da darf man doch sicher mal spekulieren, oder?

Ailuros hat geschrieben:
Bitte bis zum Ende durchlesen. Uttar hat zwar des oefteren falsches Zeug gepostet und obwohl so einige wichtige Information noch fehlt, so etwa sieht die Situation tatsaechlich in den internas von NV momentan aus.

Uttar postet Mist, es sei denn, es passt dir in den Kram? Oder hast du Infos aus anderen Quellen, die hier was ähnliches wie Uttar von sich geben?

Ailuros hat geschrieben:
Hinter den Kulissen wird zugegeben dass NV3x total verpatzt wurde

Das glaube ich erst, wenn Dr. David Kirk gefeuert wird :D Auch meine ich gar nicht mal, dass der NV30 "total verpatzt" wurde. Offenbar gab es beim Design mehr Probleme und Bugs, als sie in der Zeit in den Griff bekommen konnten. Featuremäßig war NV30 zwar ein großer Schritt Richtung DX9, leistungsmäßig aber ein recht kleiner. Offenbar rechneten sie weder damit, dass ATI mit dem R200-Nachfolger dermaßen groß rauskommen würde, noch, dass DX9-Shader so schnell in die (Spiele-) Benchmarks einfließen würden. Setzt man NV30 und 35 in Relation zum NV20 und 25, sehe ich eigentlich keinen Bruch der Nvidia-Tradition, noch Anzeichen besonderer Inkompetenz (abgesehen vom HRAA.)

Ailuros hat geschrieben:
Eine so "kompetente" Karte wie NV30 hatte das wohl unbedingt noetig und alle konspirieren gegen NVIDIA in letzter Zeit.

NV hat praktisch schon immer unverschämt "optimiert". NV ist nicht Opfer einer Verschwörung, sondern das Opfer eigener Überheblichkeit. NVs Spagat zwischen Offline-Rendering-Einsatz und Echtzeit-Rendering für Spiele ist missglückt. Dass NV jetzt in so schlechtem Licht dasteht, ist das Ergebnis ihrer inakzeptablen Treiber-Cheat-Politik und nicht etwa darin zu suchen, dass ATI sich mit FM und Valve verschworen hätte...

Ailuros hat geschrieben:
Und Du denkst wohl dass ich sie nicht wusste oder was?

Warum hast du dann gefragt?

Ailuros hat geschrieben:
Dabei wird tonnenweise Bloedsinn aufgeschaufelt, aber wenn ich Dich fragen wuerde welche Karte Du Anfang von 2003 gekauft haettest, dann kann ich die Antwort schon vorhersehen; ja so relevant ist das alles.

Egal ob Anfang 2003 oder wenn ich jetzt eine neue Karte brauchen würde, führte an ATI ja kein Weg vorbei.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 13 Nov 2003 13:29 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
MTB-ThePsycho hat geschrieben:
wenn ja, ist das genau was ich sagen wollte: vom zeitpunkt der entwicklung her war die kyro2 mit ihrer füllrate voll auf höhe der zeit - bei besserer effizienz
die zahlen von gf2 interessieren ja nicht, sie wurde ja später entwickelt, die zahlen von tnt1/tnt2 wären vielleicht noch ganz interessant, falls du sie weisst

Den Käufer interessiert kaum, wann die HW entwickelt wurde, eher, wann er sie kaufen kann. Als Kyro erschien, gab es die GF2 schon zu kaufen, afaik. Leistungsmäßig konkurrierte die Kyro eher mit der MX.

Voodoo5 wurde z.B. als Gegenspieler zum NV10 entwickelt. Was hat das genutzt, wo man den NV15 schon lange kaufen konnte, ehe die Voodoo5 in den Regalen stand?

MTB-ThePsycho hat geschrieben:
andererseits könnte man sagen: wenn die cpu frei programmierbar ist und die graka "nur" rendern kann, dann lasten wir die graka doch so weit wie möglich aus

Genau das wird ja versucht.

MTB-ThePsycho hat geschrieben:
im umkehrschluss heisst das aber, dass optimierungen zu irgednwelchen ungunsten selten sinn machen

Wäre das so, würde kaum optimiert. Das Gegenteil ist der Fall. Jede Optimierung, die nicht im Vorfeld stattdfinden kann, sondern CPU-lastig ist, kostet dann natürlich ebenjene CPU-Leistung. Offenbar lohnt es für die meisten Systeme, sonst würde es ja nicht gemacht.

MTB-ThePsycho hat geschrieben:
es ging um das programmieren von enginges, nicht um fertig programmierte...

Die Problemlage im Kontext ist gleich.

MTB-ThePsycho hat geschrieben:
bei doom3 und hl2 ja, dort wird es nochmal eine wahre grafikpracht geben.
aber danach ? ich denke das thema grafik ist ab einem bestimmten punkt ausgereizt - außerdem haben spieler und teilweise auch entwickler inzwischen eingesehen, dass grafik nicht alles ist
ich sage nicht, dass es im bereich grafik einen stillstand geben wird, aber ich vermute, dass dieser nicht mehr vorrangig sein wird

Ich vermute, dass du dich hier grandios irrst.

MTB-ThePsycho hat geschrieben:
mach doch mal ein "aths-law" zu grafikkarten :) dann kann man dich bei gelegenheit zitieren

Nee. Die Zusammenhänge sind auch viel komplexer, die Leistung einer CPU ist grob mit recht wenigen Zahlen ganz gut beschreibbar, versuch das mal bei einer so komplizierten Graka wie NV3x.

MTB-ThePsycho hat geschrieben:
nanu ? hast du eine meinung bezüglich "for free" geändert ?

There is no lunch for free. Nicht umsonst setzte ich diese Begriffe in Anführungszeichen. Bei heftiger CPU-Limitierung ist AA dann natürlich "for free", ebenso wie andere rein graka-lastige Features.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 13 Nov 2003 17:58 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Zitat:
Meiner Meinung nach sind Transistoren sehr gut eingesetzt, wenn damit AF möglichst nahe an der Lehrbuch-Qualität realisiert wird.


Der winkel-abhaengige Algorithmus bei ATI spart an Transistoren und deshalb wurde er eingesetzt.

Zitat:
Ja, schon TF ist alles andere als perfekt. Bei 16°AF teilweise nur 2° zu filtern, halte ich für sehr weit entfernt von Perfektion. Wenn dir sowas nichts ausmacht, schlafe ich deshalb nicht schlechter Auf der anderen Seite bietet ATI ja konkurrenzlos gutes MSAA.


Ich hab schon vor ein paar posts fuer Screenshots und Dokumentierung angefragt aber bisher immer noch nichts. Lei Dir ne R3xx im schlimmsten Fall aus und setzt Dich hin und spiel mit dem Ding. Deine Theorie-Laberei laesst mich sowieso kalt. Keiner sagte dass es perfekt ist, NV's AF ist aber auch nicht gerade der Massstab.


Zitat:
Hier habe ich nicht ganz verstanden, was du meinst.


Dass im Durchschnitt R3xx um einiges besser ist als NV3x.

Zitat:
HL2 wird wohl einen reinen DX9-Path haben. Witzigerweise tut NV im Moment mehr, um DX9-Spielen eine Basis zu geben, als ATI.


Die "Basis" sollte man wohl in laecherlich langsamer Leistung uebersetzen ueberhaupt bei HL2. Solange sie die arithmetische Effizienz von ATI in 2.0 Shadern in NV3x nicht erreichen und sie werden es auch nie, koennen sie sich den extra Schmarren von mir aus an den Hut stecken.

Zitat:
Da weniger oft die Shader gewechselt werden, ist der Nachteil natürlich geringer. Du kannst noch so oft sagen, dass es logische Lösungen gäbe, die will ich sehen, nicht nur darüber reden


Eine Zugabe also dass dieses Argument durchaus idiotisch ist und Du nur argumentierst um zu argumentieren.

Zitat:
Hätte NV wegen ATI von FP16/32 ablassen sollen und schnell noch in einigen Wochen alles auf FP24 umstellen?? Wohl kaum. Natürlich kann man auf das Gesabbel von D.K. pfeifen, der bei FP24 davon faselt, dass das kein Standard sei (FX12 und FP16 sind ja auch kein Standard) aber schon alleine weil NV30 "Render to Vertexbuffer" beherrscht, und Vertexdaten als FP32 vorliegen, ist FP32 eine nette Option für CineFX.


Nein sicher nicht. Nur muessen eben endlich nach einem Jahr die NV-fans einstecken dass NV leider nicht die bessere Loesung geliefert hat. Im Durchschnitt ist NV3x NICHT das bessere Produkt, dreh ruhig so lang dran rum wie Du willst.

Zitat:
Wann und was du dir für Hardware kaufst, geht mich wirklich nichts an.


Ich hab ne bloede Frage bloed beantwortet. Dass meine zeitige Karte keine Probleme mit arithmetischer Effizienz zeitig hat, hast Du natuerlich mit Absicht uebersehen, da es ja nicht direkt hilft.

Zitat:
Erst redest du von HDR und MRT, jetzt plötzlich von MET... Was ist nun dein Ansatz? Fragst du, welche Features man für die Spiele hier und jetzt brauchst, oder guckst du auf die Features die die anderen gerade nicht haben?


METs waren NV's Alternative fuer MRTs, nur sind weder noch eigentlich eingesetzt in Treibern.

Zitat:
Ich war gerade beim Pixelshader... warum holst du jetzt das FSAA heraus? Im 3DC-Forum wollen einige Radeon-Besitzer unbedingt Supersampling haben. (Du nicht, ich weiß.) Diese Leute (die ich nicht so recht verstehe) müssten mit 8xS doch glücklich sein...


Weil bei einem Vergleich von 2 Karten alles mitzaehlt. Waere meine NV25 nicht ausgebrannt, haette ich sie im zweit-System behalten fuer aeltere Spiele und fuer 8xS alleine. Bitte notieren dass ich dazu nicht mal ne NV3x brauche.

Zitat:
Ich weiß nicht, wieso du immer auf FP32 herumreitest. FP32 kostet zunächst nur mehr Transistoren, nicht mehr Leistung. Mit FP16 kann CineFX ja nicht schneller rechnen, dieses Feature wird vielleicht beim NV40 mal kommen...


Ich sehe es an den Resultaten wo immer mixed modes eingesetzt werden. Du kannst mir ja gerne erklaeren woher die magischen 60% des 50 Dets herkommt; 40% vom shader compiler und 20% von Bescheisserei? Hoert sich etwa so an.

Zitat:
Es gibt praktisch keinen Grund, alle Farbrechnungen mit 32 Bit FP zu rechnen. 2006 werden 50 Instruktionen lachhaft sein, 100-200 kommt wohl eher hin. Auf NV30+ wird das vom Instruction Count immerhin noch laufen, wenn natürlich auch sehr langsam. Der hohe Instruction Count ist nun wirklich kein Nachteil, finde ich, auch wenn man ihn heute für Spiele nicht braucht.


Sagte ich ja auch, deshalb nannte ich ja auch fuer 2002 (ja fuer das war NV3x geplant) FP32 nur ein Angeber Feature. Die Vorteile sind minimal bis shader nach Jahren erstmal laenger werden.


Zitat:
Kann ich dir sagen: 4k² ist arschlahm. Aber es geht. Sollte man deiner Meinung nach auf Features verzichten, nur weil sie für das Echtzeitrendering noch nicht performant genug sind? Hat man zwei ansonsten völlig gleichwertige Chips, einer unterstützt 2k², einer 4k² Texturen, welcher wäre vorzuziehen?


Arschlahme features sind nur checkboard features. Wie soll ich Dir das anders definieren dass second per frame und frames per second doch ihre Wichtigkeit in 3D haben?

Zitat:
Reden wir noch kurz über die Pixelshader bei NV20 und NV25: 4 Texture-Ops + 8 arithmetische Ops. Eigentlich ausreichend, wenn man die Leistung der Hardware betrachtet. Doch ehrlich, 8 Texture- und 16 arithmetische Ops, das wäre mir deutlich lieber. Dank Pass Reduction kann man aus hohem Instruction Count ja sogar auch noch Performance-Vorteile gewinnen. Ich sehe keinen Grund, über den Instruction Count bei CineFX zu lästern.


Wieviel Geduld man wohl brauechte um mehr als 96 Anweisungen auf NV3x zu sehen, ist ja irrelevant. Schoene slideshows nein danke.

Zitat:
96 vs 128 Bit ist kein so großer Schritt.


Das gleiche gilt auch umgekehrt fuer die naechsten paar Jahre.

Zitat:
Uttar postet Mist, es sei denn, es passt dir in den Kram? Oder hast du Infos aus anderen Quellen, die hier was ähnliches wie Uttar von sich geben?


Wie gesagt das Klima dass er im Artikel zeigt ist so bei NV. Kram weil der Artikel zeigt wie beschissen die Situation intern bei denen sein koennte?

Zitat:
Das glaube ich erst, wenn Dr. David Kirk gefeuert wird Auch meine ich gar nicht mal, dass der NV30 "total verpatzt" wurde. Offenbar gab es beim Design mehr Probleme und Bugs, als sie in der Zeit in den Griff bekommen konnten. Featuremäßig war NV30 zwar ein großer Schritt Richtung DX9, leistungsmäßig aber ein recht kleiner. Offenbar rechneten sie weder damit, dass ATI mit dem R200-Nachfolger dermaßen groß rauskommen würde, noch, dass DX9-Shader so schnell in die (Spiele-) Benchmarks einfließen würden. Setzt man NV30 und 35 in Relation zum NV20 und 25, sehe ich eigentlich keinen Bruch der Nvidia-Tradition, noch Anzeichen besonderer Inkompetenz (abgesehen vom HRAA.)


Ich sehe keinen Grund Kirk zu feuern. Kompetenz oder Inkompetenz sind relativ. Wenn es nichts besseres auf dem Markt vergleichssmaessig gibt, dann sind auch die Massstaebe anders.

Schon alleine die Tatsache dass man ATI so stark unterschaetzt hat ist ein Zeichen von Schwaeche. Sep2002 bekam ich ein e-mail wo drinstand dass R300 gross, heisse waere und viel zu viel Strom verbrauchen wuerde. Der Absender sehr hoch im Rang in der Firma.

Zitat:
NV hat praktisch schon immer unverschämt "optimiert". NV ist nicht Opfer einer Verschwörung, sondern das Opfer eigener Überheblichkeit. NVs Spagat zwischen Offline-Rendering-Einsatz und Echtzeit-Rendering für Spiele ist missglückt. Dass NV jetzt in so schlechtem Licht dasteht, ist das Ergebnis ihrer inakzeptablen Treiber-Cheat-Politik und nicht etwa darin zu suchen, dass ATI sich mit FM und Valve verschworen hätte...


Brauch ich nicht zu beantworten, liegt genau im Klima meiner obrigen Paragraphen. Und wieso bitte haben sie NICHT fuer NV25 beschissen? Antwort: weil sie es nicht noetig hatten.

Zitat:
Egal ob Anfang 2003 oder wenn ich jetzt eine neue Karte brauchen würde, führte an ATI ja kein Weg vorbei.


Das ist ne dumme Ausrede, ueberhaupt fuer einen FSAA-freak. *aetsch*


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 13 Nov 2003 19:15 
Offline
User
Benutzeravatar

Registriert: 29 Aug 2001 19:58
Beiträge: 616
aths hat geschrieben:
Den Käufer interessiert kaum, wann die HW entwickelt wurde, eher, wann er sie kaufen kann. Als Kyro erschien, gab es die GF2 schon zu kaufen, afaik. Leistungsmäßig konkurrierte die Kyro eher mit der MX.

darum ging es aber nicht. ich wollte die kyro1/2 nicht in ein besseres licht rücken (hat sie auch nicht nötig).
es ging um das vorurteil (welches in deinen posts 2-3 mal aufgetaucht ist) das ein TBDR mit niedriger füllrate gleichzusetzen ist, da man die den kyro <-> geforce2 vergleich als referenz nimmt.
das ist aber in diesem zusammenhang etwas kurzsichtig
Zitat:
Wäre das so, würde kaum optimiert. Das Gegenteil ist der Fall. Jede Optimierung, die nicht im Vorfeld stattdfinden kann, sondern CPU-lastig ist, kostet dann natürlich ebenjene CPU-Leistung. Offenbar lohnt es für die meisten Systeme, sonst würde es ja nicht gemacht.

nun, es gibt optimierungen, die sich generell rechnen. diese lohnen sich immer
auf was ich seit 3 posts hinauswill: optimierungen, die - unterm strich gesehen - zu lasten der cpu gehen, nur damit die graka besser zurecht kommt, sind meiner ansicht nach unideal
falls du hier jetzt widersprechen willst:
aths hat geschrieben:
MTB-ThePsycho hat geschrieben:
andererseits könnte man sagen: wenn die cpu frei programmierbar ist und die graka "nur" rendern kann, dann lasten wir die graka doch so weit wie möglich aus

Genau das wird ja versucht.

---------------------

Zitat:
Ich vermute, dass du dich hier grandios irrst.

wird sich zeigen... allerdings sowieso erst in 2 oder 3 jahren

_________________
Du willst Respekt? Knie nieder und bettle darum!

http://www.notcpa.org
http://www.bpjs-klage.de

http://www.ccc.de/campaigns/boycott-musicindustry
Bild


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 13 Nov 2003 19:26 
Offline
Site Admin
Benutzeravatar

Registriert: 03 Aug 2001 18:30
Beiträge: 1656
Wohnort: Ostseeküste
Ihr mit eurer Quote Orgie!

Die Diskussion ist teilweise spannend, aber sehr viel Supstanz ist da nicht mehr gekommen.

@aths
Du wirst zum gegenwärtigen Zeitpunkt keine weiteren Informationen erhalten. :)

Laß mich nur noch einmal versichern Serie 5 kommt und nicht erst in einem Jahr.
Ich kann dir nicht sagen wie weit sie sind, aber auf jeden Fall weiter als manche denken oder andere hoffen.
Das was da kommt ist ein highend Chip und nicht verglichen mit NV3x oder R3xx, sie vergleichen sich durchaus mit der nächsten Generation. Niemand hier sagt das es ein Killer Chip wird. Eine Situation mit einem echten Killer und vielen anderen guten Karten kann ich mir nicht vorstellen, aber es wäre durchaus möglich neben den anderen im Sektor zu stehen, mit allen Vor- und Nachteilen die sicher auch wieder jeder Chip haben wird.

Was mir immer wieder mal auffällt, die reduzierst TBDR sehr auf die Overdraw Vermeidung. Da ist so nicht richtig und nicht ausreichend. Die TBDR von PowerVR, gegenwärtig die einzigen TBDRs überhaupt, stellen genauso wie die anderen Chips ein sehr komplexes Gebilde dar. Du kannst keinen der Chips auf ein Feature reduzieren, man muss immer die Gesamtheit sehen. Des weiteren vergleichst du ständig KYRO mit den Chips der späteren Generationen von NV oder ATI. PowerVR hat zwar in letzter Zeit keine Chips gebracht, aber sehr intensiv gearbeitet und auch ihre Feature weiter entwickelt. Das Ergebnis werden wir in kürze in Funktion erleben können und sei versichert, wir haben nicht einmal eine Vorstellung wie weit man TBDRs optimieren kann. :shock:

_________________
MfG
Loewe
~~~~~~~~~~~~~~~~~~~
webmaster of deferred Power
~~~~~~~~~~~~~~~~~~~
If you can hack it, just hack it, don`t bother with details!


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 15 Nov 2003 19:39 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
Ailuros hat geschrieben:
Der winkel-abhaengige Algorithmus bei ATI spart an Transistoren und deshalb wurde er eingesetzt.

Er spart Transistoren und Füllrate, beides zulasten der Qualität. Finde ich suboptimal. Meine Theorie-Laberei soll dich nicht davon abhalten, AF beim R300 zu nutzen, ich führte lediglich Gründe an, warum mir die gebotene Qualität unzureichend ist für aktuelle Hardware. Unzureichend finde ich übrigens auch die FSAA-Qualität jeglicher NV-Hardware.

Ailuros hat geschrieben:
Dass im Durchschnitt R3xx um einiges besser ist als NV3x.

Ich weiß nicht, ob man das so allgemein und für jeden gültig sagen kann, zöge man meine Bedürfnisse als Entscheidungsgrundlage in Betracht, ist der R300 als Spieler-Hardware dem NV3x um Längen überlegen.

Ailuros hat geschrieben:
Die "Basis" sollte man wohl in laecherlich langsamer Leistung uebersetzen ueberhaupt bei HL2. Solange sie die arithmetische Effizienz von ATI in 2.0 Shadern in NV3x nicht erreichen und sie werden es auch nie, koennen sie sich den extra Schmarren von mir aus an den Hut stecken.

An "echten" DX9-Spielen wird es mehr als HL2 geben. Es ist ja (leider?) so, dass die meisten Spiele für die Durchschnittshardware von Gelegenheit-Spielern konzipiert wurden. DX9-Games werden auf Krücken à la FX 5200 zwar entsprechend langsam laufen, aber sie werden laufen. Die "Hemmschwelle", DX9-Shader zu schreiben, wird trotz der miesen Leistung der FX 5200 durch die FX 5200 sicherlich gesenkt. Das heißt ja nicht, dass die FX 5200 eine brauchbare DX9-Spielekarte ist, das ist auch die FX 5600 nicht.

Ailuros hat geschrieben:
Eine Zugabe also dass dieses Argument durchaus idiotisch ist und Du nur argumentierst um zu argumentieren.

Darf ich das jetzt als Flame werten? Oder besteht zwischen uns noch eine Barriere sprachlicher Art? Oder haben wir völlig inkompatible Herangehensweisen an das Thema?

Ailuros hat geschrieben:
Nein sicher nicht. Nur muessen eben endlich nach einem Jahr die NV-fans einstecken dass NV leider nicht die bessere Loesung geliefert hat. Im Durchschnitt ist NV3x NICHT das bessere Produkt, dreh ruhig so lang dran rum wie Du willst.

Nanu, wo behaupte ich, dass NV30 im Durschnitt das bessere Produkt sei??

Ailuros hat geschrieben:
Ich hab ne bloede Frage bloed beantwortet. Dass meine zeitige Karte keine Probleme mit arithmetischer Effizienz zeitig hat, hast Du natuerlich mit Absicht uebersehen, da es ja nicht direkt hilft.

Persönlich halte ich arithmetische Effizienz im Moment für völlig unwichtig, wenn man mit seiner Karte spielen will. Ich bin sauer, dass Max Payne 2 für die Spiegel komischerweiser Pixelshader 1.4 sehen will, ansonsten reicht meine DX 8.1 HW für alle Effekte bei annehmbarer Grafikqualität und guten Frameraten noch aus.

Ailuros hat geschrieben:
METs waren NV's Alternative fuer MRTs, nur sind weder noch eigentlich eingesetzt in Treibern.

Werden MRT/MET von Spielen benötigt? Wenn ja, von welchen? Wenn nein, widerspricht das nicht deiner Herangehensweise der Beurteilung von Features?

Ailuros hat geschrieben:
Weil bei einem Vergleich von 2 Karten alles mitzaehlt. Waere meine NV25 nicht ausgebrannt, haette ich sie im zweit-System behalten fuer aeltere Spiele und fuer 8xS alleine. Bitte notieren dass ich dazu nicht mal ne NV3x brauche.

8xS nutze ich nur in alten, anspruchslosen Grafikdemos.

Zitat:
Ich sehe es an den Resultaten wo immer mixed modes eingesetzt werden. Du kannst mir ja gerne erklaeren woher die magischen 60% des 50 Dets herkommt; 40% vom shader compiler und 20% von Bescheisserei? Hoert sich etwa so an.

In bestimmten Fällen kann dieser Recompiler 60% (und mehr) herausholen, ohne das Ergebnis zu verschlechtern. Weder kenne ich die durchschnittliche Leistungssteigerung, noch weiß ich, ob Nvidia nich doch "kleine" Qualitätseinbußen inkauf nimmt. Ich nehme stark an, dass normalerweise deutlich weniger als 60% Leistung gewonnen werden und befürchte, dass Nvidia kleine Ungenauigkeiten für akzeptabel hält.

Ailuros hat geschrieben:
Sagte ich ja auch, deshalb nannte ich ja auch fuer 2002 (ja fuer das war NV3x geplant) FP32 nur ein Angeber Feature. Die Vorteile sind minimal bis shader nach Jahren erstmal laenger werden.

Rede ich gegen eine Wand, oder was?? FP32 ist für Texture Ops durchaus nützlich, und dort kein Angeber-Feature. Die Vorteile liegen dann nicht bei langen Shadern, sondern bei großen Texturen.

Ailuros hat geschrieben:
Arschlahme features sind nur checkboard features. Wie soll ich Dir das anders definieren dass second per frame und frames per second doch ihre Wichtigkeit in 3D haben?

Wie du deine Wichtigkeiten definierst, bleibt dir überlassen. Entwickler schätzen lange Featurelisten per se, sobald die Features brauchbar sind, zunächst ist egal, ob der Speed brauchbar ist. Auf langsamer Hardware entwickelt sich sicher besser, als mit dem Reference Rasterizer.

Da man noch lange nicht bei Auflösungen größer gleich 2048 ist, machen größere Texturen im Moment keinen Sinn. Andererseits kostet dieses Feature wohl auch nicht allzuviele Transistoren. Für Spiele ist diese Texturauflösung irrelevant, aber nicht nur GF-Karten haben Features, die in Spielen praktisch bedeutungslos sind.

Ailuros hat geschrieben:
Wieviel Geduld man wohl brauechte um mehr als 96 Anweisungen auf NV3x zu sehen, ist ja irrelevant. Schoene slideshows nein danke.

Ja, es ist utopisch, komplett "geshadete" Spiele mit langen Shadern auf irgendeiner heute kaufbaren Hardware zu spielen. Gilt für aktuelle Radeons natürlich auch, die 32+64 Instructions kannst du für einige, wenige Eye-Candy-Effekte nehmen, aber nicht alle Oberflächen so aufwändig berechnen.

Ailuros hat geschrieben:
Wie gesagt das Klima dass er im Artikel zeigt ist so bei NV. Kram weil der Artikel zeigt wie beschissen die Situation intern bei denen sein koennte?

Ehrlich gesagt, ist mir die beschissene Situation bei NV ziemlich piepe. Ich arbeite nicht bei NV. Wenn dereinst eine neue VGA-Karte ansteht werde ich sehen, was für HW (und Treiber) angeboten werden; falls NV am bri-Zwangsfilter festhält, ist diese HW für mich z.B. von vornherein praktisch wertlos. Du kennst meine ja Wunschliste, kaum jemand wird die komplette Liste erfüllen, man wird dann ja sehen wer dem noch am nächsten kommt. Vielleicht sollte ich noch ergänzen, dass ich 2x RG AA echt leid bin und endlich 4x oder 8x sehen will.

Ailuros hat geschrieben:
Brauch ich nicht zu beantworten, liegt genau im Klima meiner obrigen Paragraphen. Und wieso bitte haben sie NICHT fuer NV25 beschissen? Antwort: weil sie es nicht noetig hatten.

Beim AF haben sie gedreht (allerdings deaktivierbar). Beim Vertex Shader für den 3Mark2001 GT 4 haben sie dreist gecheatet. Was die Quake Timedemos angeht, so behaupte ich dass keine GeForce-Karte die gebenchte im "echten" Spiel tatsächlich erbringt. Warum die TNT2 Pro beim 2001-er 3DMark (gebencht auf PIII-500) schneller als eine Voodoo5 sein soll, kann ich auch nur mit Betrug erklären.

Ailuros hat geschrieben:
Das ist ne dumme Ausrede, ueberhaupt fuer einen FSAA-freak. *aetsch*

Ausrede? Was? Und warum?


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 15 Nov 2003 19:50 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
MTB-ThePsycho hat geschrieben:
es ging um das vorurteil (welches in deinen posts 2-3 mal aufgetaucht ist) das ein TBDR mit niedriger füllrate gleichzusetzen ist, da man die den kyro <-> geforce2 vergleich als referenz nimmt.

So wollte ich mich nicht verstanden wissen. Einerseits sehe ich es schon als richtig, dass bisherige erfolgreiche TBDR (Kyro, Kyro2) rohfüllratenmäßig der Konkurrenz deutlich unterlegen waren, aber das hat ja nichts direkt mit dem TBDR zu tun. Es wäre sinnvoll, TBDR zu bauen, die rohfüllratenmäßig einigermaßen mit der Konkurrenz mithalten, und der DR-HSR-Bonus noch obendrauf kommt.
MTB-ThePsycho hat geschrieben:
nun, es gibt optimierungen, die sich generell rechnen. diese lohnen sich immer
auf was ich seit 3 posts hinauswill: optimierungen, die - unterm strich gesehen - zu lasten der cpu gehen, nur damit die graka besser zurecht kommt, sind meiner ansicht nach unideal

Ich verstehe noch immer nicht so ganz, warum du hier so trennst. Mich interessiert als Spieler nicht, ob meine CPU zu 100% ausgelastet ist, oder ob die Graka völlig ausgelastet ist (letzeres kann mit FSAA/AF-Modi ohnehin sichergestellt werden.) Es interessiert die Framerate, die sich aus dem Zusammenspiel von CPU und Graka ergibt. Die CPU-Last zu steigern, um die Graka zu entlasten ist doch sinnvoll, wenn die resultierende Framerate auch steigt.

Die CPU kann btw ohnehin nicht "ideal" verwendet werden. Eine Engine sollte ja möglichst die Aufgaben so verteilen, dass alle Einheiten möglichst gut ausgelastet sind, z.B. könnte die CPU, während die Graka für einen Moment auch alleine zurecht kommt, irgendwas berechnen, aber sie sollte auf jeden Fall wieder frei sein, wenn die Graka-Pipes leer laufen...
MTB-ThePsycho hat geschrieben:
wird sich zeigen... allerdings sowieso erst in 2 oder 3 jahren

Meinen ersten eigenen Computer hatte ich 1990. Das Ding hatte (dank Erweiterung) 32 KB RAM, das BASIC ludt ich anfangs noch schön immer nach jedem booten brav von Kassette... Wenn ich eine Erfahrung gewonnen habe dann die, dass die Entwicklung nirgendwo stehen bleibt. Ich staunte bereits bei niedrig aufgelösten 16-Farben-Grafiken, was alles tolle möglich sei. Bei einem 486-er mit 33 MHz ließ ich mich zur kühnen Behauptung hinreißen, jedes Spiel, was nicht mehr darauf laufen würde, sei es auch nicht wert gespielt zu werden; Jahre später bekam ich angesichts der Grafik von Unreal den Mund nicht mehr zu...


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 15 Nov 2003 19:56 
Offline
User
Benutzeravatar

Registriert: 06 Sep 2001 17:23
Beiträge: 304
Loewe, das war wieder mal ein Posting von dir, wo ich — sorry ob der harten Worte — den Kopf schüttele. Man liest Andeutungen, die leider keine Informationen enhalten, erfährt also nichts neues; aber es wird kräftig versichert... so geht das hier schon lange. Du hälst seit Ewigkeiten diesen Mythos aufrecht, ohne Belege oder irgendeine Faktenlage anzudeuten. Hättest du Infos, müsstest aber aus Quellenschutzgründen den Mund halten, gäbe es Formulierungen und Wege, wenigstens einige Dinge zu sagen ohne sie zu sagen.

Loewe hat geschrieben:
sei versichert, wir haben nicht einmal eine Vorstellung wie weit man TBDRs optimieren kann. :shock:

Hast du mehr außer Versicherungen zu bieten? Wir haben nicht mal eine Vorstellung davon? Woher weißt du was? Weißt du denn, welche Vorstellungen ich habe? ATI brauchte 3 Chips, um außer Achtungserfolgen einen wirklichen Donnerschlag zu bewirken, aber wenn man dich so reden hört ist man ja geneigt zu glauben, PowerVR würde sich zurückmelden mit einem gaaanz tollen Chip, der nicht unbedingt ein Killer sei, aber wohl gegen R420 und NV40 bestehen könnte?

Ich möchte mich noch mal wegen meiner Grobheit entschuldigen, aber hin und wieder scheint mir, dass du auf den Messias hoffst. Vielleicht sollte ich aber auch nur mal einsehen, dass das hier 'ne Fanseite ist, und die Regulars entsprechend denken.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 16 Nov 2003 02:30 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Ich schmeiss mal die Anordnung der quotes in der quote-Orgie ein bisschen um und das mit Grund.

Zitat:
Darf ich das jetzt als Flame werten? Oder besteht zwischen uns noch eine Barriere sprachlicher Art? Oder haben wir völlig inkompatible Herangehensweisen an das Thema?


Nein und ich zeig Dir auch warum.


Zitat:
In bestimmten Fällen kann dieser Recompiler 60% (und mehr) herausholen, ohne das Ergebnis zu verschlechtern. Weder kenne ich die durchschnittliche Leistungssteigerung, noch weiß ich, ob Nvidia nich doch "kleine" Qualitätseinbußen inkauf nimmt. Ich nehme stark an, dass normalerweise deutlich weniger als 60% Leistung gewonnen werden und befürchte, dass Nvidia kleine Ungenauigkeiten für akzeptabel hält.


Es war auf den letzten 340 Patch ausgerichtet. NV musste oeffentlich zugeben dass der besagte Patch ihren Shader-optimizer nicht abschaltet, wobei hier NV selber wohl noch erklaeren muss wo zum Henker die etwa 1000 Punkte nach dem Patch verloren gingen.

Zitat:
Beim AF haben sie gedreht (allerdings deaktivierbar). Beim Vertex Shader für den 3Mark2001 GT 4 haben sie dreist gecheatet. Was die Quake Timedemos angeht, so behaupte ich dass keine GeForce-Karte die gebenchte im "echten" Spiel tatsächlich erbringt. Warum die TNT2 Pro beim 2001-er 3DMark (gebencht auf PIII-500) schneller als eine Voodoo5 sein soll, kann ich auch nur mit Betrug erklären.


Erster Kommentar von den 3dfx Jungs als sie bei NV landeten war "wir wussten dass sie bescheissen, aber wir wussten nie dass es so schlimm ist".

GT4/3dmark2k1 kannst Du vergessen, die gleiche Optimierung wurde von mehr als nur einem IHV benutzt.

Zitat:
Du hälst seit Ewigkeiten diesen Mythos aufrecht, ohne Belege oder irgendeine Faktenlage anzudeuten. Hättest du Infos, müsstest aber aus Quellenschutzgründen den Mund halten, gäbe es Formulierungen und Wege, wenigstens einige Dinge zu sagen ohne sie zu sagen.


Ah endlich kommen wir zum Kern der Sache, es geht also um den Mythos von Serie5. Momentan ist er analog des Mythos von Serie4, da es bis jetzt noch keine veroeffentlichte Hartware gibt.

Du kriegst nicht mehr raus; nice try though :P

Zitat:
Hast du mehr außer Versicherungen zu bieten? Wir haben nicht mal eine Vorstellung davon? Woher weißt du was? Weißt du denn, welche Vorstellungen ich habe? ATI brauchte 3 Chips, um außer Achtungserfolgen einen wirklichen Donnerschlag zu bewirken, aber wenn man dich so reden hört ist man ja geneigt zu glauben, PowerVR würde sich zurückmelden mit einem gaaanz tollen Chip, der nicht unbedingt ein Killer sei, aber wohl gegen R420 und NV40 bestehen könnte?


Von Dir erwarte ich zu wissen wie aussagend Papier-Spezifikationen sein koennen, bevor man einen chip testen und analysieren kann. Von paperspecs alleine aus, ist die Antwort durchaus ja.

------------------------------

So und um jetzt mal zu einer Summe und den ganzen nutzlosen Quark zu uebergehen (ja ich stimme in vielen Punkten in Deiner vorigen Antwort auf meinen Post zu, und das war auch mein Ziel):

Irgendwann brachtest Du NV30 und NV40 als Beispiele in die Debatte, wobei speziell fuer den ersten Fall es durchaus laecherlich ist an Moeglichkeiten von schwacher Geometrie-kompetenz oder arithmetic efficiency eines TBDR zu erwaehnen, wenn gerade NV30 ueberhaupt das schlimmste Beispiel ist.

Durch den Prozess der Quote-Orgien geht es dann so weit off-topic, dass ein Leser den Eindruck bekommt dass niemand mehr weis um was es am Anfang an ginge. Und nein diese "um-den-Brei-rede" Methode hilft nicht und bringt auch nicht die erwuenschte Resultate und deshalb auch die Sticheleien was die Argumentation der Argumentation zuliebe betrifft.

Ich mach es Dir mal ganz einfach: ich kann bei allem Ernst nicht behaupten dass ich viel weiss oder dass man mir keine Fehler anrechnen kann oder falsch interpretierte Infos, aber mein Wissensniveau was sich im 3D Markt bewegt ist um einiges hoeher als die des Unterschiedsverbraucher, und das nicht nur einen einzigen IHV betreffend.

Und wenn ich bestehe dass Volari nur absolter <zensiert> *hust* sein wird oder ~4 Monate vor der NV35 Ankuendigung behaupte dass nix mehr mit NV40 in 2003 wird, dann hab ich auch guten Grund an endlosen Argumenten fuer jedes Thema teilzunehmen. Uebrigens ist Dir bewusst, dass XGi womoeglich weltweite Exclusivitaet an CP tech geben wird? (you heard it from me but I don't know you :P )

Zitat:
Ich möchte mich noch mal wegen meiner Grobheit entschuldigen, aber hin und wieder scheint mir, dass du auf den Messias hoffst. Vielleicht sollte ich aber auch nur mal einsehen, dass das hier 'ne Fanseite ist, und die Regulars entsprechend denken.


Auf einer NVIDIA freundlichen Seite ist es zu erwarten dass NV40 als Messiah-chip angeshen wird, genauso bei ATI freundlichen Seiten R420 und hier wohl auch Serie5. Waere das Gegenteil zu erwarten?


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 16 Nov 2003 02:45 
Offline
the spirit of -dp-
Benutzeravatar

Registriert: 08 Dez 2002 10:38
Beiträge: 119
Zitat:
Ich verstehe noch immer nicht so ganz, warum du hier so trennst. Mich interessiert als Spieler nicht, ob meine CPU zu 100% ausgelastet ist, oder ob die Graka völlig ausgelastet ist (letzeres kann mit FSAA/AF-Modi ohnehin sichergestellt werden.) Es interessiert die Framerate, die sich aus dem Zusammenspiel von CPU und Graka ergibt. Die CPU-Last zu steigern, um die Graka zu entlasten ist doch sinnvoll, wenn die resultierende Framerate auch steigt.


In der Zukunft wird sich CPU-Last mehr und mehr auf AI und physiscs konzentrieren und deshalb auch der Link zum DX-next Link. Ach noch einer:

http://www.beyond3d.com/forum/viewtopic.php?t=8995

Zitat:
This is a finaly good indication that nearly all of the geometry ops on XBox2 are going to be pushed to the graphics processor, leaving the CPU for just AI and physics.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 16 Nov 2003 13:07 
Offline
User
Benutzeravatar

Registriert: 29 Aug 2001 19:58
Beiträge: 616
Zitat:
MTB-ThePsycho hat geschrieben:
nun, es gibt optimierungen, die sich generell rechnen. diese lohnen sich immer
auf was ich seit 3 posts hinauswill: optimierungen, die - unterm strich gesehen - zu lasten der cpu gehen, nur damit die graka besser zurecht kommt, sind meiner ansicht nach unideal

Ich verstehe noch immer nicht so ganz, warum du hier so trennst. Mich interessiert als Spieler nicht, ob meine CPU zu 100% ausgelastet ist, oder ob die Graka völlig ausgelastet ist (letzeres kann mit FSAA/AF-Modi ohnehin sichergestellt werden.) Es interessiert die Framerate, die sich aus dem Zusammenspiel von CPU und Graka ergibt. Die CPU-Last zu steigern, um die Graka zu entlasten ist doch sinnvoll, wenn die resultierende Framerate auch steigt.

das hab ich alles schonmal gesagt, aber nun gut:
1. man kann gar nicht wissen, was letztendlich in einer höheren framerate resultiert, da diese ganze masse an usern absolut unterschiedliche systeme haben.
die cpu so weit wie möglich auszulasten (bis zu welchem grad ist das wohl sinnvoll ?), um weiter grafikfeatures zu aktivieren - nun hier kann man sehr geteilter meinung sein. meiner ansicht nach wäre es hier sinnvoller, optimierungen wegzulassen, damit das spiel auch auf älterer hardware läuft, zur not senkt man die auflösung oder so...
2. die cpu wird in zukunft noch viele andere aufgaben nebenher haben, da spiele nunmal komplexer werden (siehe ailuros letzter post)
Zitat:
MTB-ThePsycho hat geschrieben:
wird sich zeigen... allerdings sowieso erst in 2 oder 3 jahren

Meinen ersten eigenen Computer hatte ich 1990. Das Ding hatte (dank Erweiterung) 32 KB RAM, das BASIC ludt ich anfangs noch schön immer nach jedem booten brav von Kassette... Wenn ich eine Erfahrung gewonnen habe dann die, dass die Entwicklung nirgendwo stehen bleibt. Ich staunte bereits bei niedrig aufgelösten 16-Farben-Grafiken, was alles tolle möglich sei. Bei einem 486-er mit 33 MHz ließ ich mich zur kühnen Behauptung hinreißen, jedes Spiel, was nicht mehr darauf laufen würde, sei es auch nicht wert gespielt zu werden; Jahre später bekam ich angesichts der Grafik von Unreal den Mund nicht mehr zu...

irgendwo ist aber tatsächlich immer ein gewisses limit erreicht.
wie gesagt, einen stillstand erwarte ich auch nicht, ich denke nur das hier die "mode" umschwenkt.
sachen wie AI und physik hat man in der vergangenheit eher vernachlässigt oder nur am rande bedacht, das wird man in nächster zeit wieder aufholen.
große sprünge, wie du einen beschrieben hast, sind sowieso nicht mehr möglich
(darüberhinaus ist bei heutigen engines viel mehr möglich als die vom durchschnitt verwendete hardware zulässt - und das stört auch kaum einen)

edit: recht geben muss ich dir aber in bezug auf loewe (sorry) - diese andeutungen, die eigentlich gar keine sind, gehen mir auch langsam auf den keks.
entweder man versucht etwas zu sagen oder man lässt es bleiben.

_________________
Du willst Respekt? Knie nieder und bettle darum!

http://www.notcpa.org
http://www.bpjs-klage.de

http://www.ccc.de/campaigns/boycott-musicindustry
Bild


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 109 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5  Nächste

Alle Zeiten sind UTC + 1 Stunde


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Gehe zu:  
cron
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de