Ampere-Architektur von NVIDIA soll im April starten – Turing als Codename der ersten GeForce-Karte

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Reine Dx12 games wird man nicht so schnell sehen

Das hängt mit der api selbst zusammen
Mann muss sich mit dem hardwarerescourcen beschäftigen und bekommt keinen fertigen compiler dazu
Man muss sich mit lästigen ram addressierung beschäftigen weil Dx12 gerade das bei multi cpu threadsden overhead auf einen renderhread entfernt
man muss sich mit min und max rescourcen managedment beschäftigen
in dx11 gibt es tools die das alles übernehmen man werkelt lediglich beim fertigen code herum bis die performance passt
Das ist bei dx12 nicht so teils fehlt personal die technik beherrscht und den gamecode auf Windows directx12 anpasst.
Die sind selten
Der vorteil von dx12 ist nur das man schwächere hardware besser unterstützen kann und in zukunft den takt limit der cpu herabsetzt für die gebotene drawcalls
also mehr drawcalls für weniger cpu taktzyklen
Damit kann man schneller werden als derzeit mit 3840 shader (nvidia) bzw 4096 shader(amd)
das problem ist nicht die gpu leistung die ist da, das Problem ist die cpu das max an drawcalls erreicht ist und nur noch unrealistische 5,2ghz das aufhebt
wohlgemerkt an derzeitigen limit in 1080p mit 3840shader.
Geht man in die Auflösung herauf sind die drawcalls indentisch aber wehe man designt ein game nach 4k dann wird die cpu zum Flaschenhals wie bei 720p


Amd navi ist ein shrink von fiji nummer 3
da erwarte ich dieselbe Leistung wie derzeit zur gtx1080 mit annehmbaren tdp um die 160w anstatt 300w
erst nach navi also amd gpu next wird amd aufschließen und das ist erst 2021
Bis dahin wird nvidia den Markt beherrschen und entsprechend bei etwas mehr Leistung die preise anheben
Wichtig ist ob amd mit navi die bis dahin eventuell volta Leistung des einsteigerchip (gv106) erreicht und diesen für nur 250$ hergibt
Das zwingt nvidia früher mit volta zu kommen um die Preistruktur zu bewahren
Bis volta wird ein pascal refresh kommen
ampere ist die neue arch ab 2019 HPC, 2021-2 desktop

alles andere wäre kaufmännisch Sinnfrei.
 
Hardwareaner schrieb:
MS gehört auch dazu. Haben die deshalb ein übermäßiges Interesse an Vulkan?
Zum Vergrößern anklicken....
Du meinst Nvidia entwickelt umsonst an Gameworks Vulkan? New Release von Samples war am 24.01.18? Kann es sein, dass solche Aussagen eher Bias sind. Die Github'er sind jedenfalls interessiert?
 
satuan schrieb:
Du meinst Nvidia entwickelt umsonst an Gameworks Vulkan? New Release von Samples war am 24.01.18? Kann es sein, dass solche Aussagen eher Bias sind. Die Github'er sind jedenfalls interessiert?
Zum Vergrößern anklicken....
In jedem Fall ist das Interesse von Nvidia an Vulkan nicht ansatzweise so groß wie das von AMD. AMD hat mit DX12/Vulkan alles auf eine Karte gesetzt und verloren, während Nvidia den schlaueren Weg gegangen und die Treiber für die zwar alte aber mittelfristig zukunftssicherere API hin weiter optimiert hat (angelsdecay hat die teils unschlagbaren Vorteile von DX11 ja schöm aufgelistet).
Nvidia ist in der Khronos Group und hilft dort mit auch nur hauptsächlich damit die Weiterentwicklung nicht wie bei Mantle total in Richtung AMD-Hardware geht. Und weil man LL-APIs nicht ewig aus dem Weg gehen kann.
 
