News GeForce GTX 980 Ti als neues Flaggschiff im September

Zugegeben, der Satz ist sehr ungenau ausgedrückt. Ich wollte beide Themen gegenüberstellen.

Tut mir leid, ich habe in dem Satz Robotik und Sonde als zwei Beispiele für deine These interpretiert. Denn ein Roboter der gegen eine Wand oder allgemeiner egen ein Hindernis fährt ist in den meisten Fällen auch ein absolutes Nogo, da das den Roboter zerstören oder je nach Fall sogar Personenschäden verursachen kann (zum Beispiel wenn es sich beim Roboter um ein selbstfahrendes Auto handelt).

Edit: Vieleicht solltest du auch einen zu FP16 zufügen, denn diese sind wieder zurück beim Gaming aus Performancegründen.
Die waren nie weg. FP-Texturen sind in den meisten Fällen FP16 Genauigkeit - meist als Half bezeichnet (half, float, double).
 
Wird Zeit, dass AMD endlich in die Gänge kommt, wo sind die R9 390/380X Karten?!
 
SimsP schrieb:
Und in wie fern ist diese Aussage gegenteilig? Ich sprach von fp64 auf der GPU. In deinen genannten Beispielen geht es um den Einsatz von fp64 Berechnungen auf der CPU.
Davon steht nichts in der von mir verlinkten Quelle....also hast du nun eine die deine Behauptung belegt?

Und was deine Behauptung angeht, dass nur faule Programmierer FP64 nutzen zeugt doch etwas von Engstirnigkeit. Wenig wissenschaftlich oder technisch.

Erneut hast du eine Beitrag ohne Inhalt zum besten gegeben. Du fragst nach Quellen um dann pauschal alle für ungültig zu deklarieren.

Vielleicht ist es ja doch mangelndes Englisch bei dir:
Dennoch stießen die Programmierer gerade bei Szenen mit mehreren Fahrzeugen an die Grenzen der verwendeten CryEngine, die unter DirectX 11.1 beziehungsweise 11.2 läuft. Sie passten die Engine daher an ihre Bedürfnisse an: Transformations-Routinen laufen nun statt in 32 in 64 Bit, Z-Buffering in 32-Bit-Genauigkeit. "Auf moderner Hardware kommt es dadurch nicht zu Performance-Einbrüchen", sagt Alistair Brown.
Aber sicher läuft das auch alles auf der CPU inkl. DX11.2.
 
Zuletzt bearbeitet:
olalaaa schrieb:
die titan x bringt in battlefield 4 in 4K ultra ohne AA ~80 FPS auf den schirm. blablabla...

vollkommener schwachsinn.
du gehst ja nur nach ultra ultra msaa benchmarks und ziehst noch dazu eine beta version von project cars heran.
total lächerlich dein argument.

in high mit smaa kannst du jedes aktuelle spiel auch auf einer 200€ gpu in 1080P@60 spielen. wenn ultra schatten 50% verbraten und 4xMSAA mit über 30% zu buche schlägt dann würde ich mal einen crashkurs zu dieser materie besuchen. deine benchmarks sind komplett irrelevant.

ich spiele watch dogs in high/smaa @ 1080p mit butterweichen 40+ FPS auf einer GTX660.
1) Wenn man davon redet, das Graka XY das Spiel XY packt, dann erwarte ich das sie das auf vollen Details packt und Kantenglättung wie etwa 4fach inbegriffen
2) BF4 ist verglichen mit BF3 trotz all dem neuen/anderen Kram sehr gut optimiert, was den Hardwarehunger angeht. Könnte für dein Watchdogs auch zutreffen, weiß ich nicht.
3) Ja, Schatten fressen und das ist auch eine option die ich zurückschalten würde
4) Der Crysisbenchmark dreht sich um ein FINALES Spiel und ich hab wörtlich bemerkt, das pCars noch nicht final ist, aber es ist ein guter Anhaltspunkt, wenn man sich so die Minimum-Fps ansieht. Und das finale Produkt dürfte natürlich noch optimiert werden, aber angesichts des Ziels das schönste Rennspiel zu bringen und angesichts der Massen an Polys die die Autos haben, glaube ich nicht das dieses noch erheblich sparsamer werden wird in denselben Einstellungen.

