Hi.

Schon seid einiger zeit vermisse ich hier im HArdware-Forum die Tiefgreifenderen und komplexeren Diskussionen welche bisher dem Nivau des Forum eigendlich immer zu gute kamen...

Deshalb eröffne ich nun diesen Diskussions Topic in dem über den Sinn oder Unsinn verschiedener Technicken diskutirt werden soll.

Dazu möchte ich allerdings vorweg einige "Benimregeln" aufstellen da hier Meinungsverschiedenheiten vorprogrammirt sind:
1. Dies soll kein Hersteller Flamewar Topic werden. Also bitte keine "AMD sux", "NV ist mist" oder "VIA hat eh nix drauf" Posts.
2. Auch wenn mal ein User nicht eurer Meinung ist muss man nicht direkt ausfallend werden.  
3. Bitte zumindest alle Beiträge des aktuellen Themas überfliegen um nicht X mal den selben Beitrag zu bringen.

Ich denke es spricht nix dagegen wenn ich zum start einfach mal ein Thema Vorgebe.




Ich habe mich (Zwangsläufig) recht stark mit der Cine FX Engine befassen müssen.

Die Cine FX Engine ist eine Pixel Engine welche von n-Vidia für deren akutelle Grafikbretter endwickelt wurde. Sie besteht aus 5 wesentlichen Teilen: der Triangle Unit, dem Shader Core, der Texture Unit dem Shader back end und den Combiners...

Das besondere an dieser Engine oder besser Shader Array ist das sie nur ein einziges mal in der ganzen GPU vorkommt. Man kann also sagen eine GPU die über die CineFX Engine verfügt verfügt lediglich über eine einzige Shader einheit.

Verhilte sich das ganze wirklich so einfach dann wären aktuelle NV GPUs allerdings hoffnungslos unterlegen was Shader berechnungen angeht. n-Vidia hat sich natürlich noch was ganz besonders nettes ausgedacht. Im Normalfall werden in einer Shader Unit immer einzelne Pixel berechnet... die CineFX engine arbeitet aber mit 2*2 Pixel Großen "Quads". Man arbeitet also quasi mit QDP (quad data procession bzw. 4 Fache daten berechnung).

Nun übertrage man das ganze mal auf ein Beispiel... dreist wie ich bin nem ich dazu einfach mal die GeForce FX 5800 Ultra Variante des NV30. Mit dieser CineFX Engine ließen sich pro Takt satte 8 Texturinstruktionen berechnen. Damit käme man auf extreme 4000 MTO/Sek. (zum vergleich: eine Radeon 9700 Pro schaft trotz 4 echter Shader einheiten lediglich 2600 MTO/Sek.)

Nun muss man allerdings auch noch so genannte Arithmetik-Operationen durchführen. Hier zieht die QDP nicht ganz. Es lassen sich nur 4 MAO/Takt durchführen was 2000 MAO/Takt ergibt. (eine Radeon 9700 Pro schaft hier weiterhin 2600 Operationen Pro Takt)

Nun kommen wir zum Hanken an der geschichte: Die Cine FX Engine kann nur 8 MTO/Takt ODER(!!!) 4 MAO/Takt rechnen. Da man allerdings so gut wie immer beide Berechnungen braucht ergibt sich hier ein Problem. Hier gibt es 2 Lösungswege. Endweder man rechnet einen kompletten durchgang mit MTOs und den nächsten mit MAOs oder man wählt den selben Weg wie n-Vidia und "mischt" die berechnungen. Das sähe dann so aus: 4 MTO/Takt + 2 MAO/Takt.

Um es kurz zu machen: Teo. kann die ein NV30 mit 500 MHz max. 4000 MTO/Sek. berechnen oder max. 2000 MAO/Sek.

Da in der Praxis beides Bentigt wird ergibt sich aber follgendes Bild: 2000 MTO/Sek. + 1000 MAO/Sek. (Zum vergleich eine Radeon 9700 Pro schaft trotz geringeren taktes weiterhin 2600 MTO/Sek. + 2600 MAO/Sek.)