Hardwareaner schrieb:
In jedem Fall ist das Interesse von Nvidia an Vulkan nicht ansatzweise so groß wie das von AMD. AMD hat mit DX12/Vulkan alles auf eine Karte gesetzt und verloren, während Nvidia den schlaueren Weg gegangen und die Treiber für die zwar alte aber mittelfristig zukunftssicherere API hin weiter optimiert hat (angelsdecay hat die teils unschlagbaren Vorteile von DX11 ja schöm aufgelistet).
Nvidia ist in der Khronos Group und hilft dort mit auch nur hauptsächlich damit die Weiterentwicklung nicht wie bei Mantle total in Richtung AMD-Hardware geht. Und weil man LL-APIs nicht ewig aus dem Weg gehen kann.
Zum Vergrößern anklicken....
Nvidia profitiert genauso von LL wie AMD. Ihr beschränkt immer nur alles auf dGPUs. Und was wird dabei aus Bereichen die von Vulkan profitieren? LL bedeutet ja hardwarenäher und setzt damit Ressourcen frei, die man heute schon hat, aber nicht nutzen kann unter HL. Dann aus einer einzigen Datenbank zu schöpfen - ist jedenfalls kostengünstiger, wenn andere noch mitentwickeln. Gameworks ist ja keineswegs in eine Richtung entwickelt und auf Nvidia proprietär ausgerichtet, nein überhaupt nicht. Ist schon spät, na dann...

Seht euch mal lieber an was Nv da macht, hier wird viel ... erzählt, weil's der eigene Bias hergibt: NVIDIA GameWorks Vulkan and OpenGL Samples | NVIDIA Developer
 
satuan schrieb:
Nvidia profitiert genauso von LL wie AMD. Ihr beschränkt immer nur alles auf dGPUs. Und was wird dabei aus Bereichen die von Vulkan profitieren? LL bedeutet ja hardwarenäher und setzt damit Ressourcen frei, die man heute schon hat, aber nicht nutzen kann unter HL. Dann aus einer einzigen Datenbank zu schöpfen - ist jedenfalls kostengünstiger, wenn andere noch mitentwickeln. Gameworks ist ja keineswegs in eine Richtung entwickelt und auf Nvidia proprietär ausgerichtet, nein überhaupt nicht. Ist schon spät, na dann...

Seht euch mal lieber an was Nv da macht, hier wird viel ... erzählt, weil's der eigene Bias hergibt: NVIDIA GameWorks Vulkan and OpenGL Samples | NVIDIA Developer
Zum Vergrößern anklicken....

Natürlich profitiert nvidia von Vulkan, nur ist nvidia ist nicht im Zugzwang dort Tempo zu machen. Wie kommt AMD auf den Trichter bei gefühlt 10:1 Vertretung im Spielesektor ihr eigenes Ding zu drehen und sich drüber wundern das niemand die Features nutzt. Auch werden die meisten Engines direkt oder indirekt auf nvidia Hardware zugeschnitten weil jene einfach den Verbreitungsgrad haben was deren Architektur weiter stützt. Aber nur Fanboys interessiert es welche Farbe ihre Grafikkarte hat. Mein Gehäuse ist geschlossen und wenn es funktionieren würde könnt ich auch mit Windows Standart Anzeigetreiber leben. AMD muss Hardwaretechnisch wie beim Ryzen ein ordentliches Produkt liefern.
Ich hätte auch kein Problem mit den Doppel GPU Karten oder Sli Konzept wenn es ordentlich zu Ende gedacht wäre und Problemlos funktionieren würde.
 
kein Entwickler optimiert auf einer bestimmten GPu
Sie optimieren dx11 api damit games auf vram und ram richtig laufen
Ob da amd oder nvidia gpu läuft interessiert nicht
Die speziellen Anpassungen machen nvidia und amd im Treiber
das amd gpu durch hardwaresheduler leicht im Nachteil ist bei directx, ist bekannt und kann nur vom Spielentwickler beim compilieren der api und des gamecode mit einer comand list behoben werden
Nvidia bietet das als default im Treiber an und wird automatisch angewendet, schaltet sich aber ab wenn klar wird das eine comand list vorhanden und verwendet wird vom game.

Diese Mär von nvidia optimiert game hält sich hartnäckig
 
angelsdecay schrieb:
kein Entwickler optimiert auf einer bestimmten GPu
Sie optimieren dx11 api damit games auf vram und ram richtig laufen
Ob da amd oder nvidia gpu läuft interessiert nicht
Die speziellen Anpassungen machen nvidia und amd im Treiber
das amd gpu durch hardwaresheduler leicht im Nachteil ist bei directx, ist bekannt und kann nur vom Spielentwickler beim compilieren der api und des gamecode mit einer comand list behoben werden
Nvidia bietet das als default im Treiber an und wird automatisch angewendet, schaltet sich aber ab wenn klar wird das eine comand list vorhanden und verwendet wird vom game.