Kleines fps-Beispiel, de serienmäßigen Autos von TDU2 haben 3-5MB in high details. Selbst auf high sind Radläufe, Lampen und anderes oft nicht wirklich rund, trotz zugeschalteter Filter via Treiber. Der Camaro ZL1 vom UP0.4 hat DREIMAL soviel MB, weils ein highpoly Model ist, alles perfekt gerundet, keine Ecken/Treppen und der zog mir auf dem alten Sys fast 10fps wenn ich den gefahrn bin. Klar is pCars moderner und garantiert optimierter, aber das verdeutlicht glasklar wohin die Richtung geht. Mehr Polys aka feiner/sauberer modelliert zieht mehr GPU, aber wem erzähl ich das eigentlich... Und bei Rennspielen sollten die Minimum-Fps nie unter 40-45 liegen. Eben auch in höchster Einstellung, sofern da ein sichtbarer Unterschied zur nächstniedrigeren ist.

Wie gesagt, klar isses NOCH ne Beta, aber wer glaubt das die final in derselben Szene unter denselben Einstellungen 20 oder gar 30fps mehr bringt... naja Zitronenfalter und so.
 
Wenn ich Eure FP64 Diskussion lese, dann erinnert mich das an meine Versuche/Spielereien mit OpenCL. Neben FP32 vs. FP64 gibt es nämlich noch weitere Größen, die man variieren kann, um Performance rauszuholen (vermutlich auf Kosten der Genauigkeit). Diese Größen kann man dem OpenCL-Compiler für den Kernel mitgeben, als da wären: -cl-unsafe-math-optimizations und als Meta-Option -cl-fast-relaxed-math. Sorry, falls zu off-topic :D

Hat jemand (praktische) Erfahrung damit? Jedenfalls wird es bei Maxwell nicht viel bringen, wenn bereits die Hardware für DP so dünn ausgestattet ist.
 
Hat jemand (praktische) Erfahrung damit? Jedenfalls wird es bei Maxwell nicht viel bringen, wenn bereits die Hardware für DP so dünn ausgestattet ist.

Das hilft dir hauptsächlich für SP. Ohne Fast Math werden in SP die Inversions-, inverse Wurzel-, Potenz- und die Winkelfunktionen iterativ mit Hilfe von 100ten Befehlen berechnet. Aktiviert man fast Math so werden die so eben genannten Funktionen in SP mit einer einzigen Intrinsik über die SFUs der GPU berechnet. Die SFUs sind allerdings etwas ungenauer. In DP werden diese Operationen unabhängig von fast Math immer iterativ berechnet (einer der vielen Gründe weshalb DP meist unpraktikabel teuer ist). Zudem setzt Fast Math denormalized floats sowohl bei DP als auch bei SP auf 0, um sich die Kosten der Sonderbehandlung zu sparen. Das bringt allerdings meist relativ wenig Performance.
 
Zuletzt bearbeitet:
Oh, da kennt sich jemand aus. Danke für die kurze Aufklärung :)
 
Genkidama schrieb:
Aufgrund deines Einzeilers wird AMD gezwungen seine neuen Grafikkarten vorzustellen.Wer braucht schon Events oder Messen.Sorry fürs Trollen.:lol:

Die graka sparte war bisher die einzig gewinn bringende....Leichter kann man es NV nicht machen, klar ein unreifes produkt rauszubringen ist auch nicht gut, aber so langsam sollte Amd echt mal in die Gänge kommen....
 