So. Ich hoffe das nun nach dieser erläuterung im groben über die NAch und Vorteile der Cine FX Engine bescheid weiß...


Darum nun die Frage: Sinn oder Unnsin? (bitte nun keine Beiträge das eien GF FX trozdem schneller sei oÄ. Hier soll lediglich über die Technick diskutirt werden) Was gibt es zu verbesser bzw. wie kann man die nachteile der CineFX Engine "ausbügeln"?




Viel Spaß beim Diskutiren

Man In Blue

Du meinst die Spezikiationen?

Klar:
Core: NV30
Coretakt: 500 MHz
Anbindung Core: 128 Bit
Pixelpipelines: 8
TMUs Pro Pipe: 1
Shader: Shader Arrey
Speicher: Samsung 2,2 NS DDR-2
Speichertakt: 500 MHz
Speicheranbindung: 128 Bit (4*32)

Füllrate: 4000 MPixel/Sek
Speicherbandbreite: 16000 MB/Sek

Jo... der Liquid fehlt mir schon lange... :-/

mfg

Man In Blue

Zitat von »Tahigwa«

Hi

Was geht das denn Mich an?!
Darüber sollen sich die Entwickler bei NV oder ATi den Kopf zerbrechen. Ich verlange von meiner
Grafikkarte nur das sie schnell und problemlos läuft. Wie sie das macht ist mir egal.  :

Sorry, aber mehr kann ich zu dem Thema nicht beitragen.

Tahigwa

Dann lass es doch einfach.

Ich wollte/will hier ein Topic aufzihen in dem man gediegen über die aktuellen Technologien diskutiren kann. Das soll/sollte das nivau des Forums bissel hoch zihen.

Wenn dich sowas nicht interessirt dann ist das ja schön und gut... aber dann musst du das ja ned jedem auf die Nase binden.

mfg

Man In Blue

EDIT: Hier soll nicht nur über GrKas gesprochen werden... das war nun nur das "Sart Thema"...

Zitat von »Napalm«

sorry mib ich versteh nur bahnhof aber mich interessiert schon seit langer zeit was aus displacement mapping geworden is?schien an sich eine sehr vielversprechende technik zu sein die so einfach wie genial is(an alle denen das nix sagt:statt durch polygone werden durch eine graustufentextur höhenunterschiede berechnet)

cu napalm

ps:falls ich grad dummes zeug gelabert hab schlagt mir einfach auf den kopf! ;D

Also DMapping birgt zZ. 2 Nachteile:

1. Man kann es nur mit eine rMatrox P512 oder mit einer Radeon 9500++ hardwaremäßig berechnen
2. Man hat quasi keine Kollisionskontrolle. Sproch: wenn man aus einem Würfel eine Kugel macht und diese auf den Boden fallen läss (virtuell) wird sie sich weiterhin verhalten wie ein Würfel. Das liegt daran das man nach der optischen umrechneung von Würfel nach Kugel keine anderen Daten für die Kollisoinsberechnung ect. zurück an die CPU gibt...

Dadurch eignet sich DMapping in der bisherigen form nur als formschönes Bump Mapping... ob und wann das dann auch mal die regel wird ist faglich. Aber das lässt sich ja noch weiter spinnen/ausbauen... (dazu ist das Topic ja da)

@ Manuel:

Hmm. Das ist schade. Und dabei hab ich mir do soooooooo viel mühe gegeben es verständlich zu machen.

Was genau verstehst du denn ned?

Radeon 9500++ = Radeon 9500 oder höher... (kleine anlenung an C++ muss... )

Die Kollsionskontrolle im shader berechnen? Hast du dazu ne erläuterung? Kann ich mir gerade nur schwer vorstellen. (zumal die Kollisionskontrolle extrem aufwenig sein kann und mit der Physik engine verknüpft sein sollte welche wiederum hauptsächlich von der CPU berechnet wird wodruch ein enorm hoher traffik zwischen GPU/VPU und CPU auftreten würde...)