Diese Mär von nvidia optimiert game hält sich hartnäckig
Zum Vergrößern anklicken....

What?
 
comand list
eine liste von drawcalls Anforderung auf mehrere CPu Kerne (threads) aufteilt
Bestandteil von directx seit dx10 (2006)

Directx11 bis 192 threads

nvidia hat ab 2012 mit kepler (gtx6xx) den hardware sheduler aus dem treiber entfernt und durch eine software sheduler ersetzt
Der bei games die in dx10 dx11 laufen die cpu last auf alle vorhandene Kerne aufteilt
Das funktioniert soweit so gut das man vom spiele entwickler sich es oft sparen eine eigene multithread Nutzung beim game zu entwickeln.
Aber das ist stark game engine abhängig
Wo die comand list aus dem nvidia treiber greift ist
Idtech 5 mit opengl
iwtech 5
unreal engine
rage engine (rockstar)
dunia engine (far cry serie)
dawn engine (dishonored serie)
alle auf unity basierende games

Wo die comand list nicht geht sind portierungen von engines aus dem directx9 zeitalter
idtech3
unreal engine 2/3
Real Virtuality 3/4
source (valve half life und andere Ableger csgo)
 
Zuletzt bearbeitet:
angelsdecay schrieb:
Diese Mär von nvidia optimiert game hält sich hartnäckig
Zum Vergrößern anklicken....
Und was ist Gameworks in Spielen? CPU und Ram optimiert? Hier sind gerade vor lachen ein paar vom Stuhl gefallen! Gameworks ist Nvidia LL! Du meinst alle Spiele unter dx12, dx11 FL12 und Vulkan sind HL optimiert? Dann steht es um dich schlimmer als vermutet.:cool:

Nvidia hat damit eins nicht unter dx11, CPU Limits in dem Ausmaß wie AMD GPUs sie haben, damit weniger Overhead der woanders umgesetzt werden kann, dafür tauscht AMD aber auch nicht ganze extensions aus oder includieren Befehle in der d3d Bibliothek als eigenen String, um schnell zu sein. Das ist eine reine Treibergeschichte und wenn du mich fragst = gecheatet. Nichts was der Entwickler so vorgesehen hatte. Genau deshalb halten sie auch so lange wie möglich an dx11 fest, unter dx12 kann es das nicht mehr geben.

Das der Großteil der kleinen Schmieden sich keine eigenen Work-Tools LL entwickeln kann, liegt an den damit zusammenhängenden Kosten die Publisher oft scheuen. Daher werden Vulkantools auf Bedürfnisse hin entwickelt, so wie z.Bsp. Compiler von dx zu Vulkanports.

Genauso wird das auch unter dx gehandhabt und von MS gefördert.

- - - Updated - - -

Cibo schrieb:
Natürlich profitiert nvidia von Vulkan, nur ist nvidia ist nicht im Zugzwang dort Tempo zu machen. Wie kommt AMD auf den Trichter bei gefühlt 10:1 Vertretung im Spielesektor ihr eigenes Ding zu drehen und sich drüber wundern das niemand die Features nutzt. Auch werden die meisten Engines direkt oder indirekt auf nvidia Hardware zugeschnitten weil jene einfach den Verbreitungsgrad haben was deren Architektur weiter stützt. Aber nur Fanboys interessiert es welche Farbe ihre Grafikkarte hat. Mein Gehäuse ist geschlossen und wenn es funktionieren würde könnt ich auch mit Windows Standart Anzeigetreiber leben. AMD muss Hardwaretechnisch wie beim Ryzen ein ordentliches Produkt liefern.
Ich hätte auch kein Problem mit den Doppel GPU Karten oder Sli Konzept wenn es ordentlich zu Ende gedacht wäre und Problemlos funktionieren würde.
Zum Vergrößern anklicken....
???, was ist denn z.Bsp. ... mit Qualcomm, Samsung, Linux, Handys, Pads, anderes Mobilezeugs, Webgaming?.... Da hat Nvidia nichts zu melden und will mit ihren Cloudgamingangeboten mitreden. Mal drüber nachgedacht wozu sich Vulkan da eignet.