Nai schrieb:
Die waren nie weg. FP-Texturen sind in den meisten Fällen FP16 Genauigkeit - meist als Half bezeichnet (half, float, double).
Erneut missverstehst du mich. Ich rede von Hardwareeinheiten auf der GPU und nicht von Nutzung der Programmierer.
 
Erneut missverstehst du mich. Ich rede von Hardwareeinheiten auf der GPU und nicht von Nutzung der Programmierer.

Nö? Texturen werden durch Texture Units hardwarebeschleunigt gesamplet. Dabei arbeiten die Texture-Units ungefähr um den Faktor 2 schneller wenn die zu sampelnden Texturen halbe statt einfache Genauigkeit besitzen. Ergo hat die GPU Hardwareeinheiten für halbe Genauigkeit (selbst wenn es sich nur um Hardwareeinheiten für Texturbefehle handelt).
 
Daedal schrieb:
Davon steht nichts in der von mir verlinkten Quelle....also hast du nun eine die deine Behauptung belegt?

Und was deine Behauptung angeht, dass nur faule Programmierer FP64 nutzen zeugt doch etwas von Engstirnigkeit. Wenig wissenschaftlich oder technisch.

Du hast schon gesehen, dass ich faul in Anführungszeichen gesetzt hatte? Es ist ja nicht so als ob double gar keine Daseinsberechtigung hätte, aber viel zu oft werden Sachen einfach nach dem Motto programmiert: "Die Hardware kanns ja". Das ist zwar richtig, aber wenn man mal fünf Minuten nachgrübelt findet man meist eine bessere Lösung. Und so ist das auch in den meisten Fällen wo fp64 eingestezt wird.

Erneut hast du eine Beitrag ohne Inhalt zum besten gegeben. Du fragst nach Quellen um dann pauschal alle für ungültig zu deklarieren.
Ich habe dich nie um Quellen gebeten?!?
Stimmt deine Beiträge sind mit viel mehr Inhalt bestückt. Nur dass sie im Endeffekt überhaupt nicht aussagen.
Deine "Quellen" beruhen auf Blogs von irgendwelchen Leuten, die irgendwas aufgeschnappt haben. Wenn du dir mal die Diskussionen dazu ansehen würdest, dürftest du ziemlich schnell merken, dass deine Meinung, dass fp64 Berechnungen auf der GPU durchgeführt werden durch diese Beiträge kaum untermauert werden. Wenn man ne Quelle bringt sollte man schon wissen was da steht und vielleicht auch mal 5 Sekunden kritisch hinterfragen, ob das Sinn macht.

Auch dein Zitat von heise.de ist eher schwach. Ich weiß schon, warum du nicht verlinkt hast, dass es von heise kommt, denn die Glaubwürdigeit deren Aussagen hat in den letzten Jahren ganz schön gelitten. Und das auch zu Recht. Heise ist die einzige Seite, die behauptet, dass bei STarcitizen 64bit Transformationen eingesetzt werden. Und dann widersprechen sie sich noch selbst in dem sie schreiben, dass es auf moderner Hardware keine Performance einbrüche dadurch gibt. Sry aber eine dieser Behauptungen ist falsch, weiles momentan keine Grafikkarte gibt die genauso schnell fp64 wie fp32 Berechnungen durchführt.

Aber da du mich ja so nett nach einem Beleg für meine Behauptung gebeten hast, hier ein Beitrag von einem Cloudimperium Mitarbeiter:
In the case of an announcement of a general '64 bit support,' the meaning is simply that a larger memory space can be used. Pointers (memory addresses) are larger and can thus address more slots in memory. The size of the data being accessed is otherwise not modified by this; an integer is still 32 bits, a float is still 32 bits, a short is still 16, and a char is 8. Switching to 64 bit doesn't change this; just that you can use as much memory as your 64 bit OS allows. 2^32 = 4,294,967,296; which is roughly where the 4GB memory limit of a 32 bit application comes from.