mfg

Man In Blue

Hmm.

Im Normalfall berechnetman ja die Koordinaten der Plygone und ned der Pixel...

Und das ist auch ganz gut so. Wenn man wirklklich hedes element (es handelt sich ja ned wirklich um Pixel... Von der Kollisionskontrolle her denke ich kann man das schon eher mit einer Voxel Engine vergleichen) einzelnd berechnen würde würde man einen extremen Rechenaufwand erzeugen.

Ich denke nicht das diese möglichkeit praktikabel ist.

Ich denke eher das man das Samapping zusammen mit einer Teslation einsetzen sollte... (änlich wie ATi's TrueForm) dadurch würde die Kollisionskontrolle immerhin genauer werden. (also wenn man aus dem oben genanten Würfel per telation einen Körper mit gleichseitigen 5 Ecken machen würde... nur verständnishalber... in der PRaxis müsste die Teslation natülrich um einges genauer werden... damit würde die Kugel zumindest ein kleines bischen kugelartiger verhalten...)

Andererseits könnte man dann auch direkt die Polygonanzahl hoch schreiben.

mfg

Man In Blue

Naja.

Eine Voxelengine wäre auch zu rechenintensive...

Da ist man mit den Plygonen schon auf der richtigen Pferte.

Zitat von »Napalm«

alles eine frage wieviel arbeit man auf optimierung verwendet.der mensch hat schon so viel energie in schwachsinn verendet das das dann auch keinen unterschied mehr macht. ;D
ausserdem sind die deltaforce ariale doch nicht wirklich klein.wenn man die grösse vermindert kann man dann auch die quali hochsetzen.

Die Delta Force Teile waren aber auch nicht besonders Hardwareschonend. ;D

Voxel waren mal eine dolle Sache... aber Polygone sind zZ. einfach die bessere Lösung. Vor allem für Objekte und Innen-areale sind Texturen unverzichtbar geworden... auch die meisten Shader Befehle setzten das vorhandensein von Polygone oder Texturen vorraus (Partikel- und Full Screen- Effekte ausgeschlossen)

Man ist mit der Technick auch schon viel zu weit um ketzt noch um zu denken... dazu müsste man zu vieles was zZ. grundliegend ist ändern...


@ Manual: Was ist denn nu? Würd dir gerne Erklären was du nicht verstehst. (gild auch für alle anderen die scheinbar zZ. am Bahnhof stehen)

Zitat von »Flatline«

Muss leider auch sagen dass das ein bischen zu hoch für mich ist, versteh zwar deiner Erklärung nach zumindest die Auswirkungen aber für Überlegungen bzgl. Vor/Nachteilen reichts leider nicht. Mit den Daten um die ich dich gebeten hatte: Ich hab das so verstanden das die 5800 ultra die Cine FX Engine nicht hat und du also sozusagen eine virtuelle annimst die dieses Feature hat, oder hab ich das falsch verstanden? Falls nicht hatten mich eigentlich die mto/mao Werte der echten 5800 ultra interessiert um zu sehen wie groß der Vorteil wäre.
@Napalm wozu gibts waküs

Doch der NV30 verfügt über die CineFX Engine...

Aber ich versteh nun was du meinst...

Würde der NV30 nicht auf die CineFX Engine mit QDP zurück greifen sondern über 4ordinäre Shader einheiten verfügen könnte sie satte 4000 MTO/Sek PLUS (!) satte 4000 MAO/Sek durchführen.

@ Napalm: Stimmt nicht. Bei den ATi Karten muss lediglich ein kleiner Teil der Berechnungen von der CPU übernommen werden... bei den NV KArten wird das Komplette D-Mapping von der CPU übernommen.

mfg

Man In Blue