Geringere Anforderungen an die Hardware, oder zielgerichtete Entwicklung für Leistungssegmente - weil LL statt HL und weniger Overhead? Noch nie was davon gehört? Hat den Anschein nicht. Was hat Nvidias Marktanteil im dGPU Geschäft damit zu tun? Erläuerte das mal kurz.

Darf ich?: 30% GPU Marktanteil hält der dGPU Bereich, knapp 70% davon Nvidia, das ist ein "Furz" was Gameworks damit abdeckt. Und genau daher entwickelt Nvidia auch gezielt an Vulkan mit und implementiert es in seine Gameworks Dev Datenbank. So wie alle anderen IHVs die sich an Vulkan beteiligen auch.
 
Zuletzt bearbeitet:
satuan schrieb:
Und was ist Gameworks in Spielen? CPU und Ram optimiert? Hier sind gerade vor lachen ein paar vom Stuhl gefallen! Gameworks ist Nvidia LL! Du meinst alle Spiele unter dx12, dx11 FL12 und Vulkan sind HL optimiert? Dann steht es um dich schlimmer als vermutet.
Zum Vergrößern anklicken....

Was willst du eigentlich immer mit deinem Gameworks gehate? Und was hat Gameworks, DX12, DX11 FL12 und Vulkan mit der Aussage zu tun?
Schon mal was von Ausnahmen der Regel gehört? Der Anteil von Titeln genannter Kategorie gehen im Vergleich gegen Null. Rosinen würde man sowas nennen, noch dazu bist du hier der einzige der permanent versucht irgendwas in Gameworks zu sehen obwohl das im jeweiligen Diskussionsthema überhaupt keine Anteile hat.
Auch verpackst du diese Aussage unnötigerweise als Fakten obwohl es bestensfalls ne Meinung ist und verkaufst hier auch pseudotechnische Erklärungen ohne dass du selbst mit dem Background vertraut bist - das sagte ich dir auch nicht erst einmal.

Bitte tue uns doch den Gefallen und kennzeichne in Zukunft derartige Aussagen als Meinung oder Annahmen - dann lässt sich da im zweifel über für- und wieder debattieren! Ist nicht schwer, tut nicht weh und hilft klar der sachlichkeit beizutragen!
 
fdsonne schrieb:
Bitte tue uns doch den Gefallen und kennzeichne in Zukunft derartige Aussagen als Meinung oder Annahmen - dann lässt sich da im zweifel über für- und wieder debattieren! Ist nicht schwer, tut nicht weh und hilft klar der sachlichkeit beizutragen!
Zum Vergrößern anklicken....
Das dürfte ja für alle gelten. Im Übrigen habe ich Nvidias Aktivitäten rund um Vulkan dann sogar noch verteidigt, weil ein paar meinen sie würden darauf einen Pfifferling geben, was aber Nonsens ist anhand der Begründungen die geliefert werden. Ich persönlich habe das Thema nicht angesprochen sondern darauf geantwortet, falls du das mal wieder überlesen hast.

Hier verkaufen alle nur Meinungen...

*und da ich Cloudrendering angesprochen habe sollte du dich mal fragen was OptiX sonst ist - wenn nicht Nvidia LL?

Das hat mit Gehate gar nichts zu tun, sondern ist Tatsache und keine Meinung.

- - - Updated - - -

angelsdecay schrieb:
comand list

Directx11 bis 192 threads
Zum Vergrößern anklicken....
Das Ding heißt cmd=command list und nein unter dx11 sind je nach cs 768 oder 1024 numthreads möglich (ID3D11Device) oder worauf möchtest du dich beziehen, mal weit offtopic. Durch Matrixadditionen könnten numthreads auf numthreads gesetzt werden.
 
Zuletzt bearbeitet:
Das stand mal offiziell beim Vergleich zwischen dx11 dx12 feature level auf MS webseite
mittlerweile vertuscht und Seite umgestaltet daher ein Ersatz wie comand list funktioniert
genau geht es um programmierbare shader cluster direkt anzusprechen

Nur ist das mehr ein softwareproblem als ein hardwareproblem