In the other case, if it was an announcement about using higher precision numbers for positions, physics, or something along those lines.... (And I don't think it was, as last I heard that was still something being discussed as a possibility, rather than something which was set in stone; though that's not my specialty, so it may have changed recently) ... In that case, it would actually involve larger data types, but only in specific subsystems. There is really no case in which we would simply increase the sizes on our datatypes across the board. As you mentioned, this would slow things down (and not just on the GPU either). However, there are certain cases in which we might want more precision. In these cases, it largely comes down to a question of a precision increase vs the cost of a workaround. Some great examples of such can be found in the Kerbal Space Program dev logs, in their battles against the Deep Space Kraken: http://forum.kerbalspaceprogram.com/entries/12-Krakensbane
When implementing these sorts of fixes, it is preferable to keep the changes as isolated as possible in order to avoid unnecessary code rewrites, performance hits, or memory consumption. In the rendering, you generally don't need to worry about precision in the subsystems you might want to increase. If you had a ship and a camera in a space represented by 64 bit values, you can pre-transform everything into a local camera-relative space, then send that to the GPU as a space represented by 32 bit values without losing any useful precision. You lose precision far from the camera, but that precision doesn't actually make a difference to the rendering. It's actually quite common to convert down even smaller than that in cases where you don't need a full 32 bits of precision.

Hope that clears things up a bit!

Jetzt zufrieden?
 
(And I don't think it was, as last I heard that was still something being discussed as a possibility, rather than something which was set in stone; though that's not my specialty, so it may have changed recently)

Was soll ich denn von dieser Aussage halten? Da redet einer dass er selber keine Ahnung hat und das was du behautest ist nicht in Stein gemeiselt und sich kürzlich geändert haben könnte. Ich habe dir eben diese Änderungen schon mehrfach verlinkt und auch dass es eben nun so kommt.

In that case, it would actually involve larger data types, but only in specific subsystems. There is really no case in which we would simply increase the sizes on our datatypes across the board. As you mentioned, this would slow things down (and not just on the GPU either). However, there are certain cases in which we might want more precision. In these cases, it largely comes down to a question of a precision increase vs the cost of a workaround. Some great examples of such can be found in the Kerbal Space Program dev logs, in their battles against the Deep Space Kraken: http://forum.kerbalspaceprogram.com/...12-Krakensbane

Und hier ist eben genau so ein Anwendungsfall beschrieben, den ich dir auch schon verlinkt habe. Keiner hat gesagt alles läuft nur noch in fp64 ab, doch es kommt nun zur Anwendung im Gegensatz zur bisherigen Vorgehensweise.
 
Das heißt du glaubst der Aussage von einem wildfremden Blogger mehr als der Aussage eines Teammitglieds, das in den Entwicklungsprozess eingebunden ist, wenn auch nicht speziell mit dieser Aufgabe betraut?

Und ja es ist genau das was du in deinem Anwendungsfall auch beschrieben hast aber er sagt explizit:

There is really no case in which we would simply increase the sizes on our datatypes across the board. As you mentioned, this would slow things down (and not just on the GPU either).
If you had a ship and a camera in a space represented by 64 bit values, you can pre-transform everything into a local camera-relative space, then send that to the GPU as a space represented by 32 bit values without losing any useful precision. You lose precision far from the camera, but that precision doesn't actually make a difference to the rendering. It's actually quite common to convert down even smaller than that in cases where you don't need a full 32 bits of precision.

Kurzgesagt bedeutet das: Selbst wenn der Koordinatenraum auf 64bit basiert wird bei der GPU weiterhin mit fp32 gerechnet und nicht wie du behauptest mit 64 bit.
 
Die Diskussion hier läuft gerade mehrgleisig.

@Daedal, @SimsP, @Nai: wollt Ihr Eure Diskussion nicht von diesem Thema abspalten und im Programmiersprachen Unterforum weiterdiskutieren?
 