Nun zur Überraschung aller sind nvidia gpu deutlich cpu overhead anfälliger als amd gpu. Video als anschaulicher beweis von einen laien
Der grund ist der software sheduler
Dieser erzeugt wegen der verwaltung der cpu threads mehr cpu last auf einen kern.
Und jetzt kommts
Diese technik ist soweit das man mehr gewinnt durch die drawcalls aufteilung bei der cpu als wenn man dies stur directx auf einen Kern berechnen lässt.
das liegt an den games und deren engines
alles ab dx10 wird dadurch der erste thread entlastet und auf alle threads aufgeteilt
Nur funktioniert das in manch game schlechter als gedacht bsp splintel cell conviction (2010) da ist die grenze 2 Kerne alles darüber und erst smt an sinkt die leistung wieder.

Diese Phänomen sieht man oft, hier hilft prozessorlasso
Denn diese umstand ist windows zu verdanken. Der bei geringer cpu last einfach takt und den thread auf reise schickt.
Mal quer auf jeden cpu thread verschoben.
Das Problem trat gern bei amd CPu auf
es gibt den hardware Grund warum amd gpu anscheinend weniger gut auf dx11 laufen wird im video erklärt.
Die Grundlage ist aber das die Spielentwickler hier einfach die möglichkeiten der command list nicht nutzen.
 
angelsdecay schrieb:
Das stand mal offiziell beim Vergleich zwischen dx11 dx12 feature level.
genau geht es um programmierbare shader cluster direkt anzusprechen. Nur ist das mehr ein softwareproblem als ein hardwareproblem.
es gibt den hardware Grund warum amd gpu anscheinend weniger gut auf dx11 laufen wird im video erklärt.
Die Grundlage ist aber das die Spielentwickler hier einfach die möglichkeiten der command list nicht nutzen.
Zum Vergrößern anklicken....

Bei Nvidia ist es so, dass der CWD einen Threadblock nur dann plant wenn der SM über ausreichende Ressourcen verfügt (Warps-Register-Memory usw.). Die Level-Ressourcen werden dabei zugewiesen. Diese erstellt genügend Warps für alle Threads im Block. Der Ressourcenmanager weist den dann Unterpartitionen Warps Rounds zu. Dabei hat jede Subpartition einen Warpscheduler, ein Register und Ausführungseinheiten. Wenn ein Warp einer Unterpartition zugewiesen wird, bleibt er auf der Unterpartition bis er abgeschlossen wurde oder durch einen Kontextwechsel vorbelegt wird. Wenn alle Threads im Warp abgeschlossen sind, wartet der Warpscheduler darauf, bis die vom Warp ausgegeben Befehle geschlossen wurden. Dann gibt der Ressourcenmanager die Ressourcen frei. Wenn alle Warps in einem Threadblock abgeschlossen sind, werden alle auf Blockebene freigegeben. Dann wird der CWD vom SM benachrichtigt, dass der Block abgeschlossen wurde. Warps werden immer dann als aktiv betrachtet, wenn sie einer Unterpartition und alle dazugehörigen Ressourcen zugewiesen wurden. Das heißt der Sheduler überwacht den Zustand und entscheidet welche blockiert sind und welche ausgegeben werden können. Dort werden dann zwei Befehle mit der Priorität 1-2 usw. ausgewählt. Da ist Architektur abhängig und da hat sich auch weiterentwickelt, wie erklärt und ist genauso multipel ausführbar. Wieso 192? Mir ist dazu eine Größe wie mb oder gb bekannt?

Zudem hast du einen sehr alten Artikel verlinkt der von einer dx11 Beta schreibt, heute unterstützt dx11 auch höhere Level. Erst ab dx12 ändert sich das Renderingmodell grundlegend Die Verringerung des Drawcall-Overhead ist daher auch unter dx11 nutzbar, nur deshalb gibt es für dieses Runtime auch höhere Level die dies sicherstellen. Diese waren von MS als Übergang geplant um den Entwicklern die Arbeit so leicht wie möglich zu machen und viele von den kommenden Implementationen schon zu nutzen, soweit sie ausführbar sind. Man kann darunter eben auch hardwarenahe Eigenschaften optional nutzen. Erst ab 12.1 sind Tier_Stufen usw. verbindlich. Nvidia hat also keine Nachteile beim Sheduling oder erleidet sie. Sie sind vorerst im CPU Limit schneller, weil sie eine perfekte Balance zwischen CPU und GPU erreichen und damit Bottlenecks minimieren, wenn nicht sogar ausschließen. Die reine Drawcall oder Multithread Rohleistung lässt sich dabei nicht auf alle Anwendungsbereiche verlustfrei anwenden, zeigt aber das auch ältere Hardware davon profitiert. Man muss klar bedenken das der API Overhead wegen seiner eigenen Komplextät da auch noch eine Rolle spielt und wenn dort gezielt auf einen optimiert wird, entstehen Vorteile. Heute ist trotzdem viel mehr möglich als es noch 2009 war. Es gibt immer Übergangsphasen das war in der Entwicklungsgeschichte schon immer so.

Um das Thema jetzt abzuschließen - der Vulkan Nvidia Treiber ist eine Linux-Tegra-Standardkomponente und zu Jetson TX2, TX2i und TX1 kompatibel. Ich würde dir mal empfehlen (und einigen anderen hier) einige Publikationen dazu einzusehen (Cuda, Kernel, Thread Block, SM), da Cuda dabei direkt auf API Funktionen zurückgreift und das schon seit Version 1.0.

Und das soll dann auch für mich gewesen sein, dem ohne Background.
 
The Compute Work Distributor will schedule a thread block (CTA) on a SM only if the SM has sufficient resources for the thread block (shared memory, warps, registers, barriers, ...). Thread block level resources such shared memory are allocated. The allocate creates sufficient warps for all threads in the thread block. The resource manager allocates warps round robin to the SM sub-partitions. Each SM subpartition contains a warp scheduler, register file, and execution units. Once a warp is allocated to a subpartition it will remain on the subpartition until it completes or is pre-empted by a context switch (Pascal architecture). On context switch restore the warp will be restored to the same SM same warp-id.

When all threads in warp have completed the warp scheduler waits for all outstanding instructions issued by the warp to complete and then the resource manager releases the warp level resources which include warp-id and register file.

When all warps in a thread block complete then block level resources are released and the SM notifies the Compute Work Distributor that the block has completed.

Once a warp is allocated to a subpartition and all resources are allocated the warp is considered active meaning that the warp scheduler is actively tracking the state of the warp. On each cycle the warp scheduler determine which active warps are stalled and which are eligible to issue an instruction. The warp scheduler picks the highest priority eligible warp and issues 1-2 consecutive instructions from the warp. The rules for dual-issue are specific to each architecture. If a warp issues a memory load it can continue to executed independent instructions until it reaches a dependent instruction. The warp will then report stalled until the load completes. The same is true for dependent math instructions. The SM architecture is designed to hide both ALU and memory latency by switching per cycle between warps.
Zum Vergrößern anklicken....

Was ein Zufall oder nicht, dass eure Beiträge so ähnlich zueinander sind? :d

Oder habe ich da einfach nur deinen Account bei Stackoverflow entdeckt?

Naja just my 2 Cents :wink:
 
Paddy92 schrieb:
Naja just my 2 Cents :wink:
Zum Vergrößern anklicken....
Ja - Paddy du bist so cool, du mit deinen 2 Cents die soviel wert sind wie ... . Aber spekulativ gesehen, war ich vermutlich der Fragesteller? Dann solltest du es auch als solches kennzeichnen.

Was die Frage angeht: kann man eine vorherrschende Lehrmeinung nicht anders rüber bringen, als sie an Unis vermittelt wird, was auch der Tatsache, Realität und Funktionsweise entspricht, klick mal auf das Profil - dann weißt du warum. Ob dir da Accounts auf stackoverflow helfen, wo sich eine Bandbreite an Engineer's und Tool Entwicklergrößen umher treibt, den man auch mal lauschen kann, ich weiß es nicht. Ich persönlich "vermute es nicht". Der Rest den du suchst steht hier: CUDA Toolkit Documentation, ist dort genauso beschrieben - einfach nur lesen. Nvidia verteilt keine anderen Publikationen, Dokumentationen oder Whitepaper. Vieles davon wird von Greg Smith abstammen, das ändere ich ja nicht.

Ich glaube mal es ist genug Lesestoff für die nächste Zeit, dann wirst du ja ausreichend beschäftigt sein. Das ändert auch nichts daran, dass es genauso programmiert werden muss wie beschrieben, ich hätte dir ja die UNI verlinken können. Nur was willst du damit? Die nehmen dich eher nicht.
 