Kasmopaya schrieb:
Die verpassen den GTA V und Witcher III Release, wird wieder eine üble Klatsche für AMD wenn das so weiter geht.

Mh, was GTA 5 angeht: das seh ich nicht so problematisch, wenn man sich die Hardware-Anforderungen ansieht und wenn es entsprechend gut optimiert ist.
Schlimmer ist da eher The Witcher III. Da dürfte die Grafikleistung sicherlich gefragt sein und man könnte gut Kunden gewinnen, da sicherlich einige ihre Karten extra für das Spiel aufrüsten werden (hab ich damals auch bei The Witcher II von meiner 8800GT auf eine GTX 560TI).
 
"Wie bei der vorherigen Generation wird ein Nachfolger der aktuellen GeForce GTX Titan X in Form eines schnelleren Ti-Modells erwartet."

Die Formulierung sehe ich als etwas falsch ausgedrückt. Das Projekt "Titan" ist ein Prestige-Objekt und die damalige GTX 780 Ti wurde gelauncht, da AMDs R9 290X sich als "Titan-Killer" herausstellte und sogar noch 1 GB mehr Speicher bot, als die langsamere GTX 780.

Obwohl die 780 Ti schneller als die Titan war, bot sich trotzdem weiterhin "nur" 3 GB Speicher. Die 6 GB Ram blieben dann dem "Nachfolge-Prestige-Objekt" Titan Black vorbehalten. Bis heute gibt es keine GTX 780 Ti mit 6 GB Speicher...bzw. mir wäre keine bekannt.

Eine 980 Ti jetzt anzukündigen, sehe ich als reines Pokerspiel gegenüber AMD. Der erste angepeilte Termin für die R9 300er Serie war jetzt für das erste Quartal 2015 geplant, nur das ist bekanntlich nächste Woche Mittwoch vorbei und keine verlässliche Quelle hat bisher ein Vorserienmodell zum Testen bekommen, um zumindest ein paar Fakten zu zeigen. Mir stellt sich die Frage, ob AMD einfach tierische Probleme mit den neuen Chips für die Flaggschiffe hat. Die "kleineren" Karten werden ja nur wieder umgelabelte, alte Karten sein. Das ist ja schon bekannt.

>Edit< Wie CB schon schrieb, werden unter den umgelabelten Dingern auch nochmals aufgewährmte HD 7870 "Pitcairn" sein, die dann auch FreeSync unterstützen sollen. Einer HD 7870 den Support zu verweigern, einem wieder-wieder-aufgewärmten gleichen Chip das dann zu gewähren, halte ich für fragwürdig. Da würde ich mir als Kunde genauso veräppelt vorkommen, wie bei der GTX 970er Geschichte, wo so ein riesen Fass aufgemacht wurde.
 
Zuletzt bearbeitet:
Ich geb auf die Hersteller seitigen Anforderungen gar nix. Die sind nicht selten um den Faktor 3 daneben, zu hoch oder zu niedrig angesetzt. Als ob man sie auswürfeln würde. Bald gibts GTA V Benches von PCGH, dann wissen wir mehr. Rechne dank massiver Weitsicht + Masse an Objekten(mit guten Texturen) in der open World und eventueller freier Rohleistung für DSR mit einem massiven Vram Konsum.
 
Waren nicht Treiberprobleme zuletzt die Ursache für die Verzögerungen bei AMD? Dafür spricht meiner Meinung auch die Verzögerung für die Freigabe des VSR in Version 2.0. Der März-Treiber kam einen Tag zu spät und für April ist nur ein Freesync-Update angekündigt. Ich rechne letztlich mit einem Launch der R300er mit einem VSR-2.0-Treiber zur Computex Anfang Juni.

Nvidia verdirbt hier ein bisschen die Show mit der Ankündigung der 980Ti für den (Spät)Sommer. Sehe ich auch, wie @Ltcrusher, als reines Pokerspiel.
 
Zurück
Oben