Zuletzt bearbeitet:
Könnte es auch sein, dass diese Ampere-Karte die 1080TI als erstes ersetzt und die GTX 1070/1080/1070Ti erstmal noch ein bisschen weiterlaufen, was meint ihr?
 
@Holzmann
Meinst du, du wirkst durch dein neues Profilbild kompetenter?

Sorry für OT. :cool:
 
satuan schrieb:
Ja - Paddy du bist so cool, du mit deinen 2 Cents die soviel wert sind wie ...
Zum Vergrößern anklicken....

Oh Oh Oh, da wird aber jemand zickig. :d


satuan schrieb:
Aber spekulativ gesehen, war ich vermutlich der Fragesteller? Dann solltest du es auch als solches kennzeichnen.
Zum Vergrößern anklicken....

Was spielt das für eine Rolle?

Das was hier gekennzeichnet werden sollte bzw. sogar muss, ist deine Übersetzung von fremden Gedankengut. Du machst hier einfach den Guttenberg und willst das als deine Leistung .... Excuse me ... deinen Background verkaufen. Verlink das nächste mal einfach den Text, welchen du übersetzt oder wiedergibst, und gut ist => So was müsste man als Student eigentlich wissen :wink:

Btw. Das ist mir jetzt nicht zum ersten Mal aufgefallen, dass du einfach irgendwelche Sachen abschreibst oder irgendwelche Begriffe in den Raum wirfst, die du wohl mal irgendwo auf geschnappt hast. Aber mach du mal, ist nicht mein Bier. :d


satuan schrieb:
Ich glaube mal es ist genug Lesestoff für die nächste Zeit, dann wirst du ja ausreichend beschäftigt sein.
Zum Vergrößern anklicken....

Joa, falls ich es irgendwann mal brauchen sollte. Aktuell liegt mein Beschäftigungsfeld in der tollen Android-Welt. :wink:


satuan schrieb:
Nur was willst du damit? Die nehmen dich eher nicht.
Zum Vergrößern anklicken....

Naja Leute die ein Plagiat begehen, sind an Unis nicht so gerne gesehen. Ich glaube eher, dass die dich nicht nehmen ;)

Außerdem bin ich mit meiner jetzigen Uni ganz zufrieden. :wink:
 
Nach allem was so spekuliert wird, kommen (wohl) erst die "Kleinen" dran, also 1170/1180 (oder 2070/2080). Dickschiff 1180Ti (oder 2080Ti) erst später (in 2019).
 
Dies mal ist es nicht wohl so klar:

CEO Jensen Huang sagte vor kürzerem in der Öffentlichkeit:
"Eine weitere Frage zielte wohl auf die kommende Geforce-Generation ab und wollte eine Antwort mit Ausblick auf April bis Juli 2018. Hier erklärte Huang, dass man nichts für April oder Juli angekündigt habe und Pascal weiter die beste Spiele-Plattform der Welt sei. Er gehe davon aus, das Pascal "für die absehbare Zukunft" auch weiter die beste Spieleplattform sei - immerhin gäbe es Produkte von 99 bis 1.000 US-Dollar. Nvidia über GPUs und Krypto: "Wir liefern 10x so viele GPUs" wie AMD

Somit könnte ich mir durchaus vorstellen, dass die Pascal Reihe noch weiter läuft auch nach der Vorstellung von Ampere als TOP-Dog.
 
Zuletzt bearbeitet:
26.03.-29.03.2018 findet die "GPU Technology Conference". Wer weiss, vielleicht erfahren wir dann mehr ;).

@Holzmann
Interessanter Artikel in deinem Link. Allerdings kann er die Frage was nun zuerst kommt (Midrange bzw. Butter und Brotklasse - so wie bisher - oder Topdog) nicht beantworten. Ich halt mich da an die Erfahrungen der Vergangenheit und da kamen zunächst erst alle Grakas ohne größte Zahl+Ti im Namen raus^^.
 
Zuletzt bearbeitet:
Ich werde dieses Jahr keine GPU Kaufen. Erst 2019 wieder alle meine Spiele laufen aktuell mit der 1080 TI in WHQL Auflösung + G-Sync gut.
Selbstverständlich möchte ich nicht NVidia Preispolitik Unterstützen.
 
Brotklasse wäre super, denn das einzige was mir GPU-mäßig fehlt ist eine kleine GTX mit genug VRAM die Spiele wie Warframe in 4K schafft, mit geringer TDP. Solange man 400 € dafür ausgeben muss wird das aber nichts. 150 € neu für eine 2050 Ti, das wäre mal was.

Da hast du recht, Ti-Wechselzyklus lohnt am meisten. Selbst wenn man keine Ti kauft, sind die X70 und X80 gegen Ende eines Releasezyklus immer günstiger, mal abgesehen von dem Miningscheiß aktuell. NVIDIA senkt stets die UVP sobald die Ti kommt.
 
angelsdecay schrieb:
Reine Dx12 games wird man nicht so schnell sehen

Das hängt mit der api selbst zusammen
Mann muss sich mit dem hardwarerescourcen beschäftigen und bekommt keinen fertigen compiler dazu
Man muss sich mit lästigen ram addressierung beschäftigen weil Dx12 gerade das bei multi cpu threadsden overhead auf einen renderhread entfernt
man muss sich mit min und max rescourcen managedment beschäftigen
in dx11 gibt es tools die das alles übernehmen man werkelt lediglich beim fertigen code herum bis die performance passt
Das ist bei dx12 nicht so teils fehlt personal die technik beherrscht und den gamecode auf Windows directx12 anpasst.
Die sind selten
Der vorteil von dx12 ist nur das man schwächere hardware besser unterstützen kann und in zukunft den takt limit der cpu herabsetzt für die gebotene drawcalls
also mehr drawcalls für weniger cpu taktzyklen
Damit kann man schneller werden als derzeit mit 3840 shader (nvidia) bzw 4096 shader(amd)
das problem ist nicht die gpu leistung die ist da, das Problem ist die cpu das max an drawcalls erreicht ist und nur noch unrealistische 5,2ghz das aufhebt
wohlgemerkt an derzeitigen limit in 1080p mit 3840shader.
Geht man in die Auflösung herauf sind die drawcalls indentisch aber wehe man designt ein game nach 4k dann wird die cpu zum Flaschenhals wie bei 720p


Amd navi ist ein shrink von fiji nummer 3
da erwarte ich dieselbe Leistung wie derzeit zur gtx1080 mit annehmbaren tdp um die 160w anstatt 300w
erst nach navi also amd gpu next wird amd aufschließen und das ist erst 2021
Bis dahin wird nvidia den Markt beherrschen und entsprechend bei etwas mehr Leistung die preise anheben
Wichtig ist ob amd mit navi die bis dahin eventuell volta Leistung des einsteigerchip (gv106) erreicht und diesen für nur 250$ hergibt
Das zwingt nvidia früher mit volta zu kommen um die Preistruktur zu bewahren
Bis volta wird ein pascal refresh kommen
ampere ist die neue arch ab 2019 HPC, 2021-2 desktop

alles andere wäre kaufmännisch Sinnfrei.
Zum Vergrößern anklicken....

Spätestens mit dem Ende von Win7 werden wir etliche DX12-only-Titel sehen, weil bis dahin auch alle Engines das als leicht zugänglichen Renderer anbieten werden. Bis dahin hat sich die veränderte Art der Entwicklung, die man bei LL-APIs machen muss auch durchgesetzt haben, sprich, es gibt entsprechende Erfahrung, entsprechenden einsetzbaren Code und entsprechende Tools. Die Hardwarebetrachtung ist da vollkommen irrelevant, denn bis 2020 spielt Pascal eh keine tragende Rolle mehr. Es wird ja alles soweit unterstützt und wie schnell das läuft ist weitgehend egal. Die Softwarebetrachtung ist entscheidend. Auch DX11 hat 2 Jahre gedauert, bis es sich halbwegs durchgesetzt hatte und da erforderte nicht so ein krasses Umdenken im Softwaredesign wie LL. Das ist nunmal der Lauf der Dinge.
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Ähnliche Themen

HWL News Bot
Vera Cooper Rubin: Codename für NVIDIAs übernächste GPU-Architektur
Antworten
0
Aufrufe
364
HWL News Bot
HWL News Bot
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh