DirectX 11.2 in Windows 8.1 Preview

[Demirug]

8.1 bekommt ein kleines DX Update. Bisher konnte ich folgenden DXGI Neuerungen finden.

IDXGIDevice3.Trim: Eine Function mit der eine App die in Suspend geht Resourcen freigeben kann.

IDXGIOutput2.SupportsOverlays: Überprüft ob multipane overlay support zur Verfügung steht. Ich bin im Moment nicht sicher welche Auswirkungen das hat.

IDXGISwapChain2
- GetFrameLatencyWaitableObject: Handle um auf den nächsten Frameupdate zu warten

-GetMatrixTransform
-SetMatrixTransform: Eine Matrix um die Back buffer Presentation zu beinflussen.

-GetMaximumFrameLatency
-SetMaximumFrameLatency: Anzahl der Frames die maximal in der Queue sein dürfen.

-SetSourceSize
-GetSourceSize: Ändert den Bereich des Backbuffers der aneziegt werden soll ohne die größe des Backbuffers selbst zu ändern.

Für Direct3D 11.2 ist dort die Liste: http://msdn.microsoft.com/en-us/library/windows/desktop/dn312084(v=vs.85).aspx

[Ronny145]

Ach deswegen WDDM 1.3 Treiber. Mal sehen was Microsoft sonst noch zu Direct3D 11.2 sagt. Die Session ist für heute angesetzt.

[-/\-CruNcher-/\-]

http://channel9.msdn.com/Events/Build/2013/3-062

[Godmode]

8
IDXGISwapChain2
- GetFrameLatencyWaitableObject: Handle um auf den nächsten Frameupdate zu warten


-GetMaximumFrameLatency
-SetMaximumFrameLatency: Anzahl der Frames die maximal in der Queue sein dürfen.


Könnte das schon eine Auswirkung der SLI/CF Micro-Stuttering-Diskussionen sein?

[Skysnake]

Gut möglich und eine Lösung die 1000 mal besser ist als irgend welche Alleingänge von AMD und nVidia.

Jetzt muss sich nur noch zeigen, wie gut die Sache ist.

[boxleitnerb]

Die Alleingänge bzw. der Alleingang hat den Kunden aber bereits jahrelang genutzt. Ich glaube außer dir will keiner auf den St. Nimmerleinstag warten bis sowas irgendwann mal vielleicht brauchbar umgesetzt wird. Frei nach Mediamarkt: Genießt du schon oder wartest du noch?

[Skysnake]

Wenn der Kunde halt einfach mals Maul aufmachen würde, würde sich da auch mehr tun...

Und wenns halt einfach niemanden interessiert, ist es auch durchaus ok, wenn da kaum/keine Ressourcen rein gesteckt werden. Die fehlen nämlich ansonsten an anderer Stelle.

Und das "außer dir" kannst du dir sparen, denn offensichtlich interessiert es eigentlich nur eine kleine Randgruppe überhaupt, sonst hätte sich da schon viel früher viel mehr getan, und ein viel größerer Aufschrei durch die Käuferschaft gehen müssen, was aber nicht der Fall ist.

Dennoch begrüße ich, das man sich dem Thema annimmt. In Anbetracht der APUs ist es einfach sinnvoll, da es gut wäre, wenn man diese vernünftig mit dedizierten GPUs koppeln könnte, und auch für große MCM APUs ist es wohl interessant.

[boxleitnerb]

Du bist der einzige, der immer einen Riesenaufstand macht und den Kunden funktionierende Lösungen vorenthalten will. Pragmatismus gewinnt.

[Rente]

Bei Installation der Preview wird für nVidia-Karten auch direkt ein passender WDDM1.3-Treiber installiert, großartige Vorteile sollten sich abseits der Latenzgeschichten aber wohl nicht ergeben wenn ich die Punkte von Demi richtig verstehe.

[Skysnake]

Du bist der einzige, der immer einen Riesenaufstand macht und den Kunden funktionierende Lösungen vorenthalten will. Pragmatismus gewinnt.
Weil es die große Masse der Kunden nen feuchten Dreck interessiert, genau wie dieses Forum und die "BQ-Nazis".

Die schert es einfach nicht, deswegen melden Sie sich auch nicht ;)

Und vorenthalten will ich gar niemandem etwas. Ich will nur, dass der richtige Weg gegangen wird, der für ALLE am Schluss von Vorteil ist, und nicht ein Schnellschuss aus der Hüfte ist, um ein paar Fanatikern es recht zu machen.

[][immy]

handelt es sich hierbei nur um eine software-erweiterung, oder muss die hardware dafür auch irgendwas können.

[Skysnake]

Wahrscheinlich sollte man das im Treiber alles per Software regeln können, also die prinzipielle Kompabilität/Funktionsweise.

Dass das dann auch Performant und gut nutzbar ist, könnte aber eventuell Änderungen an der Hardware nötig machen.

Wird man also wohl abwarten müssen, wie die SAchen eben genau! aussehen.

[Kladderadatsch]

"es ist kein dx12 geplant" heißt also dx11.1-9:confused:

[HPVD]

schöne Zusammenfassung was Directx 11.2 bringt:
http://www.golem.de/news/direct3d-directx-11-2-soll-spiele-schneller-machen-1306-100052.html

[Coda]

Das größte Feature sind wohl partial residential textures a.k.a. tiled resources. Gut.

[AnarchX]

Das größte Feature sind wohl partial residential textures a.k.a. tiled resources. Gut.

Wohl auch auf 11_0 HW verfügbar: http://forum.beyond3d.com/showpost.php?p=1760037&postcount=6797

[Ronny145]

Wohl auch auf 11_0 HW verfügbar: http://forum.beyond3d.com/showpost.php?p=1760037&postcount=6797


Nur zur Hälfte.


while the second tier requires DX11_1 feature level as the base

[Skysnake]

Und damit BÄM into nVidia-Face....

Da bedeutet dann, wenn ich das richtig verstanden habe, dass die AMD Karten, da 11.1 fähig auch 11.2 bekommen können!, sofern halt AMD das will, nVidia aber in die Röhre schaut und eben auf 11.0 sitzen bleibt.

[del_4901]

Und damit BÄM into nVidia-Face....

Da bedeutet dann, wenn ich das richtig verstanden habe, dass die AMD Karten, da 11.1 fähig auch 11.2 bekommen können!, sofern halt AMD das will, nVidia aber in die Röhre schaut und eben auf 11.0 sitzen bleibt.

Nein, Nvidia und ATi haben einfach andere Implementierungen fuer "Tiled Resources".

[Skysnake]

Da sagt das Zitat von Ronny aber was anders aus. Ich bin jetzt mal davon ausgegangen, dass das korrekt ist.

[AnarchX]

Baumann sagt doch auch nur, dass es zwei Stufen innerhalb von Tiled Resources gibt. Wohl ähnlich wie bei den Compute Shadern.

TR 11_0 müsste aber dann auch von Pre-Kepler 11_0 HW ausgeführt werden können?

[fondness]

AMD scheint es jedenfalls mit dem neuen Treiber bereits zu unterstützen:
New DX11.1 feature – Tiled Resources

http://support.amd.com/us/kbarticles/Pages/AMDCatalystWIN8-1PreviewDriver.aspx

[Skysnake]

warum spricht man aber von DX11.1? :ugly:

Wurde DX11.1 etwa nachträglich erweitert? Oder wie oder was?

[dildo4u]

Die zweite Demo lief auf einer GTX770.

http://youtu.be/EswYdzsHKMc

Er sagt auch das sie mit NV,AMD und Intel zusammengearbeitet haben.Eigentlich müsste es dann auch auf Fermi funzen.

[Coda]

Ohne Hardware-Support fehlt einem halt wohl Filtering über die Tile-Grenzen hinweg etc. Nützt nicht viel.

[Schaffe89]

AMD dürfte damit ziemlich sicher mit den HD 8XXX Karten das Directx 11.2 Plaketterl bekommen.
Nvidia dürfte damit wohl erst 2014 kommen.

[Skysnake]

denke ich auch.

Wäre ja auch irgendwie ziemlich strange, wenn man 11.2 unterstützt, welches soweit ich das verstanden habe eben 11.1 voraussetzt, man selbst aber nur 11.0 unterstützt :ugly:

Jetzt aber kurz mal was GANZ anders.
Könnt ihr nachvollziehen, warum nVidia zulässt, dass so etwas überhaupt passiert? :ugly:

Ich mein die sind ja auch nicht auf den Kopf gefallen. Warum lassen die dann solche Specs durch, und versuchen nicht mittels Kopfstand das zu unterbinden, oder wenigstens nur optional zu machen, damit Sie ihr DX11.2 Plakkern auch drauf kleben dürfen..

[Kriton]

Was ist mit:

http://www.golem.de/news/direct3d-directx-11-2-soll-spiele-schneller-machen-1306-100052.html

Hardware Overlays

Eine der großen Neuerungen in DirectX 11.2 ist die Unterstützung für Hardware Overlays. Das ermöglicht es, zwei unabhängig voneinander gerenderte Ebenen übereinanderzulegen, beispielsweise, um 3D-Grafik und Einblender voneinander getrennt zu berechnen. So erscheinen Einblendungen scharf, da sie in hoher Auflösung gerendert wurden, auch wenn die 3D-Auflösung verringert wird, um hohe Frame-Raten von 60 Bildern pro Sekunde sicherzustellen.

Sofern es von der Hardware unterstützt wird, können beide Ebenen ohne zusätzlichen Rechenaufwand mit vollem Alphablending zusammengefügt werden.

Das lässt sich nicht nur mit statisch festgelegten Auflösungen nutzen, sondern Spiele können die Auflösung beider Ebenen, die als unabhängige Swap-Chains umgesetzt sind, dynamisch verändern. So kann ein Spiel die Auflösung in besonders rechenintensiven Szenen reduzieren, um eine flüssige Darstellung sicherzustellen. Zudem ist es möglich, das in vielen Spielen genutzte HUD mit einer sehr geringen Frame-Rate in hoher Auflösung zu rendern, schließlich ändert sich dieses oft nur einmal pro Sekunde.

Wird die Auflösung dabei nur leicht gesenkt, soll dies für Spieler kaum wahrnehmbar sein, das Spiel fühlt sich aber schneller an, so Microsoft.

Klingt nach 11.2 HW. Oder irre ich da?

Heißt ja auch:

Einige der Neuerungen funktionieren dabei mit vorhandener Hardware, manche setzen neue Treiber und zum Teil auch entsprechende Hardwareunterstützung voraus.

Aber kenne mich da zu wenig aus und lasse mich gern eines Besseren belehren. Aber da ich gerade an Aufrüstung denke (trotz Heatwell) und derzeit bei Nvidia eh schon wegen 11.0 zögere wäre es interessant zu wissen ob es mit 11.2 weitere HW-Anforderungen gibt.

[Coda]

Die Doku ist mittlerweile wirklich extrem grottik. Ich hab immer noch nicht rausgefunden, was genau wann und wie bei Tiled Resources unterstützt wird. Was ist bei 11.0-Hardware noch verwendbar und was nicht?

Übrigens sollte jegliche GCN-Hardware das vollständig unterstützen können also auch die HD-7000-Karten.

[-/\-CruNcher-/\-]

denke ich auch.

Wäre ja auch irgendwie ziemlich strange, wenn man 11.2 unterstützt, welches soweit ich das verstanden habe eben 11.1 voraussetzt, man selbst aber nur 11.0 unterstützt :ugly:

Jetzt aber kurz mal was GANZ anders.
Könnt ihr nachvollziehen, warum nVidia zulässt, dass so etwas überhaupt passiert? :ugly:

Ich mein die sind ja auch nicht auf den Kopf gefallen. Warum lassen die dann solche Specs durch, und versuchen nicht mittels Kopfstand das zu unterbinden, oder wenigstens nur optional zu machen, damit Sie ihr DX11.2 Plakkern auch drauf kleben dürfen..

Meine these diesbezüglich ist immernoch das es eine Kosten Nutzen Rechnung von Nvidia ist haben sie schon früher so beimr DSP gemacht wo AMD full support durchweg full Bitstream Decoding support durch die Bank hatte auch für WMV VLD (volles bitstream decoding) da hat Nvidia es in den Desktop Karten einfach weg gelassen nur die Laptop und Low End Karten (Chips) haben den vollen bitstream decoding support bekommen.
Logischer Gedanke der dahinterstand muss wohl folgender gewesen sein "Nutzer die eine High End Discrete Karte haben sollten auch die entsprechende CPU Power haben um WMV VLD decoden zu können, also wieso sollen wir transistoren resourcen und somit Geld verschwenden wenn es für die meisten Desktop user keinen sinn macht 1080p HD-DVD wird funktionieren ob jetzt mit 80% CPU usage oder 10%"
Laptop und Low End user können von dem Hardware Decoding aber profitieren :)
Oder aber Nvidia hat den Untergang von HD-DVD schon kommen sehen ;)

AMD dachte von Anfang an nicht so für sie war immer alles gleichgestellt in den features egal ob Laptop Low End oder High End man ist nicht diese 2 schienen gefahren und scheint so das bei DirectX 11.1 das wieder der Fall war das Nvidia den Kostent Nutzen nicht erkannt hat und einfach sparen wollte um so auch vieleicht die Resourcen anders zu verteilen, was das angeht scheint Nvidia eine sehr harte linie zu fahren.

Und so gesehen ist schon beachtlich was AMD mit der GCN architektur erreicht hat von den featuresets wieder alles drin egal ob laptop,desktop,mobile und trotzdem performanter und billiger :)

Bin selbst seit zig jahren wieder Nvidia user 9800 pro war meine letzte ATI karte (HD 3400 hatte ich gekauft aber nie eingebaut weil die 8800 GT einfach genial war) aber seit GCN bin ich echt am Überlegen mal wieder zu wechseln ;)

Allerdings ist Nvidia wieder an der Reihe ihre neue Generation zu präsentieren da könnten sie alles wieder korrigieren :)

[AnarchX]

There are over 90 million NVIDIA GPUs capable of supporting Tiled Resources
http://blogs.nvidia.com/blog/2013/06/26/higher-fidelity-graphics-with-less-memory-at-microsoft-build/

Eventuell doch nicht nur Kepler?

[Coda]

Fraglich. Bevor man nicht weiß was genau unterstützt wird kann man dazu nichts sagen.

Meine Vermutung wäre, dass man irgendwie bindless textures verwendet. Wie? - keine Ahnung.

[boxleitnerb]

Weil es die große Masse der Kunden nen feuchten Dreck interessiert, genau wie dieses Forum und die "BQ-Nazis".

Die schert es einfach nicht, deswegen melden Sie sich auch nicht ;)

Und vorenthalten will ich gar niemandem etwas. Ich will nur, dass der richtige Weg gegangen wird, der für ALLE am Schluss von Vorteil ist, und nicht ein Schnellschuss aus der Hüfte ist, um ein paar Fanatikern es recht zu machen.

Es ist egal, ob einer oder 1000 profitieren - profitiert wird so oder so.

Doch, du willst es anderen vorenthalten aus deinen verqueren Vorstellungen heraus. Es spricht überhaupt nichts gegen eine zeitweilige Lösung, bis später (wenn überhaupt) eine allgemeine Lösung gefunden wird. Nennt sich Innovation, und dagegen bist du. Wo wären wir heute als Gesellschaft, wenn in den letzten 200 Jahren alle so gedacht hätten wie du? Glaubst du, die ersten Autobauer haben sich um irgendwelche Normen geschert oder branchenübergreifende Lösungen? Alles fängt klein an bei wenigen, die Innovationen hervorbringen und erst später breitet sich das dann aus und wird von den anderen aufgegriffen. Das ist der ganz normale Gang in der Wirtschaft. Nvidia hätte sich das Framemetering patentieren lassen sollen, das wäre nur recht gewesen.

[Schaffe89]

Framemetering patentieren lassen?

[boxleitnerb]

Warum nicht? Wenn man etwas entwickelt hat, warum soll man es sich nicht patentieren lassen? Wenn es nach Skysnake ginge, hätte 3dfx SLI und Glide nie herausbringen dürfen. Von DirectX haben übrigens auch nicht alle etwas - Linux und Mac z.B. Soll man jetzt die letzten 20 Jahre Gaming ausradieren und stattdessen gemütlich warten, bis OpenGL sich in dem Umfang durchsetzt, wie wir es von DirectX kennen? Das ist so lächerlich, wenn man mal darüber nachdenkt. Ich wette 100 Euro, wenn es umgekehrt gewesen wäre und AMD mit AA-Bits, Framemetering usw. angekommen wäre, von ihm hätte es keinen Mucks gegeben, aber keinen einzigen.

[fondness]

Warum nicht? Wenn man etwas entwickelt hat, warum soll man es sich nicht patentieren lassen?

Na eh, 3dfx hätte sich SSAA patentieren lassen sollen, oder am besten gleich den Grafikchip als ganzes, dann hätte man keine lästigen Konkurrenten gehabt. ;D

[Match-Maker]

Es ist egal, ob einer oder 1000 profitieren - profitiert wird so oder so.

Doch, du willst es anderen vorenthalten aus deinen verqueren Vorstellungen heraus. Es spricht überhaupt nichts gegen eine zeitweilige Lösung, bis später (wenn überhaupt) eine allgemeine Lösung gefunden wird. Nennt sich Innovation, und dagegen bist du. Wo wären wir heute als Gesellschaft, wenn in den letzten 200 Jahren alle so gedacht hätten wie du? Glaubst du, die ersten Autobauer haben sich um irgendwelche Normen geschert oder branchenübergreifende Lösungen? Alles fängt klein an bei wenigen, die Innovationen hervorbringen und erst später breitet sich das dann aus und wird von den anderen aufgegriffen. Das ist der ganz normale Gang in der Wirtschaft.
(y)

[Gipsel]

Warum nicht?Die Erfindungshöhe ist gleich Null.

[Coda]

Könnte das schon eine Auswirkung der SLI/CF Micro-Stuttering-Diskussionen sein?
Hat damit überhaupt nichts zu tun, das bestimmt nur die maximale Anzahl an Frames im Render-Buffer. Kannst du auch im Treiber einstellen.

[boxleitnerb]

Die Erfindungshöhe ist gleich Null.

Wie kannst du das beurteilen, kennst du die Implementierung (inzwischen auch in Hardware)? In Zeiten, in denen simpelste Smartphonedesigns (Box mit vier abgerundeten Ecken :freak:) patentiert werden, sehe ich da kein Problem.

[Gipsel]

Wie kannst du das beurteilen, kennst du die Implementierung (inzwischen auch in Hardware)? In Zeiten, in denen simpelste Smartphonedesigns (Box mit vier abgerundeten Ecken :freak:) patentiert werden, sehe ich da kein Problem.
Eine Erfindungshöhe ist nur gegeben, wenn der Durchschnittsfachmann mit Kenntnis aller bisher bekannten Techniken nicht in einfacher Weise auf diese Lösung kommt. Stottern durch Messen der Zeiten und entsprechendes Einfügen von Wartezeiten möglichst zu vermeiden ist eine absolut triviale Idee, da braucht man gar nicht drüber zu diskutieren. Auf diese Lösung kommt sogar ein Nichtfachmann. :freak:
Wie man das genau implementiert, ist dabei vollkommen nebensächlich.

Allgemein bin ich ein absoluter Gegner von Trivialpatenten. Alles was man sofort kapiert und man nicht mindestens 5 Minuten erklären muß, ist meiner Meinung nach nicht patentwürdig. :D

[Coda]

Seh ich auch so.

[Actionhank]

Allgemein bin ich ein absoluter Gegner von Trivialpatenten. Alles was man sofort kapiert und man nicht mindestens 5 Minuten erklären muß, ist meiner Meinung nach nicht patentwürdig. :D
Diese Definition ist totaler Quatsch. Als ob sich eine Innovation durch Komplexität definiert.

[Gipsel]

Diese Definition ist totaler Quatsch. Als ob sich eine Innovation durch Komplexität definiert.Wenn jeder Honk auf die Lösung kommt und/oder sie sofort versteht (man sie ihm also nicht erklären muß), kann es ja wohl kaum eine große Innovation sein. :rolleyes:

[Actionhank]

Wenn jeder Honk auf die Lösung kommt und/oder sie sofort versteht (man sie ihm also nicht erklären muß), kann es ja wohl kaum eine große Innovation sein. :rolleyes:
Das ist einfach Unfug. Nur weil etwas einfach zu verstehen ist, heißt das noch lange nicht, dass jeder sofort auf die Idee kommt. Vielleicht solltest du noch einmal über den Spruch "Einfach genial, genial einfach." nachdenken.

[Skysnake]

Es ist egal, ob einer oder 1000 profitieren - profitiert wird so oder so.

Nein ist es nicht, da du jeder €/$ nur einmal ausgeben kannst, und nVidia sollte sich wirklich lieber um ihre Treiber aktuell kümmern anstatt solche Ferz zu machen...


Doch, du willst es anderen vorenthalten aus deinen verqueren Vorstellungen heraus. Es spricht überhaupt nichts gegen eine zeitweilige Lösung, bis später (wenn überhaupt) eine allgemeine Lösung gefunden wird. Nennt sich Innovation, und dagegen bist du. Wo wären wir heute als Gesellschaft, wenn in den letzten 200 Jahren alle so gedacht hätten wie du? Glaubst du, die ersten Autobauer haben sich um irgendwelche Normen geschert oder branchenübergreifende Lösungen? Alles fängt klein an bei wenigen, die Innovationen hervorbringen und erst später breitet sich das dann aus und wird von den anderen aufgegriffen. Das ist der ganz normale Gang in der Wirtschaft.
Nö, ich will dir gar nichts vorenthalten, ich erinnere nur daran, dass hier die Interessen nur SEHR weniger gepushed werden, und man dabei dann aus den Augen verliert, das es durchaus wichtigeres gibt. Vor allem aber sich unnötig arbeit macht, weil vernünftig man das eh nur mit standardisierten Interfaces lösen kann. Davon haben dann auch am Ende alle etwas.

Das ist der vernünftige Weg. Der bremst auch nicht wirklich Innovationen aus... Man kann so was wie AA Bits/Framemetering auch nicht mit grundlegend neue Techniken vergleichen. Das ist alles nichts wirklich revolutionäres Neues.

Techniken, die sich nicht an gegebene Standards halten, gehen oft unter. Man muss da einfach den Mittelweg suchen. Schau dir GPU-PhysX an. Das ist im Prinzip nen lebender Zombi, weil nVidia unbedingt auf ihre propritären Schnittstellen setzen musste... Hätten Sie das alles offen gemacht, und z.B. der Khronos-Gruppe oder vergleichbar übergeben, hätte wir schon lange GPU-PhysX in allen möglichen Spielen...

Es ist eben NICHT so, dass hauptsache schnell etwas kommen muss. Es muss auch nachhiltig und entwicklungsfähig sein. Das verliert ihr aber aus den Augen. Da regiert nur noch das "ich will ich will ich will".


Nvidia hätte sich das Framemetering patentieren lassen sollen, das wäre nur recht gewesen.

Dem fehlt die Schöpfungshöhe. Das Patentamt, dass das patentiert gehört eins über die Rübe gezogen.

Warum nicht? Wenn man etwas entwickelt hat, warum soll man es sich nicht patentieren lassen? Wenn es nach Skysnake ginge, hätte 3dfx SLI und Glide nie herausbringen dürfen.
Kannst du nicht vergleichen.

3dfx hatte eine sehr einfache API gebracht, und es war absolut noch nicht absehbar, was sich durchsetzt am Ende. Letzten Endes hat sich 3dfx damit aber womöglich keinen gefallen getan. Wissen werden wir es nie. Sie haben es ja nicht überlebt. Eine Öffnung und Kooperation mit den anderen Marktteilnehmern hätte Sie vielleicht überleben lassen, wer weiß.


Von DirectX haben übrigens auch nicht alle etwas - Linux und Mac z.B. Soll man jetzt die letzten 20 Jahre Gaming ausradieren und stattdessen gemütlich warten, bis OpenGL sich in dem Umfang durchsetzt, wie wir es von DirectX kennen?

Ja, es wäre besser gewesen, wenn sich OpenGL durchgesetzt hätte, hat es aber eben nicht, weil dort auch Fehler gemacht wurden. MS hat halt eine Zeit lang ziemlich viel richtig gemacht, oder richtiger gemacht, und eben die Hardware und Softwarehersteller auf ihr Seite bekommen.


Das ist so lächerlich, wenn man mal darüber nachdenkt. Ich wette 100 Euro, wenn es umgekehrt gewesen wäre und AMD mit AA-Bits, Framemetering usw. angekommen wäre, von ihm hätte es keinen Mucks gegeben, aber keinen einzigen.
Wette schon verloren ;)

Ich hab AMD für ähnliches auch schon kritisiert. Und bzgl Framemetering ist dir meine Kritik an AMD wohl auch entgangen... Manche Leute lesen scheinbar nur das, was in ihr Weltbild passt :P

[Elkinator]

für einige hier ist das echt schwer zu verstehen?

DX11.2 setzt hardwareunterstützung von DX11.1 voraus, jede DX11.1 karte unterstützt automatisch auch DX11.2.

[boxleitnerb]

Nein ist es nicht, da du jeder €/$ nur einmal ausgeben kannst, und nVidia sollte sich wirklich lieber um ihre Treiber aktuell kümmern anstatt solche Ferz zu machen...


Als ob du wüsstest, wieviel Geld man reingesteckt hat. Außerdem kann man das dann zu allem sagen. SSAA, Eyefinity, HD3D/3DVision usw. - nutzt nur wenigen, also streichen wir es, gibt kein Geld für die Entwicklung :freak:


Nö, ich will dir gar nichts vorenthalten, ich erinnere nur daran, dass hier die Interessen nur SEHR weniger gepushed werden, und man dabei dann aus den Augen verliert, das es durchaus wichtigeres gibt. Vor allem aber sich unnötig arbeit macht, weil vernünftig man das eh nur mit standardisierten Interfaces lösen kann. Davon haben dann auch am Ende alle etwas.


S.o.
Wer beurteilt, was wichtig ist und was nicht? Du? Und nur weil etwas nicht standardisiert ist, kann es dennoch vernünftig funktionieren bzw. es ist überhaupt nicht garantiert, dass die standardisierte Lösung gleich gut oder gar besser funktioniert (wenn sie denn überhaupt kommt!). Und schlussendlich (zum x-ten Mal): Alle können immer noch etwas davon haben, aber BIS DAHIN hat wenigstens ein Teil des Marktes etwas davon. Und das ist besser als gar nichts.


Das ist der vernünftige Weg. Der bremst auch nicht wirklich Innovationen aus... Man kann so was wie AA Bits/Framemetering auch nicht mit grundlegend neue Techniken vergleichen. Das ist alles nichts wirklich revolutionäres Neues.

Techniken, die sich nicht an gegebene Standards halten, gehen oft unter. Man muss da einfach den Mittelweg suchen. Schau dir GPU-PhysX an. Das ist im Prinzip nen lebender Zombi, weil nVidia unbedingt auf ihre propritären Schnittstellen setzen musste... Hätten Sie das alles offen gemacht, und z.B. der Khronos-Gruppe oder vergleichbar übergeben, hätte wir schon lange GPU-PhysX in allen möglichen Spielen...

Es ist eben NICHT so, dass hauptsache schnell etwas kommen muss. Es muss auch nachhiltig und entwicklungsfähig sein. Das verliert ihr aber aus den Augen. Da regiert nur noch das "ich will ich will ich will".


Wenn es untergeht, geht es eben unter und wird von einer konkurrierenden Lösung (offen oder nicht offen) ersetzt (oder auch nicht...). Nvidia hätte also nach all dem monetären Aufwand den ganzen Kram umsonst abgeben sollen? Sehr realistisch. Und wieder: Es ist besser als nichts. Wo sind die anderen Lösungen damals gewesen? Ageia wäre ohne Nvidia komplett untergegangen und niemand hätte was davon gehabt. Jetzt haben wenigstens 60+% des Marktes die Möglichkeit, ab und zu ein paar nette Effekte zu sehen. Und erzählt mir jetzt nicht, dass GPU-PhysX die Entwicklung eines offenen Standards ausgebremst hätte - dazu ist es viel zu wenig verbreitet und praktisch nicht relevant in der Gesamtbetrachtung.

Und ich widerspreche dir hier ganz klar:
Auf Standards, die irgendwann mal vielleicht kommen mögen, zu warten, ist definitiv das Ausbremsen und Verhindern von Innovationen. Sich einigen, Konsens finden dauert viel Zeit. Zeit, in der die Entwicklung stehenbleiben würde, wenn einzelne diese Phase nicht schon für eigene Lösungen nutzen würden. Die Geschichte gibt mir Recht - es haben eigentlich immer einzelne Personen/Unternehmen neue Dinge entwickelt. Selbst wenn du mir zehn Beispiele nennen könntest, wo dies nicht so war und Standards die Entwicklung vorangetrieben haben, nenne ich dir Zehntausend Fälle, wo es anders war.


Kannst du nicht vergleichen.

3dfx hatte eine sehr einfache API gebracht, und es war absolut noch nicht absehbar, was sich durchsetzt am Ende. Letzten Endes hat sich 3dfx damit aber womöglich keinen gefallen getan. Wissen werden wir es nie. Sie haben es ja nicht überlebt. Eine Öffnung und Kooperation mit den anderen Marktteilnehmern hätte Sie vielleicht überleben lassen, wer weiß.


Klar ist es vergleichbar - Glide war nur auf 3dfx-Karten möglich, Punkt. Direct3D lief auf allen GPUs. Dasselbe mit SLI. Genau wie die Bits und Framemetering nur auf Nvidia-GPUs möglich sind, nicht auf AMD. Proprietäre Technik eben.


Ja, es wäre besser gewesen, wenn sich OpenGL durchgesetzt hätte, hat es aber eben nicht, weil dort auch Fehler gemacht wurden. MS hat halt eine Zeit lang ziemlich viel richtig gemacht, oder richtiger gemacht, und eben die Hardware und Softwarehersteller auf ihr Seite bekommen.


Siehst du, du gibst es ja schon selbst zu - es wurden Fehler gemacht, also ist auch die standardisierte Lösung nicht unbedingt erstrebenswert. Wo bleibt dein Aufschrei im Fall DirectX? Nur ein schlappes "wäre besser gewesen"...aber wenn es um Nvidia-Technologien geht, gibt es seitenlanges beißendes Gemecker von dir. Merkst du das echt nicht? Warum misst du mit zweierlei Maß?


Wette schon verloren ;)

Ich hab AMD für ähnliches auch schon kritisiert. Und bzgl Framemetering ist dir meine Kritik an AMD wohl auch entgangen... Manche Leute lesen scheinbar nur das, was in ihr Weltbild passt :P

Alibi-Kritik, damit machst du mir nichts vor.

[Gipsel]

Das ist einfach Unfug. Nur weil etwas einfach zu verstehen ist, heißt das noch lange nicht, dass jeder sofort auf die Idee kommt. Vielleicht solltest du noch einmal über den Spruch "Einfach genial, genial einfach." nachdenken.Da gibt es schon eine recht starke Korrelation (und damit etwas patentwürdig ist, darf ein Fachmann nicht einfach darauf kommen). Und die Zeiten der simplen Erfindungen sind schon eine Weile vorbei. Heute kann man sich sicher sein, daß jede "einfache" Idee in einem gut etablierten Feld bereits jemand Anderes gehabt hat. Was es aber geben kann, sind im Endeffekt relativ einfache Lösungen, wo man aber ein wenig grübeln (oder einer einem das erklären) muß, warum es eigentlich funktioniert. Aber einfache Lösungen, bei denen sofort klar ist, warum es funktioniert, sind trivial und damit nicht patentwürdig. Deswegen stehe ich zu meiner Aussage oben.

Und praktisch gesehen gibt es heutzutage wegen der offenbaren Unfähigkeit einiger Patentämter viel zu viele Trivialpatente, die die technische Entwicklung behindern und nicht schützen und damit im Endeffekt fördern, wie das ursprünglich mal gedacht war.

[Skysnake]

S.o.
Wer beurteilt, was wichtig ist und was nicht? Du?

Du etwa?
Ich ergreife nur das Wort für diejenigen, die das Thema komplett am Arsch vorbei geht.

So was nennt sich Meinungsfreiheit/Demokratie, wenn jeder seine Meinung kund tun kann. Man kann für etwas sein, so wie ihr, man kann aber auch gegen etwas sein, so wie ich.

Ich muss am Ende auch damit leben, wenn nVidia auf euch hört, und etwas macht, auch wenn ich es für falsch halte. Genau so musst du/ihr eben auch damit leben, wenn nVidia z.B. auf mich hört, und es eben nicht macht.


Und nur weil etwas nicht standardisiert ist, kann es dennoch vernünftig funktionieren bzw. es ist überhaupt nicht garantiert, dass die standardisierte Lösung gleich gut oder gar besser funktioniert (wenn sie denn überhaupt kommt!). Und schlussendlich (zum x-ten Mal): Alle können immer noch etwas davon haben, aber BIS DAHIN hat wenigstens ein Teil des Marktes etwas davon. Und das ist besser als gar nichts.

Und wenn erst mal eine propritäre Lösung da ist, dann ist es GANZ schwer, das sich ein offener Standard durchsetzt....

Denn die Firma/en mit propritären Lösungen versuchen im Allgemein mit aller gewalt an ihrer Lösung fest zu halten, auch wenn es für den Markt und die Kunden am Ende am Besten wäre, wenn es einen offenen Standard gäbe..


Wenn es untergeht, geht es eben unter und wird von einer konkurrierenden Lösung (offen oder nicht offen) ersetzt (oder auch nicht...). Nvidia hätte also nach all dem monetären Aufwand den ganzen Kram umsonst abgeben sollen?

Nö, wie kommst du darauf? Passt halt in dein Weltbild nicht?

Man hätte schlicht fair use Lizenzen vergeben können. Man hat ja eh schon einen Vorteil, weil man eben früher angefangen hat etwas zu implementieren, und daher eben auch einen Wissens/Erfahrungsvorsprung hat. Dazu die Lizenzgebühren und gut ist.

Damit kann eine Firma durchaus leben, und es ist für die Kunden besser, da Sie eben mehrere konkurrierende Firmen haben, die sich gegenseitig pushen.


Sehr realistisch. Und wieder: Es ist besser als nichts. Wo sind die anderen Lösungen damals gewesen? Ageia wäre ohne Nvidia komplett untergegangen und niemand hätte was davon gehabt. Jetzt haben wenigstens 60+% des Marktes die Möglichkeit, ab und zu ein paar nette Effekte zu sehen. Und erzählt mir jetzt nicht, dass GPU-PhysX die Entwicklung eines offenen Standards ausgebremst hätte - dazu ist es viel zu wenig verbreitet und praktisch nicht relevant in der Gesamtbetrachtung.

Das kann keiner wirklich sagen, ob Ageia untergegangen wäre oder nicht. Ich kann mich zumindest nicht daran erinnern, das Ageia insolvent gewesen wäre. nVidia hat halt das Potenzial gesehen und sich die Firma geschnappt.

Das Ergebnis sehen wir aber auf jeden Fall heute. GPU-PhysX spielt praktisch keine Rolle, weil die Entwickler nur mit finanzieller Unterstützung nVidias GPU-PhysX einsetzen. Man kann damit schlicht nicht den gesamten Markt bedienen. Hier ist also eine ropritäre Lösung also mal wieder klar eine Technologiebremse


Und ich widerspreche dir hier ganz klar:
Auf Standards, die irgendwann mal vielleicht kommen mögen, zu warten, ist definitiv das Ausbremsen und Verhindern von Innovationen. Sich einigen, Konsens finden dauert viel Zeit. Zeit, in der die Entwicklung stehenbleiben würde, wenn einzelne diese Phase nicht schon für eigene Lösungen nutzen würden. Die Geschichte gibt mir Recht - es haben eigentlich immer einzelne Personen/Unternehmen neue Dinge entwickelt. Selbst wenn du mir zehn Beispiele nennen könntest, wo dies nicht so war und Standards die Entwicklung vorangetrieben haben, nenne ich dir Zehntausend Fälle, wo es anders war.

Einzelne Firmen haben sich auf Dauer seltenst durchgesetzt in der IT. Es lief eigentlich immer auf Entwicklungen hinaus, bei denen man versucht möglichst viele Partner zu gewinnen. Einzelaktionen sind seltenst erfolgreich bei Technik.

Klar, es gibt einzelne Firmen die Ideen haben, damit sich etwas aber bewährt und Durchsetzt sind eigentlich fast immer viele Firmen notwendig.

Und mit den "10.000 Fällen" würde ich mal nicht übertreiben. Fangen wir mal klein an, und ich nenne dir einen Fall, und du mir 10 ok? ;)

Ich werf mal Infiniband in den Raum. Hat zwar ne einzelne Firma entwickelt, aber als offenen Standard definiert, so dass die Konkurrenz immer in der Lage war eigene Produkte zu diesem Standard zu entwickeln.

Die Bedeutung von Infiniband kennst du ja oder? ;)


Klar ist es vergleichbar - Glide war nur auf 3dfx-Karten möglich, Punkt. Direct3D lief auf allen GPUs. Dasselbe mit SLI. Genau wie die Bits und Framemetering nur auf Nvidia-GPUs möglich sind, nicht auf AMD. Proprietäre Technik eben.

Die damaligen Zeiten kannst du aber nicht mit heute vergleichen. Damals gab es noch viele Hersteller und viele unterschiedliche Technologien, wo man erst schauen musste, was überhaupt etwas taugt, also was sich durchsetzen kann.

Davon sind wir heute WEIT entfernt. Bei den von dir genannten Dingen kann man klar entscheiden, ob es sinnvoll/gut ist, oder eben nicht.


Siehst du, du gibst es ja schon selbst zu - es wurden Fehler gemacht, also ist auch die standardisierte Lösung nicht unbedingt erstrebenswert. Wo bleibt dein Aufschrei im Fall DirectX? Nur ein schlappes "wäre besser gewesen"...aber wenn es um Nvidia-Technologien geht, gibt es seitenlanges beißendes Gemecker von dir. Merkst du das echt nicht? Warum misst du mit zweierlei Maß?

Daran sind aber die Partner schuld...

Das liegt nicht am Standard an sich.


Alibi-Kritik, damit machst du mir nichts vor.
Ah ja, das hast jetzt du zu entscheiden.

Vor allem, was ist denn bitte Alibi-Kritik? Entweder man kritisiert oder eben nicht. Und ich sag immer wenn ich etwas schelcht finde, egal welche Firma das ist.

PS:
Was hat das eigentlich mit dem Thema hier zu tun, als dass du das hier wieder aufwärmen musst? In der Thematik ist doch alles gesagt worden oder nicht?

[Actionhank]

Aber einfache Lösungen, bei denen sofort klar ist, warum es funktioniert, sind trivial und damit nicht patentwürdig.
Obigen Satz halte ich für falsch. Wir drehen uns im Kreis.

[Gipsel]

Obigen Satz halte ich für falsch. Wir drehen uns im Kreis.Ich habe eine Begründung dafür gegeben. Die greifst Du nicht an und lieferst keine Argumente dagegen. Damit haben wir einen Stillstand und keinen Kreis. ;)

[boxleitnerb]

Vorab:
Vielleicht könnte ein Mod die Diskussion bitte splitten?

Du etwa?
Ich ergreife nur das Wort für diejenigen, die das Thema komplett am Arsch vorbei geht.


Ja, weil ich es auch nutze und direkt betroffen bin und weiß, dass die Nutzer es schätzen. Du hast zu dem Thema überhaupt keinen Bezug.
Les dir deinen Satz nochmal durch...du brauchst das Wort für die gar nicht zu ergreifen. Erstens interessiert es die wie du sagst überhaupt nicht, als dass sie hier über dich ihre Meinung kundtun müssten. Und zweitens hat dich niemand berufen, es zu tun, zumal du diese Dinge eh nicht aus eigener Erfahrung kennst oder nutzt.


Und wenn erst mal eine propritäre Lösung da ist, dann ist es GANZ schwer, das sich ein offener Standard durchsetzt....

Denn die Firma/en mit propritären Lösungen versuchen im Allgemein mit aller gewalt an ihrer Lösung fest zu halten, auch wenn es für den Markt und die Kunden am Ende am Besten wäre, wenn es einen offenen Standard gäbe..


Quatsch, das lässt sich pauschal gar nicht sagen. Das hängt davon ab, wie mächtig die Stellung ist. DirectX kann man praktisch unmöglich vom Thron stoßen, das kleine GPU-PhysX z.B. schon.


Nö, wie kommst du darauf? Passt halt in dein Weltbild nicht?

Man hätte schlicht fair use Lizenzen vergeben können. Man hat ja eh schon einen Vorteil, weil man eben früher angefangen hat etwas zu implementieren, und daher eben auch einen Wissens/Erfahrungsvorsprung hat. Dazu die Lizenzgebühren und gut ist.

Damit kann eine Firma durchaus leben, und es ist für die Kunden besser, da Sie eben mehrere konkurrierende Firmen haben, die sich gegenseitig pushen.


Was soll der Kommentar mit dem Weltbild? Das ist völlig unangebracht.
Sie wollten eben die Technologie nicht aus den Händen geben, das kann man ihnen kaum verdenken. Der eine macht es so, der andere so.


Das kann keiner wirklich sagen, ob Ageia untergegangen wäre oder nicht. Ich kann mich zumindest nicht daran erinnern, das Ageia insolvent gewesen wäre. nVidia hat halt das Potenzial gesehen und sich die Firma geschnappt.

Das Ergebnis sehen wir aber auf jeden Fall heute. GPU-PhysX spielt praktisch keine Rolle, weil die Entwickler nur mit finanzieller Unterstützung nVidias GPU-PhysX einsetzen. Man kann damit schlicht nicht den gesamten Markt bedienen. Hier ist also eine ropritäre Lösung also mal wieder klar eine Technologiebremse


Damals war abzusehen, dass das so nichts wird. Die Karten waren teuer, die Anwendungen praktisch nicht vorhanden.
Und wie oft willst du noch etwas behaupten, was nicht stimmt? GPU-PhysX kann gar nichts bremsen, dazu ist es viel zu klein! Es ist in der Tat so klein und unbedeutend, dass es für jeden, der wollte, ein Leichtes wäre, eine Alternative herauszubringen. Da könnte Nvidia überhaupt nichts dagegen tun - wenn sie jetzt schon Mühe haben, GPU-PhysX zu verbreiten, meinst du es würde einfacher werden, wenn eine brauchbare Alternative vorhanden wäre???
Unbestreitbarer Fakt ist, dass es mit PhysX voran ging im Bereich Effektphysik. Also das Gegenteil einer Bremse. Du gehst automatisch davon aus, dass die offene Lösung auch PhysX sein muss, und das ist Unsinn. Und selbst wenn PhysX offen geworden wäre, hätte es noch lange nicht erfolgreich sein müssen, siehe OpenGL.
Havok, Bullet...gibt genug Möglichkeiten. Warum passiert da nix?


Einzelne Firmen haben sich auf Dauer seltenst durchgesetzt in der IT. Es lief eigentlich immer auf Entwicklungen hinaus, bei denen man versucht möglichst viele Partner zu gewinnen. Einzelaktionen sind seltenst erfolgreich bei Technik.

Klar, es gibt einzelne Firmen die Ideen haben, damit sich etwas aber bewährt und Durchsetzt sind eigentlich fast immer viele Firmen notwendig.

Und mit den "10.000 Fällen" würde ich mal nicht übertreiben. Fangen wir mal klein an, und ich nenne dir einen Fall, und du mir 10 ok? ;)

Ich werf mal Infiniband in den Raum. Hat zwar ne einzelne Firma entwickelt, aber als offenen Standard definiert, so dass die Konkurrenz immer in der Lage war eigene Produkte zu diesem Standard zu entwickeln.

Die Bedeutung von Infiniband kennst du ja oder? ;)


Ich sprach nicht explizit von der IT, sondern allgemein von Forschung und Technik. Und da geht praktisch jede Erfindung auf einzelne Personen oder Firmen zurück. Ob sich etwas nach nach einer Weile zum Standard mausert oder untergeht, weil bessere Lösungen erscheinen, ist dabei irrelevant. Nur damit du es weißt: Ich glaube nicht, dass GPU-PhysX überleben kann, wenn es weiter geschloßen bleibt (und Konkurrenz auftaucht). Aber das heißt noch lange nicht, dass es bis zu diesem Zeitpunkt schlecht ist. Beispiel: Nur weil sich die Länder nicht auf gemeinsame Regelungen zum Klimaschutz einigen können, soll es falsch sein, wenn einzelne Länder schonmal damit anfangen? Oder nur weil es die ISO erst ab 1947 gab, hätte die deutsche Wirtschaft über 20 Jahre lang auf nationale Normung verzichten sollen?
Es geht um diese erste Phase, in der jede Entwicklung Vorteile bringen kann, und wenn es nur für eine kleine Gruppe ist.


Die damaligen Zeiten kannst du aber nicht mit heute vergleichen. Damals gab es noch viele Hersteller und viele unterschiedliche Technologien, wo man erst schauen musste, was überhaupt etwas taugt, also was sich durchsetzen kann.

Davon sind wir heute WEIT entfernt. Bei den von dir genannten Dingen kann man klar entscheiden, ob es sinnvoll/gut ist, oder eben nicht.


Ich zähle Glide und Direct3D. Nicht wirklich viele.
Zumal sehr bald klar war, dass sich Direct3D durchsetzen würde, da viel mehr GPU-Hersteller darauf setzten. Dennoch hätte ich 3dfx nicht missen wollen, denn dann hätte ich viele Spiele nur mit Abstrichen spielen können. Solange es da war, hatte man dadurch einen Mehrwert - und genauso denke ich auch über andere proprietäre Techniken.


Daran sind aber die Partner schuld...
Das liegt nicht am Standard an sich.


Doch, denn wenn es keine Partner gibt, können sie auch nichts versemmeln. Du kennst das Sprichwort "Viele Köche verderben den Brei"?


Ah ja, das hast jetzt du zu entscheiden.

Vor allem, was ist denn bitte Alibi-Kritik? Entweder man kritisiert oder eben nicht. Und ich sag immer wenn ich etwas schelcht finde, egal welche Firma das ist.

PS:
Was hat das eigentlich mit dem Thema hier zu tun, als dass du das hier wieder aufwärmen musst? In der Thematik ist doch alles gesagt worden oder nicht?

Das ist offensichtlich für mich, da ich deine Postinghistorie, die stark anti-NV ist, kenne. Und du hast angefangen damit, Beitrag #5 schon vergessen? Statt konkret etwas zum Thema zu sagen, kamen wieder die aufgewärmten provokativen Phrasen zu den Standards...

[Skysnake]

Klar, und weil ich alleinig son nVidia hater bin, sag icha mlaufenden band, das AMD den framepacing ansatz stecken lassen soll und lieber was vernünftiges mit nvidia zusammen ;)

Und ich hab ja auch noch gar nie mit nvidia im Bereich GPUDirect zusammen gearbeitet. Nein, wie komm ich drauf, da wäre ich ja vor lauter gehate innerlich zerbrochen....

Du kommst immer wieder mit dem Stuss, obwohl jede Firma ihr Fett bei mir weg bekommt. NVidia drängt sich in letzter Zeit nur eben ständig in den Vordergrund.

Ps:
Ich warte noch auf 10 Gegenbeispiele ;)

[Lord Wotan]

Wenn DirectX 11.2 durch die neue XBox praktisch Standard wird.

Hoffe ich das NVidia endlich das täuschen lässt und wirklich endlich Karten ausbringt die DirectX 11.1 bzw. dann 11.2 können und nicht nur 11!

[ndrs]

Leute, nutzt die PM-Funktion für eure persönlichen Kleinkriege...

[Skysnake]

Wenn DirectX 11.2 durch die neue XBox praktisch Standard wird.

Für den PC aber ziemlich sicher nicht.

Win8 wird einfach als Pest angesehen....

Eventuell setzt MS ja aber darauf, dass die Developer DX11.1/2 als Pflicht machen für Games die XboxOne ports sind.

DAS würde MS natürlich EXTREM! rein laufen. Damit würde man nämlich viele Leute zu Win8 treiben.

Dazu kommt noch die Rückkehr des Startbuttons :up:

Aber keine Ahnung, ob das ausreichen würde um die LEute massenhaft zu Win8 zu treiben. Alternativ wäre natürlich ein Patch für Win7, aber das werden Sie wohl versuchen mit allen Mitteln zu unterbinden :freak:

[ShinyMcShine]

Sorry, falls es schon gefragt wurde (kurzes "Ja" oder "Nein" genügt als Antwort :D): Werden die neuen DX 11.x Versionen auch für Windows 7 nachgereicht?

VG
Shiny

[Uran_235]

Glaube ich nicht, ich glaube dazu müsste Win 7 WDDM 1.3 unterstützen.

[Coda]

Sorry, falls es schon gefragt wurde (kurzes "Ja" oder "Nein" genügt als Antwort :D): Werden die neuen DX 11.x Versionen auch für Windows 7 nachgereicht?
Nein. Es gibt manche Features von 11.1 mit einem Platform-Update, falls die Treiber es unterstützen. Bei 11.2 wird wahrscheinlich gar nichts mehr zurückportiert.

[Ex3cut3r]

Kurze Frage, wollte mir eine GTX 770 Kaufen und wollte die so zwei Jahre behalten, habe ich damit später probs, wenn dann die Konsolen Ports kommen?

[Iruwen]

Ja sorry, mit DX11.0 Hardware wird man keine Konsolenports spielen können, die Entwickler wollen am PC nämlich kein Geld verdienen und schließen deshalb 90% der potentiellen Käufer aus :freak:

[Ex3cut3r]

Hätte ja sein können sry! ^^

[fondness]

Spielen wird man sie sicher können. Die spannende Frage ist ob man immer alle Effekte zu sehen bekommt. ;)

[Skysnake]

Bestimmt, fragt sich nur mit welcher Performance.

DX11.2 bietet ja das Potenzial auf durchgehend 60 FPS, dafür halt dynamische Auflösung.

Genau so das Overlay, da sollten sich einige Prozent Leistung einsparen lassen.

[Black-Scorpion]

Bestimmt, fragt sich nur mit welcher Performance.

DX11.2 bietet ja das Potenzial auf durchgehend 60 FPS, dafür halt dynamische Auflösung.

Genau so das Overlay, da sollten sich einige Prozent Leistung einsparen lassen.
Wie soll er mit einer GTX770 alle Effekte sehen können wenn die noch nicht mal DX11.1 beherrscht.

[aufkrawall]

Win 8 ist nicht sehr erfolgreich und die Mehrheit der Kunden wird noch lange keine Hardware haben, die 11.1 oder neuer unterstützt.
Foglich wird in den nächsten zwei Jahren vermutlich so gut wie kein Spiel so etwas nutzen, außer AMD promotet wieder irgendwas Zweifelhaftes.

Deal with it.

[gedi]

DX11.1 kam doch afair als Platformupdate auch für Win7?

[aufkrawall]

Nur ein paar Features für afair Tablets, nicht der ganze Feature Level.

[Coda]

DX11.2 bietet ja das Potenzial auf durchgehend 60 FPS, dafür halt dynamische Auflösung.
Bitte was?

Genau so das Overlay, da sollten sich einige Prozent Leistung einsparen lassen.
Einige Prozent? Für nen Alpha-Blend-Fullscreen-Pass? Was faszinierst du dir da eigentlich schon wieder zusammen?

Nur ein paar Features für afair Tablets, nicht der ganze Feature Level.
Mit Tablets hat das nichts zu tun.

[aufkrawall]

Mit Tablets hat das nichts zu tun.
Ok, aber gibts irgendein dazugekommenes Feature, das für D3D-Spiele interessant ist?

[Coda]

Kleinigkeiten.

Die Dokumentation ist da auch schlecht. Es ist selbst mir fast unmöglich rauszufinden was denn jetzt auf Windows 7 unterstützt wird und was nicht. Ich glaube nicht, dass sich viele damit rumschlagen werden.

[Locuza]

Bitte was?

In einem Build Video von MS präsentiert ein Mitarbeiter dynamische Auflösungen, die 10-20% unter der "üblichen" Auflösung liegen können, um eine gewisse Framerate garantieren zu können.

Es wird auch noch etwas neues erzählt. Es ist DX 9.1 dazugekommen?
Soweit ich verstanden habe, hat man für jedes API-Level Core-Verbesserungen erzielt.

[Coda]

Dynamische Auflösung kann ich dir auch mit DX9-Hardware machen und manche Spiele tun das auch auf den Konsolen seit einiger Zeit.

Er wurde auch behauptet, dass virtuelles Texturing nur mit Windows 8.1 möglich ist. Glatte Lüge, das geht auf AMD-Karten seit einiger Zeit mit einer OpenGL-Extension und Rage macht es sogar auf DX9-Hardware per Shader. Glaubt nicht alles was die Marketing-Fuzzies von sich geben.

[Locuza]

Mhh das ist jetzt bei mir nicht so, dass ich alles glaube was behauptet wird, auch wenn ich dank mangelndem Wissen nichts weiß, aber man fragt sich natürlich, ob die neue API Sachen nicht effizienter oder flexibler implantiert, was davor prinzipiell auch möglich war, aber praktisch wenig Sinn gemacht hat.

Hier ist z.B. das Video:
http://channel9.msdn.com/Events/Build/2013/3-062

Betrifft Mappable Default Buffers (Ab 10:45 gelistet, Vorstellung des Features ab 32:50) "APUs" oder macht das auch mit dGPUs Sinn?

[Schaffe89]

außer AMD promotet wieder irgendwas Zweifelhaftes.

Wann hat AMD das letzte mal etwas "Zweifelhaftes" bezüglich eines neuen directx beworben?
Kann mich nicht drann erinnern.

[Knuddelbearli]

er meinte vermutlich NV mit ihrem DX 11.1 API oder das rausgepatchte dx 10.1 aus Assasins Creed und hat nur AMD geschrieben da er sonst immer gegen AMD haut :biggrin:

[-/\-CruNcher-/\-]

Dynamische Auflösung kann ich dir auch mit DX9-Hardware machen und manche Spiele tun das auch auf den Konsolen seit einiger Zeit.

Er wurde auch behauptet, dass virtuelles Texturing nur mit Windows 8.1 möglich ist. Glatte Lüge, das geht auf AMD-Karten seit einiger Zeit mit einer OpenGL-Extension und Rage macht es sogar auf DX9-Hardware per Shader. Glaubt nicht alles was die Marketing-Fuzzies von sich geben.

Jep es gibt schon mehr Dynamic Resolution implementationen ich kenne bis jetzt 2 extern integrierte.

DynamiX for Skyrim (Lucidlogix)
http://www.hialgo.com/ (Farcry3 und Skyrim support bis jetzt)

Man sollte auch nicht vergessen das Dynamic Resolution aus den Intel Labs stammt ;)

[Coda]

Jep es gibt schon mehr Dynamic Resolution implementationen ich kenne bis jetzt 2 extern integrierte.

DynamiX for Skyrim (Lucidlogix)
http://www.hialgo.com/ (Farcry3 und Skyrim support bis jetzt)

Man sollte auch nicht vergessen das Dynamic Resolution aus den Intel Labs stammt ;)
"Dynamic Resolution" hat die Erfindungshöhe von einer Teppichkante. Wer sich darauf was einbildet ist sowieso nicht relevant.

[Skysnake]

Bitte was?

Funktioniert doch bei den Konsolen halbwegs vernünftig.


Einige Prozent? Für nen Alpha-Blend-Fullscreen-Pass? Was faszinierst du dir da eigentlich schon wieder zusammen?

Kommt darauf an, wie komplex das Ganze ist. Gerade die Möglichkeit eben einmalig "statische" Bildinhalte zu rendern, und dann alle paar Frames nur zu updaten ist ziemlich charmant. Rennspiele, Flugzeugsimulationen mit Cockpit usw usw usw. Könnten dadurch durchaus profitieren.

Vor allem halt in Kombination mit der dynamischen Auflösung für die beiden Streams. Gerade da macht es halt durchaus Sinn in meinen Augen.

Nehmen wir doch z.B. mal das Problem von FPS-Drops bei schnellen Drehungen. Wenn man da das HUD usw in voller Auflösung weiter rendert, und die bewegten Bildteile eben für die ~5-20 Frames auf sagen wir mal 50% der normalen Auflösung runter haut oder dergleichen, sollte man durchaus die FPS oben halten können. Das gleiche bei sichtfeldfüllenden Explosionen usw.

Ich versteh nicht, warum du da so skeptisch bist, das man nicht ein paar Prozent raus holen können sollte durch das Overlay, halt natürlich grndsätzlich schon in Kombination mit der dynamsichen Auflösung der beiden Streams.

[del_4901]

Kommt darauf an, wie komplex das Ganze ist. Gerade die Möglichkeit eben einmalig "statische" Bildinhalte zu rendern, und dann alle paar Frames nur zu updaten ist ziemlich charmant. Rennspiele, Flugzeugsimulationen mit Cockpit usw usw usw. Könnten dadurch durchaus profitieren. Das ist eigentlich nur relevant fuer UI. Cockpit oder auch die Waffe willst du so nicht updaten weil dann zum einen das Licht nicht mehr stimmt. Und zum anderen das Rendern von Foreground Objects warscheinlich billiger ist und mehr fuers early-Z culling bringt als beides getrennt zu machen.

[Coda]

Ich versteh nicht, warum du da so skeptisch bist, das man nicht ein paar Prozent raus holen können sollte durch das Overlay, halt natürlich grndsätzlich schon in Kombination mit der dynamsichen Auflösung der beiden Streams.
Weil ein Fullscreen-Alpha-Composite unfassbar billig ist auf einer modernen GPU? Wo willst du Prozente rausholen? Auf den Smartphone/Tablet-SOCs bringt das vielleicht was, aber kaum mit einer Desktop-GPU.

Und dann zahlst du die Speicherbandbreiten-Kosten ja trotzdem, allerdings wahrscheinlich im Scanout und deshalb besser verteilt.

Ich bin generell skeptisch wenn es zurück zu fixed function Hardware gehen soll. Falsche Richtung.

[Coda]

Um mal zum Thema zurückzukommen: Ich hab mir den Source von dem Tiled-Resource-Example mal angeschaut.

Es schaut so aus als wäre die einzige Restriktion auf 11.0-Hardware ("TIER_1"), dass Mip 0 immer gemappt werden muss wenn man auf das Tile zugreift.

Das heißt Fermi und Kepler unterstützen wohl schon immer virtuellen Speicher in den TMUs. Aber ich werd mir mal das Windows 8.1 Preview installieren und es ausprobieren.

[Gipsel]

TressFX darf gerne im passenden Thread diskutiert werden. Ich habe mal ein paar Posts rübergeschoben. Das absolut kleinkindhafte Gezanke dagegen dürft ihr gerne in irgendeinem Kindergarten fortsetzen, aber nicht hier und schon gar nicht in einem Technologiethread. Beim nächsten Mal hat das Konsequenzen für alle Beteiligten.

[Skysnake]

Jetzt wird es GANZ kurios :ugly:

Darüber hinaus können die Nvidia-Karten nun auch mit dem neuen DirectX 11.2 umgehen, allerdings wie auch schon bei DirectX 11.1 nur mit dem „Feature_Level 11.0“ – die Hardware bleibt natürlich auf dem Stand von DirectX 11.0. Was genau bei DirectX 11.2 angepasste Hardware benötigt und was auch auf DirectX-11-GPU funktioniert, ist immer noch unklar – bis jetzt konnten wir keine Aussagen diesbezüglich einfangen. Derzeit macht es den Anschein, als wäre die Situation ähnlich wie mit DirectX 11.1 – manches geht per Software, anderes benötigt dagegen passende Hardware. Dabei ist wahrscheinlich aber DirectX-11.1-Hardware ausreichend.
http://www.computerbase.de/news/2013-07/nvidia-bringt-win-8.1-treiber-geforce-326.01/

Das ist jetzt nicht wirklich ihr Ernst oder? Damit wird sich wahrscheinlich wieder kaum einer darum scheren, ob man jetzt die FEatures einsetzt, oder aber nicht, wobei man schauen muss, wie geradlienig sich das von der XboxOne auf den PC portieren lässt. Da gibt es noch einen Hoffnungsschimmer, dass das doch in mehr als 1-2 Games eingesetzt wird.

Ich fühl mich allerdings ganz ehrlich gesagt so langsam ziemlich verarscht.

[Godmode]

Hast du was anderes erwartet? Volle Unterstützung wird es frühestens mit der nächsten Generation geben. Das gesamte Kepler Lineup ist schließlich auf dem Markt.

[Schaffe89]

Nvidia windet sich da wie ein Aal, ich versteh das nicht, erst lügen sie, sie würden directx11.1 unterstützen und nun unterstützt quasi auch Fermi Directx11.2 mit Featurelevel 11.0, dann unterstützt auch meine Radeon 1950 XTX Directx11.2 mit Featurelevel 9.0c, ich versteh nicht warum AMD das nicht mehr in ihre Werbung einbaut, bzw so ein Käse ( directx11.1 auf die Verpackungen zu schreiben) zuzulassen.

Nach dem Motto kann ich auch bei meiner Radeon HD 7870 dann in 2 Jahren Directx11.4 draufschreiben, weil es ja unterstützt wird, aber halt mit Featurelevel 11.2.

[Skysnake]

Hast du was anderes erwartet? Volle Unterstützung wird es frühestens mit der nächsten Generation geben. Das gesamte Kepler Lineup ist schließlich auf dem Markt.
Naja, die Demo soll ja anscheinend auf einer nVidia gelaufen sein. Wie soll das aber bitte gehen, wenn Sie nur Tech_lvl 11.0 unterstützt? :freak:

Kann ich die DX11.2 Funktionen jetzt mit ner nVidia nutzen oder nicht????

Da blickt doch keine Sau mehr durch.

PS:
Wenn man die DX11.2 Funktionen nicht nutzen kann, dann stellt sich natürlich die Frage, wie die Demo bei MS lief? Ich weiß, das hört sich jetzt nach Verschwörungstheorie an, und ich finde es eigentlich auch lächerlich, aber inzwischen muss man ja alles in Frage stellen. Hat jemand eigentlich gesehen, dass in dem Rechner, von dem das Bild kam auch wirklich ne nVidia drin gesteckt hat? :ugly:

[Undertaker]

Welche Demo?

Ansonsten dürfte es doch auch sicherlich so sein, dass man nicht in Hardware unterstützte 11.2-Features wohl auch irgendwie per 11.0 umsetzen kann?

[Skysnake]

Na die Mars und Flugzeug Demo auf der Presentation von MS. http://www.pcgameshardware.de/DirectX-11-Software-233669/News/DirectX-112-Mega-Texturing-1076406/

Da steht ja ein Rechner mit nVidia Logo, und nVidia hat ja auch ein Treiberupdate für Win8.1 rausgebracht. Irgendwie scheint nur niemandem klar zu sein, was denn nun wirklich Sache ist.

Aufgrund des "nVidia"-Rechners in der Presentation sind die Leute ja davon ausgegangen, dass DX11.2 eben auch auf den nVidia Karten läuft. Dazu ja auch noch die Aussage von nVidia das man x Millionen Karten hätten, die das unterstützen bla blub.

Wenn das aber wieder wie bei DX11.1 läuft, dann kannst das eigentlich in die Tonne treten.

[Schaffe89]

Nvidia beschwichtigt doch bewusst und trifft keine klaren Aussagen, das übliche Verhalten wie bei directx11.1,gehört eigentlich abgestraft.

[Iruwen]

Durch wen, interessiert doch keinen, offenbar nichtmal die meisten Entwickler bei dem Chaos :D

[Skysnake]

Verbraucherzentrale?

[Undertaker]

Na die Mars und Flugzeug Demo auf der Presentation von MS. http://www.pcgameshardware.de/DirectX-11-Software-233669/News/DirectX-112-Mega-Texturing-1076406/

Da steht ja ein Rechner mit nVidia Logo, und nVidia hat ja auch ein Treiberupdate für Win8.1 rausgebracht. Irgendwie scheint nur niemandem klar zu sein, was denn nun wirklich Sache ist.

Aufgrund des "nVidia"-Rechners in der Presentation sind die Leute ja davon ausgegangen, dass DX11.2 eben auch auf den nVidia Karten läuft. Dazu ja auch noch die Aussage von nVidia das man x Millionen Karten hätten, die das unterstützen bla blub.

Wenn das aber wieder wie bei DX11.1 läuft, dann kannst das eigentlich in die Tonne treten.

Also ich sehe da keine Unklarheiten? :confused:

DX11.2 wird nicht vollständig in Hardware unterstützt, Punkt. Einzelne Funktionen - das kennt man aus der Vergangenheit - dagegen schon. Die PCGH spricht z.B. von Tiled Ressources, was auf anderem Wege offensichtlich auch ohne DX11.2 möglich ist.

[Locuza]

Kann jemand genau aufklären wie das bei DX abläuft?
Z.B. kann Nvidia ja die DX11.2 API unterstützen, nur halt auf dem Feature-Level 11_0.
Das Feature Level 11_0 hat ja zusätzliche Funktionen gegenüber dem originalen DX11 bekommen.
War das nicht ebenso mit den DX10 Karten?
DX11 API Unterstützung mit Feature Level 10_0/1, wo Compute-Shader dazu gekommen sind?
Es gibt ja jetzt auch ein neues DX9_1 Feature Level.
Damit würden ja wirklich einige ältere Karten die neue API unterstützen, ohne dabei über Hardwarefähigkeiten hinaus zu gehen, die definitiv gebraucht werden für Feature X.

[Coda]

Jetzt wird es GANZ kurios :ugly:


http://www.computerbase.de/news/2013-07/nvidia-bringt-win-8.1-treiber-geforce-326.01/

Das ist jetzt nicht wirklich ihr Ernst oder? Damit wird sich wahrscheinlich wieder kaum einer darum scheren, ob man jetzt die FEatures einsetzt, oder aber nicht, wobei man schauen muss, wie geradlienig sich das von der XboxOne auf den PC portieren lässt. Da gibt es noch einen Hoffnungsschimmer, dass das doch in mehr als 1-2 Games eingesetzt wird.

Ich fühl mich allerdings ganz ehrlich gesagt so langsam ziemlich verarscht.
Was ist daran "kurios" dass 11.0-Hardware eine zukünftige 11.2-Spec nicht vollständig unterstützt?

Es gibt eine 11.2 API und unabhängig davon gibt es Feature-Levels. 11.2 bringt nun eine API um tiled resources zu benutzen und diese hat je nach Feature-Level unterschiedliche Eigenschaften. Und zwar dass manche Hardware die Tiles immer gemappt haben muss wenn man darauf zugreift (TIER_1). Das hab ich schonmal geschrieben.

Aufgrund des "nVidia"-Rechners in der Presentation sind die Leute ja davon ausgegangen, dass DX11.2 eben auch auf den nVidia Karten läuft. Dazu ja auch noch die Aussage von nVidia das man x Millionen Karten hätten, die das unterstützen bla blub.
Tiled Resources werden per Feature-Cap unterstützt. http://msdn.microsoft.com/en-us/library/windows/desktop/dn280435(v=vs.85).aspx

Microsoft ist teilweise wieder davon weg eine strikte Verbindung von API- und Feature-Level zu erzwingen. Und ja, das gilt auch für D3D 11.1. Das wird teilweise auf Windows 7 unterstützt und noch mehr teilweise mit 11.0-Hardware auf Windows 8.

Es gibt ja jetzt auch ein neues DX9_1 Feature Level.
Nein. Das gab es schon immer. Genauso 9_2 und 9_3. Das hat auch nichts mit "DX9.1" zu tun.

Es ist nur hinzugekommen, dass 9_1-Hardware auch ein Schatten-Feature unterstützen kann per Feature-Cap.

[Nightspider]

Wenn sich dadurch optisch die Texturen verbessern, kann man nur hoffen, dass das die neuen Konsolen schon per Hardware nutzen.
AMD Grafikkarten können das ja und zur Not kann man das am PC ja per Software machen lassen, auch wenn das dann etwas langsamer läuft.

Hauptsache die Konsolen nutzen ihr komplettes Featureset.

Übrigens Danke Coda für deine PN-Antwort!

[Skysnake]

Ok Coda, du hast dich damit ja scheinbar schon genauer beschäftigt, und ich hab keine gescheite Doku dazu gefunden.

WAS bringt mir denn jetzt eigentlich der Support von DX11.2 API, wenn der Feature level nur 11.0 ist?

Kann ich die DX11.2 API-Funktionen jetzt nutzen oder nicht? Und wenn ja, wie groß sind denn die Einschänkungen denn jetzt am Ende?

Wenn es sich "nur" auf die MipMap Stufe 0, die immer geladen werden muss beschränkt, dann ok, aber was bedeutet das für die Performance? Wird der Rest dann rein über Software im Treiber geregelt, und stinkt dann gegen eine "reine" Hardwarelösung ab, oder ist es im Prinzip Jacke wie Hose?

Für mich ist das völlig undurchsichtig, was das am Ende alles bedeutet für die Entwickler, und am Ende auch für die Kunden.

[Grestorn]

Naja, die Demo soll ja anscheinend auf einer nVidia gelaufen sein. Wie soll das aber bitte gehen, wenn Sie nur Tech_lvl 11.0 unterstützt? :freak:

Kann ich die DX11.2 Funktionen jetzt mit ner nVidia nutzen oder nicht????

Es ist doch schon immer ganz einfach:

Unter 11.0 gibt es optionale Features. Die Features sind erst unter 11.1 und weitere unter 11.2 Pflicht. Man kann sie aber auch unter 11.0 unterstützen.

nVidia hat nicht das gesamte Featureset für 11.1, deswegen können sie sich nicht voll 11.1 kompliant bezeichnen. Aber die "Spielerelevanten" Features unterstützen sie, eben halt als zusätzliche, optionale Features unter 11.0.

Genau das ist es, was "auf Featurelevel" aussagt.

Die in 11.2 hinzugekommen Features unterstützen sie komplett, eben auch als optionale 11.0 Features. Sie dürfen sich aber - wegen des unvollständigen 11.1 Featuresatzes - trotzdem nicht 11.2 compliant nennen.

Für den Spieler ist das alles irrelevant. Es wird kein Spiel geben, dass ein 11.1 oder 11.2 Feature unterstützt und auf nVidia Hardware nicht ohne Einschränkungen funktioniert. Das wolltest Du aber schon damals bei der Diskussion nie wahrhaben,

[fondness]

Aber die "Spielerelevanten" Features unterstützen sie, eben halt als zusätzliche, optionale Features unter 11.0.


NV unterstützt keine UAVs in anderen Shadern als Pixel. Das ist das einzige wirklich wichtige Feature von 11.1, durchaus auch für Spiele. Also bitte nicht immer das NV-Marketing nachplappern.

[Skysnake]

/sign

Die Sache, die ich jetzt aber nicht verstanden habe. Sie Supporten DX11.2, aber nur mit Featurelevel 11.0. Soweit klar, kann ich jetzt aber die DX11.2 Api-Calls verwenden JA oder NEIN, das hat mir noch keiner sagen können. Apriori ist es ja erstmal scheis egal, wie die das dann am Ende lösen, hauptsache man kann die API-Calls überhaupt verwenden.

Was bleibt denn am Ende noch von 11.2 übrig? Die Einschränkung mit MipMap0 hatten wir ja schon, aber wie siehts sonst aus?

Ich hätte einfach mal gern eine Übersicht, was denn jetzt geht, und was nicht, bzw was mit welchen Einschärnkungen. So etwas scheint es aber von/für nVidia aber nicht zu geben. Zumindest finde ich nichts dazu.

[Grestorn]

NV unterstützt keine UAVs in anderen Shadern als Pixel. Das ist das einzige wirklich wichtige Feature von 11.1, durchaus auch für Spiele. Also bitte nicht immer das NV-Marketing nachplappern.

Ich kann nicht beurteilen wie relevant UAV für nicht Pixel-Shader ist. Ich wollte nur erklären wieso es sein kann, dass man nicht 11.1 und 11.2 compliant ist und dennoch einen großteil der 11.1 und 11.2 Features unterstützt.

Deswegen habe ich das "Spielerelevant" ja auch in Anführungszeichen gesetzt.

[Grestorn]

/sign

Die Sache, die ich jetzt aber nicht verstanden habe. Sie Supporten DX11.2, aber nur mit Featurelevel 11.0. Soweit klar, kann ich jetzt aber die DX11.2 Api-Calls verwenden JA oder NEIN, das hat mir noch keiner sagen können. Apriori ist es ja erstmal scheis egal, wie die das dann am Ende lösen, hauptsache man kann die API-Calls überhaupt verwenden.

DirectX-11.1-Funktionen von Kepler-GPUs

Unterstützt
Partial constant buffer updates
Logic operations in the Output Merger
16bpp rendering
UAV-only rendering
Partial clears
Large constant buffers

nicht unterstützt
Target-Independent Rasterization (2D-Rendering)
16xMSAA Rasterization (2D-Rendering)
Orthogonal Line Rendering Mode
UAV in non-pixel-shader stages


Ja, und das bedeutet auch, dass die dafür notwendigen API Calls auf nVidia funktionieren.

Quelle: http://extreme.pcgameshardware.de/nvidia-themenabend-04-2013/270065-dx11-1-bei-nvidia.html

Und so wie ich das verstanden habe, werden ALLE neuen 11.2 Features unterstützt.

[Skysnake]

Das mit DX11.1 meinte ich nicht, das ist ja hinlänglich bekannt, und da ist ja das Problem, das eben NICHT alle "must have" DX11.1 Features unterstützt werden. Damit meldet sich die Hardware, meines Verständnisses ja nach auch nur als DX11.0 Hardware. Der Softwareentwickler wird also nur DX11.0 Features verwenden, so lange er nicht jedes Feature einzeln abfrägt, bzw eben die verwendete Karte manuell erkennt und dementsprechend dann Branches setzt, was wohl kaum einer machen wird.

@Topic:
Und Computerbase schreibt das Gegenteil...

Ich sag doch, da blickt aktuell doch keine Sau mehr durch, was denn jetzt Sache ist.

Ist es denn SOOOO schwer ne Liste zu machen, was geht und was nicht geht, und ob sich die Karte jetzt mit 11.2 meldet, oder eben nicht, und ob man jetzt einfach nur prüfen muss ob 11.2 unterstützt wird, und dann eben alle "must have" Features verwenden kann. Das es optionale Sachen gibt ist ja nicht neu bei DX-Versionen. Damit kann man umgehen.

EDIT:
Was halt besonders "seltsam" für mich ist, ist folgendes:
http://msdn.microsoft.com/en-us/library/dn312084


HRESULT hr = D3D11CreateDevice(
nullptr, // Specify nullptr to use the default adapter.
D3D_DRIVER_TYPE_HARDWARE, // Create a device using the hardware graphics driver.
0, // Should be 0 unless the driver is D3D_DRIVER_TYPE_SOFTWARE.
creationFlags, // Set debug and Direct2D compatibility flags.
featureLevels, // List of feature levels this app can support.
ARRAYSIZE(featureLevels), // Size of the list above.
D3D11_SDK_VERSION, // Always set this to D3D11_SDK_VERSION for Windows Store apps.
&device, // Returns the Direct3D device created.
&m_d3dFeatureLevel, // Returns feature level of device created.
&context // Returns the device immediate context.
);

if (SUCCEEDED(hr))
{
D3D11_FEATURE_DATA_D3D11_OPTIONS1 featureData;
DX::ThrowIfFailed(
device->CheckFeatureSupport(D3D11_FEATURE_D3D11_OPTIONS1, &featureData, sizeof(featureData))
);

m_tiledResourcesTier = featureData.TiledResourcesTier;
}


Da wird eigentlich erst mal nur gechecked welches Feature level die Hardware hat, und das scheint dann ja eben nur 11.0 zu sein. Alles andere muss sich dann der Entwickler einzeln abfragen über den FeatureSupport. Mit DX habe ich selbst leider noch nicht gearbeitet, daher kann ich das nicht mit 100% Gewissheit sagen, aber so sieht das zumindest für mich aus.

Das steigert natürlich den Aufwand beträchtlich für die Entwickler. Man wird ja nicht alles mögliche Implementieren an Kombinationsmöglichkeiten. Vieles macht ja nur zusammen Sinn.

[Coda]

In OpenGL hast du doch auch tausend Extensions, das ist wesentlich schlimmer. Du suchst hier doch nur fadenscheinige Argumente.

Ja, die tiled resources API funktioniert auf NVIDIA-GPUs mit der DX11.2 API und Featurelevel 11.0, weil du per CheckFeatureSupport abfragen kannst ob TIER_1 unterstützt wird. Falls das so ist, kannst du es benutzen musst nur aufpassen, dass immer alles gemappt ist. Das ist natürlich ein geradezu grotesk riesiger Aufwand, wenn du sowieso schon den ganzen Streaming-Support schreiben musst.

Viel schlimmer ist, dass das ganze nur unter Windows 8.1 unterstüzt wird. DAS macht es quasi nutzlos.

[AnarchX]

Hätte eine Windows 7 Unterstützung über die NVAPI größere Nachteile? So etwas hat NV ja immerhin schon einmal angekündigt (letzter Stichpunkt (https://developer.nvidia.com/content/geforce-gtx-680-developers-perspective)).

[Skysnake]

In OpenGL hast du doch auch tausend Extensions, das ist wesentlich schlimmer. Du suchst hier doch nur fadenscheinige Argumente.

Und was wird an OpenGL kritisiert?

Man muss ja nicht jeden Dumfug mit machen, wenn man schon so ne Schnittstelle wie DX nutzt.


Ja, die tiled resources API funktioniert auf NVIDIA-GPUs mit der DX11.2 API und Featurelevel 11.0, weil du per CheckFeatureSupport abfragen kannst ob TIER_1 unterstützt wird.

Und wieviele TIERs gibt es? Und worin unterscheiden die sich? Gibts dazu ne Doku?


Falls das so ist, kannst du es benutzen musst nur aufpassen, dass immer alles gemappt ist. Das ist natürlich ein geradezu grotesk riesiger Aufwand, wenn du sowieso schon den ganzen Streaming-Support schreiben musst.

Das was alles gemapped ist?

Und wo bleibt dann am Ende der Nutzen? bzw. was genau verhindert deiner Meinung nach den sinnvollen Einsatz?

Könnte man die Einschränkung durch "kleinere" level nicht eventuell kompensieren? So das man halt die entsprechenden "must have" daten alle am Anfang lädt und gut ist? Würde natürlich den "freien" RARM stark einschränken, aber man hat ja genug. Die 16 MB Mars Demo war ja schon durchaus beeindruckend.


Viel schlimmer ist, dass das ganze nur unter Windows 8.1 unterstüzt wird. DAS macht es quasi nutzlos.
Ja, das ist grütze, wird man aber wohl nicht ändern können, wobei halt hier die Frage ist, was passiert, wenn X AAA Titel es eben einsetzen. Dann wird viele wohl das "Geschwätz" von Gestern kaum noch interessieren, und man steigt halt doch auf Win8(.1) um. Selbst DRM hat die Leute ja nicht abgehalten Spiele zu kaufen, wenn es Sie halt nur mit gab. Da ist Win8 ja schon fast eine Klacks dagegen.

[Coda]

Und wieviele TIERs gibt es? Und worin unterscheiden die sich? Gibts dazu ne Doku?
Nein, das habe ich aber auch schon angekreidet. Ist halt ein Preview.

Die Dokumentation ist im Moment die API selbst und das eine Code-Example.

Das was alles gemapped ist?
Die Tiles in einer Textur. Kannst du aber alle auf die gleiche physikalische Page zeigen lassen. Das Zeug funktioniert so wie es soll ansonsten.

Das gezeigte Flugzeug/Terrain-Demo mit ~60GB Texturen läuft anscheinend auch auf NVIDIA-GPUs.

[del_4901]

Falls das so ist, kannst du es benutzen musst nur aufpassen, dass immer alles gemappt ist. Das ist natürlich ein geradezu grotesk riesiger Aufwand, wenn du sowieso schon den ganzen Streaming-Support schreiben musst.Man braucht halt kein Padding mehr, das ist schon ein bischen angenehmer. Und die ganzen Texturfilter funktionieren auch. Automatisches Streaming (mit Pagefaults) will man eh nicht haben. Und Die halbautomatische Variante kann man emulieren indem man eine Dummy Page mappt.

[Coda]

Du hast mich falsch verstanden.

Es ging um die Relation mal kurz ein Caps-Flag zu checken gegenüber dem restlichen Code-Aufwand den man da treiben muss um es zu unterstützen.

Und Die halbautomatische Variante kann man emulieren indem man eine Dummy Page mappt.
Genau.

Echt erstaunlich, dass NVIDIA das nie in OpenGL exposed hat.

[del_4901]

Du hast mich falsch verstanden.
Es ging um die Relation mal kurz ein Caps-Flag zu checken gegenüber dem restlichen Code-Aufwand den man da treiben muss um es zu unterstützen.
Den Streamer braucht man untendrunter doch trotzdem noch. Allein mit dem Caps Flag ist es doch nicht getan.

[Coda]

Sei nich so schwer von Begriff. Er tut so als wäre es wahnsinnig viel Aufwand auch TIER_1-Hardware zu supporten, weil man dafür ein Feature-Cap abfragen muss!

Das ist aber lächerlicher Aufwand gegenüber dem sonstigen Code den man in das Feature stecken muss.

[Skysnake]

Echt erstaunlich, dass NVIDIA das nie in OpenGL exposed hat.
War vorher nicht nen link da, wo auf ne OpenGL-Extrension bezug genommen wird?

@Streaming:
Wenn alle relevanten Daten im RAM liegen, sollte es doch nicht weh tun, wenn man der Hardware das Nachladen überlässt. Es dürfen halt nur nicht zu viele misses innerhalb eines Frames passieren.

Mit heuristiken bzw. "Checkpoint" Systemen sollte man doch aber recht gute Vorhersagen treffen können, was denn überhaupt alles relevant sein kann.

z.B. Wenn ich ein Gebäude betrete kann ich schon kurz vorher anfangen die Sachen in den RAM zu laden, gleiches beim Verlassen.

Oder eben auf Level-Grenzen beziehen.

Eigentlich sollten die niedrigsten MipMaps völlig ausreichend sein oder? Zumindest deutet die Mars-Demo das an.

Klar, ein Miss tut weh, und verlangsamt das Rendering, aber so lange es nicht zu viele werden kann es einem doch mehr oder weniger egal sein. Die Hardware sollte doch durchaus in der Lage sein, bei einem Miss etwas anders so lange zu tun, bis die Daten da sind.

[del_4901]

Sei nich so schwer von Begriff. Er tut so als wäre es wahnsinnig viel Aufwand auch TIER_1-Hardware zu supporten, weil man dafür ein Feature-Cap abfragen muss!

Das ist aber lächerlicher Aufwand gegenüber dem sonstigen Code den man in das Feature stecken muss.
Haha, jetzt liest sich der Abschnitt mehr nach Ironie, ja ich brauch manchmal ein bissel laenger. Du bist sonst so ernst, da komme ich schnell durcheinander.

[del_4901]

@Streaming:
Wenn alle relevanten Daten im RAM liegen, sollte es doch nicht weh tun, wenn man der Hardware das Nachladen überlässt. Es dürfen halt nur nicht zu viele misses innerhalb eines Frames passieren.
...
Klar, ein Miss tut weh, und verlangsamt das Rendering, aber so lange es nicht zu viele werden kann es einem doch mehr oder weniger egal sein. Die Hardware sollte doch durchaus in der Lage sein, bei einem Miss etwas anders so lange zu tun, bis die Daten da sind.

Das will man nicht haben!


Mit heuristiken bzw. "Checkpoint" Systemen sollte man doch aber recht gute Vorhersagen treffen können, was denn überhaupt alles relevant sein kann.

z.B. Wenn ich ein Gebäude betrete kann ich schon kurz vorher anfangen die Sachen in den RAM zu laden, gleiches beim Verlassen.

Oder eben auf Level-Grenzen beziehen.

Viel zu komplexes System, da kann zuviel schief gehen. On Demand ist schon richtig, abr eben mit ein paar Frames Verzoegerung.

[Iruwen]

Da wird eigentlich erst mal nur gechecked welches Feature level die Hardware hat, und das scheint dann ja eben nur 11.0 zu sein. Alles andere muss sich dann der Entwickler einzeln abfragen über den FeatureSupport. Mit DX habe ich selbst leider noch nicht gearbeitet, daher kann ich das nicht mit 100% Gewissheit sagen, aber so sieht das zumindest für mich aus.

Das steigert natürlich den Aufwand beträchtlich für die Entwickler. Man wird ja nicht alles mögliche Implementieren an Kombinationsmöglichkeiten. Vieles macht ja nur zusammen Sinn.

Ist gerade deine einzige Sorge dass man jedes Feature abfragen muss statt dass man eine Liste der unterstützten Features zurückbekommt (funktioniert das bei CPU Features so)? Das ist doch ein Copy & Paste Job und viele Features sind das offensichtlich auch nicht im Vergleich zu anderen APIs. Man kann sich auch krampfhaft Probleme suchen.

[Skysnake]

Warum sollte man das nicht haben wollen?

Wenn ich mir irgend ein x beliebiges Spiel anschaue, und sagen wir mal 60GB an Texturen da drin stecken habe, dann kann ich mir kaum ein Spiel vorstellen, wo ich nicht auf vernünftige Art und Weise in der Gestalt Grenzen ein ziehen kann, das man nicht mehr als ~6-10 GB an Texturdaten gleichzeitig braucht. Allein die level in den meisten Spielen helfen mir da ja schon.

So lange man nur einige wenige MB wirklich nachladen muss zwischen zwei Frames, sollte man noch mehr als genug Zeit übrig haben, um das Bild zu renden. Wenn man sich wirklich die Unterschiede zwischen einzelnen Frames anschaut, dann sind die ja meist nicht wirklich groß, was die Texturen angeht. Was kritisch sind, sind Rauch/Wolken/Feuer/Explosionen usw. Aber dafür kann man ja z.B. 64-512MB einfach mal abstellen.

Die Frage ist halt, und das kann nur jemand beantworten, der das auch real einsetzt:
Wie groß sind denn wirklich die Textursets, die man so in einem Fenster von 100-200 Frames braucht? Und wie groß sind die Texturmengen, die man nachladen müsste, wenn man sagen wir mal 512MBstatisch für Texturen haben, die man oft/schnell brauch, und nochmals min 512 MB für dynamische Sachen. Ist da abgesehen von irgendwelchen WorstCase Situationen, wie der Blick durch ein Fernglas, wirklich so große Texturmengen vorhanden, die von einem Frame zum nächsten zu laden wären?

Ich seh das halt unter der Prämisse, das man GPUs mit min 1GB RAM, eher sogar 2, und CPUs mit min 8GB RAM als gegeben ansehen kann für die maximale Texturqualität. Dazu min PCI-E 2.0 16x

Ist gerade deine einzige Sorge dass man jedes Feature abfragen muss statt dass man eine Liste der unterstützten Features zurückbekommt (funktioniert das bei CPU Features so)? Das ist doch ein Copy & Paste Job und viele Features sind das offensichtlich auch nicht im Vergleich zu anderen APIs. Man kann sich auch krampfhaft Probleme suchen.
Nein die Sorge ist darin begründet, das ich nie weiß, was ich denn als "Minimum" erwarten kann. Das ist ja der Knackpunkt. Manche Sachen machen ja nur in der Kombination wirklich richtig Sinn, bzw schon ein einzelnes fehlendes Feature kann mich ja soweit beschränken, das eine Idee ohne dieses halt nicht funktioniert. Was mache ich dann? Gleich drausen lassen, oder dennoch implementieren und sagen "deal with it".

Ich erwarte da eher, das man es halt einfach gar nicht nutzt, weil man dann ja noch den Fallback braucht. Gibt Features, bei denen ist das sicherlich nicht schlimm, aber eben auch andere, die dir das Genick brechen.
Das Problem ist ja, wenn es aktuell einfach keiner weiß, was wo wie Sache ist, dann wird wohl damit auch noch nicht gearbeitet, sprich, bis das dann mal in Games ankommt ist schon die nächste/übernächste GPU-Gen da...

[Iruwen]

Nein die Sorge ist darin begründet, das ich nie weiß, was ich denn als "Minimum" erwarten kann.

http://img853.imageshack.us/img853/2880/dfv2.png

Weißt du damit doch.

[aufkrawall]

Das Problem ist ja, wenn es aktuell einfach keiner weiß, was wo wie Sache ist, dann wird wohl damit auch noch nicht gearbeitet, sprich, bis das dann mal in Games ankommt ist schon die nächste/übernächste GPU-Gen da...
Wie ich schon ein paar Seiten zurück schrieb, ist das sowieso der Fall.
Wär Microsoft nicht so ein zurückgebliebener Verein, könntest du ja gerne objektiv NV die Schuld in die Schuhe schieben, aber so... ;)

Edit: Bezogen auf die Marktsituation mit Windows 8/8.1.

[Iruwen]

Wenn Coda schon mangels Doku nicht durchblickt ist das sicherlich ein größeres Problem.

[Coda]

Haha, jetzt liest sich der Abschnitt mehr nach Ironie, ja ich brauch manchmal ein bissel laenger. Du bist sonst so ernst, da komme ich schnell durcheinander.
Ich muss Ironie-Tags benutzen ;)

Warum sollte man das nicht haben wollen?
Viel zu teuer während des Renderings Page-Faults zu behandeln.

[Kriton]

Ist gerade deine einzige Sorge dass man jedes Feature abfragen muss statt dass man eine Liste der unterstützten Features zurückbekommt (funktioniert das bei CPU Features so)? Das ist doch ein Copy & Paste Job und viele Features sind das offensichtlich auch nicht im Vergleich zu anderen APIs. Man kann sich auch krampfhaft Probleme suchen.

Na ja, das mag aus Entwicklersicht irrelevant sein (kann ich nicht beurteilen) - aber ich finde es schon erstaunlich, dass man die mangelnde 11.2-Unterstützung Nvidia nicht stärker ankreidet. Gefühlt würde dies hier anders aussehen wenn das ein ATI-Thema wäre :rolleyes:
Wenn man mal davon ausgeht, dass 11.2 respektive 11.1 sinnvolle Änderungen hat, dann tut Nvidia uns keinen Gefallen damit es nicht anzubieten, denn natürlich werden sich genug Entwickler auf den kleinsten gemeinsamen Nenner einigen.
Die Frage die man also IMHO stellen muss um zu entscheiden ob man mit dem Finger auf Nvidia zeigt ist: Ist DX 11.1 respektive 11.2 bei den Teilen welche entsprechende HW benötigt sinnvoll und gut oder nicht?

Wie ich schon ein paar Seiten zurück schrieb, ist das sowieso der Fall.
Wär Microsoft nicht so ein zurückgebliebener Verein, könntest du ja gerne objektiv NV die Schuld in die Schuhe schieben, aber so... ;)

Edit: Bezogen auf die Marktsituation mit Windows 8/8.1.

Oh bitte, Win 8 ist nun wirklich nicht der Untergang des Abendlandes. Meine Schwiegermutter kann damit umgehen nachdem ich das System extra eingerichtet (keine 3rd-Party-SW) und sie 10 Minuten eingewiesen habe.

[Skysnake]

Viel zu teuer während des Renderings Page-Faults zu behandeln.
Generell, oder ab welcher Anzahl an Page-Faults?

Wieviele wären denn ca "normal", nur um einen Vergleich zu haben.

Und bezieht sich die Aussage nur auf den aktuellen tech Stand, oder generell?

Ich denke da gerade eben auch an GCN (2.0?) wo, wenn ich mich recht erinnere hardware preemption Einzug halten soll. Damit sollte die Auswirkung eines Page-Faults nochmals reduziert werden oder nicht? Kenne mich hier leider VIEL zu wenige in der DX Pipeline, und wie das auf die GPUs gemapped wird aus, um da auch nur irgendwas dazu sagen zu können.

[aufkrawall]

Oh bitte, Win 8 ist nun wirklich nicht der Untergang des Abendlandes. Meine Schwiegermutter kann damit umgehen nachdem ich das System extra eingerichtet (keine 3rd-Party-SW) und sie 10 Minuten eingewiesen habe.
Mag so sein oder auch nicht, hab es nie benutzt.
Davon sprach ich auch gar nicht, sondern von der Marktsituation:
http://thenextweb.com/insider/2013/07/01/windows-8-now-up-to-5-10-market-share-as-it-finally-passes-windows-vista/

Welchen Marktanteil wird Win 8.1 in zwölf Monaten haben?
Keinen signifikanten.
Viele Leute wollen gar nicht auf 8 aufrüsten, weil sie mit 7 völlig zufrieden sind.
Neue DX-Features für nicht existierende Spiele ändern das auch nicht.

[del_4901]

Generell, oder ab welcher Anzahl an Page-Faults?Generell!

Wieviele wären denn ca "normal", nur um einen Vergleich zu haben. 0

Und bezieht sich die Aussage nur auf den aktuellen tech Stand, oder generell? Generell will man kein unvorhersehbares Laufzeitverhalten haben.

Ich denke da gerade eben auch an GCN (2.0?) wo, wenn ich mich recht erinnere hardware preemption Einzug halten soll. Damit sollte die Auswirkung eines Page-Faults nochmals reduziert werden oder nicht? Kenne mich hier leider VIEL zu wenige in der DX Pipeline, und wie das auf die GPUs gemapped wird aus, um da auch nur irgendwas dazu sagen zu können.Das ist alles nur fuer den Debugger.

[Kriton]

Mag so sein oder auch nicht, hab es nie benutzt.
Davon sprach ich auch gar nicht, sondern von der Marktsituation:
http://thenextweb.com/insider/2013/07/01/windows-8-now-up-to-5-10-market-share-as-it-finally-passes-windows-vista/

Welchen Marktanteil wird Win 8.1 in zwölf Monaten haben?
Keinen signifikanten.
Viele Leute wollen gar nicht auf 8 aufrüsten, weil sie mit 7 völlig zufrieden sind.
Neue DX-Features für nicht existierende Spiele ändern das auch nicht.

Immerhin schon mal mehr als Vista :biggrin:

http://www.computerbase.de/news/2013-07/windows-8-ueberholt-vista-bei-weltweiter-nutzung/

Übrigens bin ich seinerzeit (u.a. - 64 Bit war auch ein Thema hinsichtlich der Treiber) wegen DX 10 auf Vista umgestiegen.

[fondness]

Mag so sein oder auch nicht, hab es nie benutzt.
Davon sprach ich auch gar nicht, sondern von der Marktsituation:
http://thenextweb.com/insider/2013/07/01/windows-8-now-up-to-5-10-market-share-as-it-finally-passes-windows-vista/

Welchen Marktanteil wird Win 8.1 in zwölf Monaten haben?
Keinen signifikanten.
Viele Leute wollen gar nicht auf 8 aufrüsten, weil sie mit 7 völlig zufrieden sind.
Neue DX-Features für nicht existierende Spiele ändern das auch nicht.

Win8 kommt bei Steam jetzt schon auf fast 15% Marktanteil. Tendenz deutlich steigend. Win8.1 wird ein Gratisupdate für Win8 und demzufolge von 99% der Win8-User auch installiert werden. Zudem kann das dem Marktanteil noch mal einen deutlichen Schub geben. In einem Jahr sollte man durchaus bei deutlich über 30% stehen und damit wohl ca. gleichauf mit Win7. Der weltweite Marktanteil spielt keine Rolle, kaum ein Spieler verwendet noch WinXP, das sind irgend welche Office-Rechner. Spieler sind da deutlich schneller am umrüsten.

[aufkrawall]

Win 7 war nach einem Jahr erfolgreicher:
http://www.zdnet.com/blog/hardware/steam-hardwaresoftware-survey-july-2010/9427

Außerdem kam SP1 für 7 später als jetzt Blue für 8 und auf Windows 8 upgraden Leute von drei verschiedenen Vorgänger-OS.
Außerdem gabs für Vista DX11. Kurz: Abwarten, ich glaube du irrst dich.

[Skysnake]

Generell!

0

Generell will man kein unvorhersehbares Laufzeitverhalten haben.

Und warum implementiert man es überhaupt, wenn es eh inakzeptabel ist? :rolleyes:

Für mich sah weder die Mars noch die Flugzeugdemo wirklich inakzeptabel aus, und genau dabei sollte es ja zu Pagefaults gekommen sein. Sonst macht die Nennung mit dem neuen Feature auch wenig Sinn.

Bisher steht immer noch als letztes Wort im Raum dass NV den Deal nicht wollte weil er sich nicht gerechnet hat. So wie bei der letzten Generation. AMD braucht jeden Cent dringend.

nVidia erzählt viel wenn der Tag lang ist.

Wobei Sie natprlich nur ein 2 Chip-Design hätten bieten können, und das eben in der Produktion teurer ist, was auf die Marge geschlagen hätte.

[Coda]

Wobei Sie natprlich nur ein 2 Chip-Design hätten bieten können, und das eben in der Produktion teurer ist, was auf die Marge geschlagen hätte.
Kommt drauf an wie weit Projekt Denver ist.

Für mich sah weder die Mars noch die Flugzeugdemo wirklich inakzeptabel aus, und genau dabei sollte es ja zu Pagefaults gekommen sein. Sonst macht die Nennung mit dem neuen Feature auch wenig Sinn.
Die Flugzeugdemo verwendet die Graphite-Middleware und die macht das ersetzen der Tiles natürlich auch verzögert.

[Skysnake]

Stimmt, da war diese Middleware noch dabei.

Bei Mars aber wohl nicht.

Mir kommt das eben ziemlich spanisch vor, pagefaults kategorisch aus schließen zu wollen, aber gleichzeitig eben genau das zu ermöglichen. Das widerspricht sich eigentlich. Entweder es ist zu einem gewissen Grad verkraftbar, dann macht die Implementierung Sinn, oder eben nicht, und ann macht Sie auch keinen Sinn.

[del_4901]

Mir kommt das eben ziemlich spanisch vor, pagefaults kategorisch aus schließen zu wollen, aber gleichzeitig eben genau das zu ermöglichen. Das widerspricht sich eigentlich. Entweder es ist zu einem gewissen Grad verkraftbar, dann macht die Implementierung Sinn, oder eben nicht, und ann macht Sie auch keinen Sinn.Die Implementierungen basieren auf virtuellem Speicher, man kann einfach mehrere virtuelle Pages auf einen physikalischen Frame zeigen lassen. Das wiederspricht sich natuerlich nur, wenn man das nicht kennt.

[Skysnake]

Das ist aber was ganz anderes, als paefaults jetzt zu zu lassen.

die Abstraktion von "virtuellen" und physischen adressen kann man auch über Software lösen. Nicht mal mit einem zu großen Performancehit, so lange man halt nicht ständig drin rum pfuscht.

Ich seh immer noch nicht das Problem an einem/wenigen Pagefaults. Dein Argument von wegen man hätte dann keine vorhersagbaren Laufzeiten ist ja richtig, aber das hast du doch im Prinzip nie. Jede Szene unterscheidet sich. Oder was wolltest du damit sagen.

[del_4901]

Das ist aber was ganz anderes, als paefaults jetzt zu zu lassen. ... Ich seh immer noch nicht das Problem an einem/wenigen Pagefaults.Was willst du uns jetzt eigentlich damit sagen? Hast du irgendwelche Agumentationen die dafuer sprechen? Hast du ueberhaupt Erfahrungen in der Games Industrie gesammelt?

Dein Argument von wegen man hätte dann keine vorhersagbaren Laufzeiten ist ja richtig, aber das hast du doch im Prinzip nie. Jede Szene unterscheidet sich.Natuerlich kann man das Laufzeitverhalten beeinflussen, wenn man das Streaming selber macht. Der Streamer bekommt halt ne bestimmte Zeit pro Frame zur freien Verfuegung, alles was in der Zeit nicht geschafft wird muss spaeter nachgeladen werden. Solange muss man sich eben mit einer kleineren Mip begnuegen. Dafuer braucht man keine teuren Pagefaults. Die Faults kommen nur dann ins Spiel wenn der Programierer waehrend der Entwicklungzeit wirklich mal vergessen hat was zu mappen, dann kann er sich das (oder QA) anzeigen lassen.

[Coda]

Oder der Streamer läuft halt komplett asynchron und macht immer so viel wie die Festplatte hergibt.

[del_4901]

Oder der Streamer läuft halt komplett asynchron und macht immer so viel wie die Festplatte hergibt. Asynchron laeuft der Streamer sowieso, aber ja, warscheinlich bottlenecked die HDD eher als der eigentliche Streaming-Thread.

[Coda]

Kann ja sein, dass du von ner PCIe-SSD läufst :)

[del_4901]

Kann ja sein, dass du von ner PCIe-SSD läufst :)Jetzt hast du mich auf ne Idee gebracht ... IT hat heute nen ganz schlechten Tag ... :P

[Coda]

:devil:

[Skysnake]

Was willst du uns jetzt eigentlich damit sagen? Hast du irgendwelche Agumentationen die dafuer sprechen? Hast du ueberhaupt Erfahrungen in der Games Industrie gesammelt?

Komm lass doch diese unterschwelligen Andeutungen weg, die einen als Gesprächspartner unzulänglich erscheinen lassen sollen weg. Das ist Kindergarten und Kontraproduktiv.

Ich habe eine ganz einfache Frage gestellt, und bereits vorher offen gesagt, das ich mit DX absolut keine Erfahrung habe, und daher gerne zu den Punkten etwas von den Leuten gerne hören würden, die damit arbeiten, oder zumindest Erfahrung mit DX haben, und wie man dort arbeitet. Deine "Frage" ist also total überflüssig gewesen :down:

Nochmals, ich habe eine These in den Raum gestellt, weil es mir unschlüssig erscheint. Wenn es dir so leicht fällt, dann bringt doch bitte nachvollziehbare Argumente, die mehr Inhalt haben als "Weil darum/Das ist halt so".


Natuerlich kann man das Laufzeitverhalten beeinflussen, wenn man das Streaming selber macht. Der Streamer bekommt halt ne bestimmte Zeit pro Frame zur freien Verfuegung, alles was in der Zeit nicht geschafft wird muss spaeter nachgeladen werden. Solange muss man sich eben mit einer kleineren Mip begnuegen.

Und warum sollte ich es selbst machen, wenn die Hardware das am Ende womöglich effizienter kann als ich?

Klar, einige Dinge macht man lieber von Hand, weil man eben sehr leicht vorhersagen kann, was man braucht. Das kann die Hardware nicht. Aber daher sollte man normal ja beide Möglichkeiten kombinieren.


Dafuer braucht man keine teuren Pagefaults. Die Faults kommen nur dann ins Spiel wenn der Programierer waehrend der Entwicklungzeit wirklich mal vergessen hat was zu mappen, dann kann er sich das (oder QA) anzeigen lassen.
Aha, da kommen wir dem Kern schon näher.

Woher weißt du/ich/wir denn, wie "teuer" ein Pagefault denn ist, und wie sich dieser denn dann am Ende wirklich auswirkt? Wenn man die Latenz durch den Pagefault mit anderen Aufgaben füllen kann, dann "kostet" der im Zweifel gar nichts. Mich wundert einfach nur diese stoische Sicherheit, das es völlig inakzeptabel ist.

Wenn du derartige Leistungsbetrachtungen hast, wo wann und wie sich die Pagefaults auswirken, wie viele µs Latenz Sie haben, und wieviele man eben im Mittel verstecken kann, oder eben auch nicht, dann immer her damit.

[del_4901]

Komm lass doch diese unterschwelligen Andeutungen weg, die einen als Gesprächspartner unzulänglich erscheinen lassen sollen weg. Stimmt, letzteres machst du schon von dir aus.

Nochmals, ich habe eine These in den Raum gestellt, weil es mir unschlüssig erscheint. Wenn es dir so leicht fällt, dann bringt doch bitte nachvollziehbare Argumente, die mehr Inhalt haben als "Weil darum/Das ist halt so".
Unvorhersehbares Laufzeitverhalten ist kein nachvollziehbares Argument? Coda? Gipsel? Ich finde es ist einfach auf den Punkt gebracht und absolut ausreichend als Argument.

Und warum sollte ich es selbst machen, wenn die Hardware das am Ende womöglich effizienter kann als ich?Reine Spekulation von deiner Seite.

Aber daher sollte man normal ja beide Möglichkeiten kombinieren. Weil in dem Fall gar keine Notwendigkeit dazu besteht.



Woher weißt du/ich/wir denn, wie "teuer" ein Pagefault denn ist, und wie sich dieser denn dann am Ende wirklich auswirkt? Wenn man die Latenz durch den Pagefault mit anderen Aufgaben füllen kann, dann "kostet" der im Zweifel gar nichts. Mich wundert einfach nur diese stoische Sicherheit, das es völlig inakzeptabel ist. Da ist einfach ein Memory(re)mapping involviert, das ist allein vom Prinzip schon teuer, da kann auch die beste Hardware nichts dran aendern. Und wenn dann noch im worst case zu trashing fuehrt... ohje. Das ueberlaesst man besser der Applikation, damit man es batchen kann.
Ich finde du bist der störrische Part in dieser Diskussion.

[Skysnake]

Stimmt, letzteres machst du schon von dir aus.

Du kannst es nicht lassen gell?


Unvorhersehbares Laufzeitverhalten ist kein nachvollziehbares Argument? Coda? Gipsel? Ich finde es ist einfach auf den Punkt gebracht und absolut ausreichend als Argument.

Wir hatten doch vorher schon festgestellt, dass du in gewissen Ramen immer Variationen hast. Sonst hätten wir ja fest gepinnte Frameraten und gut ist...


Reine Spekulation von deiner Seite.

Von deiner Seite aus, dass das eben nicht so wäre aber genau so. ;)

Sollte man sich vielleicht mal durch den Kopf gehen lassen, und drüber nachdenken, dass man es einfach nicht weiß, und erst mal schauen sollte, bevor man irgendwelche Absolutaussagen loslässt.


Weil in dem Fall gar keine Notwendigkeit dazu besteht.

Argument? [Weil darum?]


Da ist einfach ein Memory(re)mapping involviert, das ist allein vom Prinzip schon teuer, da kann auch die beste Hardware nichts dran aendern.
Ich finde du bist der störrische Part in dieser Diskussion.
Lesen bitte. Einfach lesen bevor du irgendwelche Plattheiten wieder auspackst. Das zeugt nämlich nicht davon, dass du dich mit Argumenten auseinandersätzt, und auch nur eine Sekunde darüber nachdenkst.

Nur als Erweiterung für die Allgemeinbildung:
störrisch [Synonyme: bockig, dickköpfig, unbelehrbar, verstockt, verborht]
stoisch so viel wie gleichmütig, unerschütterlich, gelassen [bekannte Verwendung: stoische Ruhe]
Ich hoffe du erkennst den Unterschied.

Also nochmals, woher nimmst du die Gewissheit, dass das "zu teuer" ist, und das schon bei einmaligem Auftreten? Das ist eine sehr sehr starke Aussage. Dazu würde ICH mich nie einfach so hinreisen lassen, ohne diesen Aspekt fundiert betrachtet zu haben.

[Coda]

...
Lass ihn doch einfach, irgendwann holt ihn die Realität sowieso ein ;)

[del_4901]

Wir hatten doch vorher schon festgestellt, dass du in gewissen Ramen immer Variationen hast. Sonst hätten wir ja fest gepinnte Frameraten und gut ist... Coda und ich haben schon festgestellt, das man durchaus mit diesen Variationen umgehen kann indem man dem Streamer ein Limit setzt.


Argument? [Weil darum?] Weil es auch ohne dem performant implementieren kann, indem man einfach ne fallback auf eine niedrigere Mip macht? Aber das haben wir doch alles schon durchgekaut.

Also nochmals, woher nimmst du die Gewissheit, dass das "zu teuer" ist, und das schon bei einmaligem Auftreten? Das ist eine sehr sehr starke Aussage. Dazu würde ICH mich nie einfach so hinreisen lassen, ohne diesen Aspekt fundiert betrachtet zu haben. Viel, viel profiling Erfahrung. Memory management war noch nie billig.

[john carmack]

"es ist kein dx12 geplant" heißt also dx11.1-9:confused:


genau das hab ich mir auch gedacht...
:D

[Coda]

Das kein DX12 geplant ist hat auch AMD behauptet, nicht Microsoft.

Ich hab mir übrigens mal die 8.1 Preview installiert, bin aber noch nicht dazugekommen das Demo zu kompilieren. Heute Abend vielleicht.

[Gipsel]

@Skysnake:
Also ich denke es sollte klar sein, daß man auf jeden Fall vermeiden will, daß man beim Rendering auf eine Textur wartet, die noch auf der Festplatte liegt. Das dauert dann im Zweifelsfall einen ganzen Frame oder noch länger. Da stellt man dann praktisch das Rendern ein, wenn man das wirklich behandeln will.
Was man sich vielleicht überlegen kann, ist, wie man die nachzuladenen Pages bestimmt. AMD beschreibt als Möglichkeit für ihr PRT-Feature, daß man wartet, bis man auf etwas trifft, was nicht geladen ist (also nicht gemapped ist, das verursacht dann einen PageFault, der aber nicht direkt behandelt wird, sondern man merkt sich ihn nur). Der Fetch setzt dann ein fail-flag und man kann den fehlenden Tile in einem UAV vermerken (was dann der Streamer asynchron nachlädt, damit das meinetwegen 2 oder 3 Frames später da ist). Alternativ setzt man eine Art LoD-Warngrenze, dann springt die Warnung schon an, wenn man sich nur einem definierten MipMap-Level nähert (ist dann allerdings nicht selektiv, wenn man nur einen Teil einer MipMap lädt, also wohl nicht immer hilfreich). Aber im Prinzip muß sich ein Entwickler die für ihn optimale Variante überlegen, wie er bestimmt, welche Tiles er mappen will (und auch wieder unmappen, sonst geht einem ja der Speicher aus), es ist also keine "vollautomatische" Lösung.

[del_4901]

@Skysnake:
Also ich denke es sollte klar sein, daß man auf jeden Fall vermeiden will, daß man beim Rendering auf eine Textur wartet, die noch auf der Festplatte liegt. Das dauert dann im Zweifelsfall einen ganzen Frame oder noch länger. Da stellt man dann praktisch das Rendern ein, wenn man das wirklich behandeln will.
Was man sich vielleicht überlegen kann, ist, wie man die nachzuladenen Pages bestimmt. AMD beschreibt als Möglichkeit für ihr PRT-Feature, daß man wartet, bis man auf etwas trifft, was nicht geladen ist (also nicht gemapped ist, das verursacht dann einen PageFault, der aber nicht direkt behandelt wird, sondern man merkt sich ihn nur). Der Fetch setzt dann ein fail-flag und man kann den fehlenden Tile in einem UAV vermerken (was dann der Streamer asynchron nachlädt, damit das meinetwegen 2 oder 3 Frames später da ist). Alternativ setzt man eine Art LoD-Warngrenze, dann springt die Warnung schon an, wenn man sich nur einem definierten MipMap-Level nähert (ist dann allerdings nicht selektiv, wenn man nur einen Teil einer MipMap lädt, also wohl nicht immer hilfreich). Aber im Prinzip muß sich ein Entwickler die für ihn optimale Variante überlegen, wie er bestimmt, welche Tiles er mappen will (und auch wieder unmappen, sonst geht einem ja der Speicher aus), es ist also keine "vollautomatische" Lösung.
So in etwa funktioniert das ganze, ich wuerde aber vorzugsweise trozdem eine dummy page mappen, und im shader selber bestimmen ob man einen hit hat, bevor man die komplette wavefront in den Panikmodus verfrachtet.

[Gipsel]

So in etwa funktioniert das ganze, ich wuerde aber vorzugsweise trozdem eine dummy page mappen, und im shader selber bestimmen ob man einen hit hat, bevor man die komplette wavefront in den Panikmodus verfrachtet.
Also GCN kann das in Hardware machen und gibt das (Hit ja/nein und wenn kein hit, welches MIP-Level fehlt) bei einem TextureFetch in einem zusätzlichen Register zurück. In CPU-Begriffen ist im Prinzip ist die PageFault-Exception maskiert (Exception Handler wird wohl außerhalb eines Debuggers kaum jemand einsetzen [wüßte jetzt auch gar nicht, daß man die z.B. in hlsl überhaupt definieren kann]) und man erhält im Shader direkt die nötige Information ohne zusätzlichen Code (man muß natürlich den Statuswert prüfen). Zumindest wenn ich das richtig verstanden habe. Oder wie willst Du einfacher im Shader bestimmen, ob Du einen Hit hattest oder nicht?

[Skysnake]

@Skysnake:
Also ich denke es sollte klar sein, daß man auf jeden Fall vermeiden will, daß man beim Rendering auf eine Textur wartet, die noch auf der Festplatte liegt. Das dauert dann im Zweifelsfall einen ganzen Frame oder noch länger. Da stellt man dann praktisch das Rendern ein, wenn man das wirklich behandeln will.
Wer redet denn von Festplatte? :ugly: Wenn ich das nicht deutlich genug kategorisch ausgeschlossen habe, dann sorry, aber das ist natürlich banane.

Mir gings rein um:
im RAM: Ja
im VRAM: Nein

Und da tut ein pagefault eben nicht weh, und darf meiner Meinung nach auch durchaus passiren.


Was man sich vielleicht überlegen kann, ist, wie man die nachzuladenen Pages bestimmt. AMD beschreibt als Möglichkeit für ihr PRT-Feature, daß man wartet, bis man auf etwas trifft, was nicht geladen ist (also nicht gemapped ist, das verursacht dann einen PageFault, der aber nicht direkt behandelt wird, sondern man merkt sich ihn nur). Der Fetch setzt dann ein fail-flag und man kann den fehlenden Tile in einem UAV vermerken (was dann der Streamer asynchron nachlädt, damit das meinetwegen 2 oder 3 Frames später da ist). Alternativ setzt man eine Art LoD-Warngrenze, dann springt die Warnung schon an, wenn man sich nur einem definierten MipMap-Level nähert (ist dann allerdings nicht selektiv, wenn man nur einen Teil einer MipMap lädt, also wohl nicht immer hilfreich). Aber im Prinzip muß sich ein Entwickler die für ihn optimale Variante überlegen, wie er bestimmt, welche Tiles er mappen will (und auch wieder unmappen, sonst geht einem ja der Speicher aus), es ist also keine "vollautomatische" Lösung.
So würde ich das auch erwarten. Man nimmt den Pagefault erst mal hin, schaut, was man noch so machen kann, und kommt eben zurück, dann wenn man eben maximal zurückommen muss, weil nichts anderes mehr zu tun ist, oder eben die Sachen da sind, und man ganz normal weiter machen kann.

Kritisch sind da ja nur zwei Punkt
1. man hat extrem viele Pagefaults -> Nach x innerhalb eines Frames weiß ich, dass ich das nicht geladen bekomme -> z.B. ich nutze eine MipMap drunter, die eben schon da ist bis zur nächsten Möglichkeit. Nachteil, ich seh es eventuell, aber ansonsten droppen halt die FPS definitiv.
2. Man kommt zurück, die Dinger sind aber immer noch nicht da, obwohl man nicht viele Pagefaults hatte -> man macht notgedrungen wohl das gleiche wie Zuvor. Man nimmt eine Stufe drunter. Ganz blöd wird es halt, wenn man sich die auch noch gespart hat.... Das ist halt wirklich der kritische Punkt, wo man dann echt Probleme bekommt, weil was soll man damit machen? Warten, oder auf eine "default" Textur ummappen? Das muss man dann aber immer selbst entscheiden.

Und wie schon gesagt. Gegen 1. kann man ja etwas tun, indem man Dinge die häufig genutzt werden, bzw wenn dann gleich komplett, wie z.B. bei Explosionen usw usw. auf jeden Fall im VRAM. Belassen.

Bleibt also nur noch das Problem, wo man von "Hand" Streamen muss, wenn man ein Spiel lädt, um die Ladezeit zu verkürzen, und eben dann, wenn der VRAM nicht mehr ausreicht für ein Minimalset, damit die Pagefaults eben unwahrscheinlich genug werden (wir gehen ja davon aus, dass die meisten Frames gar kein Pagefault auftritt, und wenn dann nur einige wenige ~10 bis max 100).

Jetzt ist halt die Frage, wie groß ist typischerweise so ein Minimalset, mit dem ich derartig niedrige Pagefault raten bekomme, dass Sie mir nicht mehr "weh" tun. Dafür ist eben die Anzahl der Pagefaults, die verkraftbar sind wichtig, und da tu ich mir wirklich schwer, ein 0 so einfach zu verdauen, da das für mich entgegen jedweder Erfahrung im Bereich Hardware ist.

Levelgrenzen sind nicht schön, aber Sie machen einem das Leben hier aber natürlich viel einfacher. Genau wie Triggerpunkte. Die Sachen muss man natürlich am Ende dann auch wieder über Streaming nachladen, wenn man keine Unterbrechungen im Spielgeschehen haben will, da sind aber die entwickler ziemlich kreativ, um so etwas zu kaschieren.

Ich sag nur irgendwelche Animationen, die einem Zeit verschaffen.

PS:
Alpha ich bitte dich den Namen raus zu editieren aus deinem Post. Der spielt hier nichts zu suchen und ist darüber hinaus auch noch falsch.

[Coda]

Und da tut ein pagefault eben nicht weh, und darf meiner Meinung nach auch durchaus passiren.
Der tut dir immer noch gewaltig weh wenn du da durch nen Exception-Handler kriechen musst der das Ding erstmal durch den PCI-Express popeln muss und währendessen deine ganze GPU nichts mehr macht, weil alle Threadgroups zufällig gerade an dieser Textur hängen. Zudem was willst du da mit einem Cache im RAM? In der Regel hat man vergleichbare Mengen an VRAM und RAM. Den RAM kann man für andere Dinge sinnvoller verwenden. Und bei APUs ist es sowieso das selbe.

Vergiss es einfach, das wird niemand so benutzen.

[Skysnake]

Wenn das für dich so sonnenklar ist, dann klär doch bitte auf, wieviel µs oder gar ms ein Pagefault einen Kostet, also das man eben nicht normal weiter arbeiten kann, sondern ein wie auch immer geartetes Exception-handling anwerfen muss.

Nur rein von der Größenordnung. Das sollte doch ein leichtes sein, wenn man derart klar eine Aussage treffen kann.

EDIT: nur um es nochmals klipp und klar zu sagen. Mit Pagefault ist hier nicht gemeint, dass die Daten gar nicht im RAM liegen, also auf HDD, sondern dass die Daten "nur" nicht im VRAM der GPU liegen, sehr wohl aber im RAM der CPU.

[del_4901]

Ich bin da voll und ganz bei Coda.
Daten "nur" nicht im VRAM der GPU liegen, sehr wohl aber im RAM der CPU. Und was das betrifft kann die GPU gar nicht wissen ob es im RAM liegt, sie weis ja nur, dass es nicht im VRAM liegt.

[Skysnake]

Das ist halt "Aufgabe" des Entwicklers. Als ob das jetzt ein unlösbares Problem wäre...

[del_4901]

Also GCN kann das in Hardware machen und gibt das (Hit ja/nein und wenn kein hit, welches MIP-Level fehlt) bei einem TextureFetch in einem zusätzlichen Register zurück. In CPU-Begriffen ist im Prinzip ist die PageFault-Exception maskiert (Exception Handler wird wohl außerhalb eines Debuggers kaum jemand einsetzen [wüßte jetzt auch gar nicht, daß man die z.B. in hlsl überhaupt definieren kann]) und man erhält im Shader direkt die nötige Information ohne zusätzlichen Code (man muß natürlich den Statuswert prüfen). Zumindest wenn ich das richtig verstanden habe. Oder wie willst Du einfacher im Shader bestimmen, ob Du einen Hit hattest oder nicht?Ein Pagefault betrifft die komplette Wavefront. (Alle muessen warten weil einer verkackt hat)
Ich wuerde DXT3 oder ein equivalentes BCN Texturformat mit 1bit Alpha suchen und dort vermerken ob ein Hit valide ist oder nicht. Der branch bertifft zwar immernoch die komplette wavefront, tut aber nicht so sehr weh wie ein fault.

[Skysnake]

Das alle warten müssen ist denke ich jedem klar. Die Frage ist halt, gibt es nicht genug Parallelität, um einfach etwas anderes zu tun? Der Wechsel kostet ja praktisch fast nichts.

[Gipsel]

Ein Pagefault betrifft die komplette Wavefront. (Alle muessen warten weil einer verkackt hat)
Ich wuerde DXT3 oder ein equivalentes BCN Texturformat mit 1bit Alpha suchen und dort vermerken ob ein Hit valide ist oder nicht. Der branch bertifft zwar immernoch die komplette wavefront, tut aber nicht so sehr weh wie ein fault.
Wie gesagt wartet da meines Wissens gar keiner, also bei GCN (oder tiled resources Tier 2, wenn das genau drauf mapped). Bei GCN haben die vector memory instructions (die buffer load/stores und auch die image load/stores für das normale Textursampling) einfach ein entsprechendes Bit im Instruktionfeld (TFE, Texture Fail Enable). Wenn das gesetzt ist, funktioniert alles genau so wie bei normalen Buffer-/Texturzugriffen, nur gibt es ein zusätzliches Zielregister, in welches der Status des Zugriffs ausgegeben wird (0 wenn hit, >0 wenn kein hit, das MipLevel, was den Fail ausgelöst hat, wird auch gleich noch mit ausgegeben). Wenn irgendwas nicht verfügbar ist (es reicht, wenn z.B. ein Tap für's AF nicht da ist), erfährt man das so also ohne jeglichen zusätzlichen Aufwand mit dem 1bit-alpha-Kanal. Wie gesagt, wird ja gar keine Exception ausgelöst, die sind praktisch immer maskiert *).
Im Prinzip geschieht ja bei jedem Zugriff ein Lookup in der PageTable. Ist betreffende Page gemappt, erfolgt der Zugriff, wenn nicht, gibt es eben eine entsprechende Statusmeldung zurück. Einen Performancenachteil sollte es dadurch nicht geben.
Die Behandlung des Fails ist dann natürlich wieder identisch.

Wie nV das intern löst, bin ich allerdings überfragt.

*):
Wenn man das mit Exceptions handhaben wollte, müßte man erstmal bei einem Fail manuell eine Exception generieren (das geht bei einem PageFault nicht automatisch im Unterschied zu einigen anderen Bedingungen), im Exceptionhandler einen CPU-Interrupt auslösen und damit auf CPU-Seite den Streamer anschubsen und wenn der fertig ist, die GPU-weiterlaufen lassen. Das ist wohl im Prinzip möglich (auch daß der Handler auf der GPU auf ein Signal von der CPU wartet). Aber wir sind uns ja einig, daß das kaum eine gangbare Lösung ist (und wohl auch ein ziemliches Gefrickel, weil das natürlich keine irgendwie unterstützte Methode ist).

[del_4901]

Wie gesagt wartet da meines Wissens gar keiner, also bei GCN (oder tiled resources Tier 2, wenn das genau drauf mapped). Bei GCN haben die vector memory instructions (die buffer load/stores und auch die image load/stores für das normale Textursampling) einfach ein entsprechendes Bit im Instruktionfeld (TFE, Texture Fail Enable). Wenn das gesetzt ist, funktioniert alles genau so wie bei normalen Buffer-/Texturzugriffen, nur gibt es ein zusätzliches Zielregister, in welches der Status des Zugriffs ausgegeben wird (0 wenn hit, >0 wenn kein hit, das MipLevel, was den Fail ausgelöst hat, wird auch gleich noch mit ausgegeben). Wenn irgendwas nicht verfügbar ist (es reicht, wenn z.B. ein Tap für's AF nicht da ist), erfährt man das so also ohne jeglichen zusätzlichen Aufwand mit dem 1bit-alpha-Kanal. Wie gesagt, wird ja gar keine Exception ausgelöst, die sind praktisch immer maskiert *).
Im Prinzip geschieht ja bei jedem Zugriff ein Lookup in der PageTable. Ist betreffende Page gemappt, erfolgt der Zugriff, wenn nicht, gibt es eben eine entsprechende Statusmeldung zurück. Einen Performancenachteil sollte es dadurch nicht geben.
Die Behandlung des Fails ist dann natürlich wieder identisch.

Wie nV das intern löst, bin ich allerdings überfragt.

*):
Wenn man das mit Exceptions handhaben wollte, müßte man erstmal bei einem Fail manuell eine Exception generieren (das geht bei einem PageFault nicht automatisch im Unterschied zu einigen anderen Bedingungen), im Exceptionhandler einen CPU-Interrupt auslösen und damit auf CPU-Seite den Streamer anschubsen und wenn der fertig ist, die GPU-weiterlaufen lassen. Das ist wohl im Prinzip möglich (auch daß der Handler auf der GPU auf ein Signal von der CPU wartet). Aber wir sind uns ja einig, daß das kaum eine gangbare Lösung ist (und wohl auch ein ziemliches Gefrickel, weil das natürlich keine irgendwie unterstützte Methode ist).

Ich werde mal aus Neugier untersuchen wie teuer es wirklich ist.
Technisch geht es mit 1 bit Alpha aber auch selbst mit AF (alle Werte ungleich genau 0 oder 1). Die betreffenden Mips bekommt man auch raus, denn man hat ja den Gradienten. Der Streamer selber muss ja buchhalten was gemappt ist. Man wuerde sogar rausbekommen ob mehrere Mips betroffen sind.

[M4xw0lf]

:popcorn:
Ich versteh kein Wort, aber es ist geil eure Gespräche zu lesen :D

[Gipsel]

Also Tiled Resources haben eventuell generell einen gewissen Performancenachteil gegenüber ganz normalen Texturen. Vermutlich weil die TLBs zum Cachen der Pagetables einfach nicht robust genug sind. Ich glaube irgendwo mal gelesen zu haben, daß man das insbesondere bei hohen AF-Graden mit Tiled Resources beobachten kann (Zugriff auf mehr Taps aus hochaufgelöster MipMap => mehr Lookups => mehr potentielle Möglichkeiten für einen Fail, edit: das ging um die sparse texture extension für OpenGL, aber das ist ja das Gleiche). Das wäre also vermutlich ein geeigneter Ansatzpunkt für so einen Test.

[Skysnake]

Dafür hat doch, wenn ich das richtig verstanden habe, DX11.2 doch die Möglichkeit mehrere Tiles zusammen zu binden. Damit sollte man sowas abfangen können, weil man eben "einfach" nur mehr Daten liest.

Ich bin jetzt allerdings etwas verwirrt von deiner Ausführung Gipsel. Ich bin bisher davon ausgegangen, dass die GPU eben drüber läuft, man dann einen Miss feststellt, wobei ich auch von einer Lösung über Register ausgegangen bin, und dann eben der Shader oder what ever eben unterbrochen wird, und die Hardware dann selbst eben das nachladen inkl DMA oder what ever initialisiert.

Ich bin jetzt eher weniger davon ausgegangen, dass die CPU dafür überhaupt benötigt. Was soll die auch machen? Nen interrupt bekommen, und dann die Daten rüber schieben? Das kann die GPU auch von allein. Man muss halt nur sicherstellen, dass die Daten auch da sind. Seh ich jetzt aber nicht als DAS Problem an. Macht man nonmappable und gut ist. Von Platte laden ist eh ziemlich bescheiden in der Situation. Man müsste also zur Not eben bevor man Sachen aus dem Speicher schiebt, die entsprechenden Lookup tables auf der GPU updaten. Nervig, aber auch kein Problem.

Normal sollte man diese ganze Mechanik ja durch die DX11.2 API verstecken. Zumindest hätte ich absolut keinen Bock darauf, mich um den ganzen Mist noch kümmern zu müssen, wenn die schon solche Sachen einführen.

[Coda]

DirectX ist eine Low-Level-API, da willst du so viel Kontrolle wie du haben kannst ohne das es nicht mehr IHV neutral ist. Alles andere muss durch die Engine oder Middleware gelöst werden.

In letzter Zeit gibt es ja sogar Schritte in Richtung dass du das Textur-Swizzling/Tiling selber machen kannst. Intel exposed das sogar durch einen Hack in Direct3D. Auf den Konsolen ist das total super, da kannst du deine Daten direkt im richtigen Format auf die Platte legen und nur noch in den VRAM kopieren.

[del_4901]

DirectX ist eine Low-Level-API.
*hust*

[Coda]

Lies weiter :tongue:

Ich würde direkten Registerzugriff mit paar Macros auch nicht mehr als "API" bezeichnen ;)

[del_4901]

Ich huelle mich lieber in den Mantel des Schweigens und kurier meine Erkaeltung aus.

[Coda]

Ich weiß Bescheid ;)

[Skysnake]

DirectX ist eine Low-Level-API, da willst du so viel Kontrolle wie du haben kannst ohne das es nicht mehr IHV neutral ist.

Klar, aber die nVidia und AMD Lösung wird sich ja relativ stark unterscheiden in diesem Punkt. Daher erwarte ich da eher mehr Abstraktion, denn weniger.


In letzter Zeit gibt es ja sogar Schritte in Richtung dass du das Textur-Swizzling/Tiling selber machen kannst. Intel exposed das sogar durch einen Hack in Direct3D.

hm...
Keine Ahnung, ob ich die Ausrichtung positiv oder eher negativ sehen soll. Wenn man wieder anfängt, Herstellerspezifisch rum zu wurschteln, dann zersetzt sich so langsam der Vorteil einer abstrakten API. Klar, die Möglichkeit zu haben, wenn man denn will auch Hardwarenäher zu arbeiten ist immer begrüßenswert, aber es sollte meiner Meinung nach im Optimalfall nie zwingend erforderlich sein. (Außer natürlich wegen Performance)


Auf den Konsolen ist das total super, da kannst du deine Daten direkt im richtigen Format auf die Platte legen und nur noch in den VRAM kopieren.
Macht ihr das nicht unter DX? :ugly:

Das wäre ja schon ziemlich schwach. Warum immer und immer wieder die gleichen Aufgaben erledigen.

[Coda]

Klar, aber die nVidia und AMD Lösung wird sich ja relativ stark unterscheiden in diesem Punkt. Daher erwarte ich da eher mehr Abstraktion, denn weniger.
Davon geh ich nicht aus. Beide werden halt page table translation bei allen Speicherzugriffen haben. Brauchen sie ja allein schon für ihren Compute-Kram.

Bei NVIDIA scheint es nur die Einschränkung zu geben, dass du nichts lesen darfst was nicht gemappt ist, sonst fliegt's dir wohl um die Ohren.

[Skysnake]

Das wäre aber schwach von AMD, wenn Sie da die Möglichkeiten ihrer Hardware nicht effektiver einsetzen würden. AMD hat so viele Möglichkeiten mit GCN.... Nur durch High-lvl-APIs nutzen tun Sie scheinbar nur verdammt wenig...

[del_4901]

Das wäre aber schwach von AMD, wenn Sie da die Möglichkeiten ihrer Hardware nicht effektiver einsetzen würden. AMD hat so viele Möglichkeiten mit GCN.... Nur durch High-lvl-APIs nutzen tun Sie scheinbar nur verdammt wenig... Was wir hier dir versuchen zu erklaeren, das es wenig mit der Hardware zu tun hat. Es waehre einfach auch schlechtes Design es anders zu machen. Ich mag GCN, aber ich mag auch Kepler. Mal den einen mal den anderen, jeh nachdem welchen ich gerade gegeneinander ausspielen kann.

[Skysnake]

AMD muss die Funktion in ihrem Treiber implementieren. Wie Sie das machen ist ihre Sache. Für den API-Nutzer ist das scheis egal, was Sie da genau machen, es hat nur das für ihn sichbar so zu tun, wie er es von der Doku her erwartet.

Das Problem, aktuell fehlt uns ja die Doku....

Soweit ich das aber durch Coda verstanden habe, unterscheidet sich die Implementierung von AMD und nVidia eh, also es gibt Einschränkungen, und handelt sich nicht um eine 100% äquivalente Umsetzung der Funktion.

[del_4901]

AMD muss die Funktion in ihrem Treiber implementieren. Wie Sie das machen ist ihre Sache. Für den API-Nutzer ist das scheis egal, was Sie da genau machen, es hat nur das für ihn sichbar so zu tun, wie er es von der Doku her erwartet.
Oh so egal ist das nicht, wenn du irgendwann mal in der Games Industrie landen solltest, dann wirst du schon den die ganzen Freuden miterleben koennen: Wenn der Treiber wieder mal etwas laenger braucht. Dann hilft auch kein Snickers mehr.

[Skysnake]

Da muss ich nicht in der Gameindustrie arbeiten, da langen mir schon absolut meine eigenen Erfahrungen mit Treibern die nicht das machen was Sie sollen....

[Coda]

Soweit ich das aber durch Coda verstanden habe, unterscheidet sich die Implementierung von AMD und nVidia eh
Ich sagte doch: Nicht wesentlich.

[Skysnake]

Nicht wesentlich im Sinne von: am Ende kann ich den gleichen Code verwenden, habe aber dann aber Performancehits, welche aber vernachlässigbar sind.
Oder nicht wesentlich im Sinne von: ich muss den Code anpassen, aber die Performancehits sind nicht relevant.

Das ist nen großer Unterschied. Die zweite Möglichkeit ist je nachdem wie groß die Anpassungen ausfallen schon ein Nachteil. Läuft es doch dann im Endeffekt darauf raus, das man wieder Herstellerspezifisch arbeiten muss, was, wenn man schon DX verwendet, nicht erstrebenswert ist.

[del_4901]

Es gäbe noch eine 3te Moeglichkeit: "am Ende kann ich den gleichen Code verwenden, und habe keine Performancenachteile."

[Skysnake]

So wie Coda das aber erzählt ist das aber nicht so. Zumindest hat er ja schon mehrfach einen Unterschied genannt.

[Coda]

Ja, der darin liegt, dass du alle virtuellen Pages einmal am Anfang auf eine schwarzes physikalisches tile mappst. Done.

Das ist in der Praxis völlig nebensächlich.

[Skysnake]

Ja, das wäre zwar ärgerlich, weil man dran denken muss, aber wenn man wirklich nur einmalig dran denken muss, dann hält sich das wahrlich in Grenzen.

[Iruwen]

Bezieht sich das jetzt konkret auf den Unterschied zwischen Tiled Resources Tier 1 und 2?

[Coda]

Update: Ich hab's jetzt gestestet mit ner GTX 680 auf Windows 8.1 Preview.

Der Treiber meldet Tier-1-Support, allerdings scheint es doch noch andere Restriktionen zu geben, denn das Demo läuft auf Anhieb so nicht auf NVIDIA. Die Runtime gibt bei bestimmten calls E_INVALIDARGS zurück. Im Web hat einer der Entwickler geschrieben, dass sie das nicht testen konnten, weil sie noch keinen Tier-1-Treiber hatten vor der Build-Konferenz.

Deshalb nehm ich meine Einschätzung erstmal zurück, ich weiß nicht ob es nicht doch nervigere Einschränkungen auf NVIDIA-Karten gibt. Ich hoffe natürlich nicht, denn ich kann mir einige Anwendungen für das Feature vorstellen.

[Nighthawk13]

Ein Blick in die OpenGL-Spec:
http://www.opengl.org/registry/specs/AMD/sparse_texture.txt

Das ist im wesentlichen die kleine Variante, die Nvidia(in DirectX) implementiert hat:
If a standard texture function is used to sample from a region of a texture
image where storage is uncommitted, undefined data is returned to the
shader (although no instability results). If the application can guarantee
that this will not occur (such as when well defined texture coordinates are
used with a texture atlas, for example), then standard texturing functions
may be used with partially resident textures. If there is a possibility that
at the time of use, data in the texture may be non-resident (uncommitted),
one of the sparse texture functions may be used to determine the residency
status of the data.
"If the application can guarantee that this will not occur" heisst de Fakto, alle Regionen müssen gemapped sein.

AMD erlaubt, dass Regionen ungemapped sind und der Sampler ein Fehlerwert zurückliefert:

The sparse texture functions return a condition code indicating the success
of a texel fetch operation. If texture data is present at the sampled
location, the texture data is returned in the <texel> inout parameter and
the function returns zero. If texture data is not present at the sampled
location, <texel> is unmodified and the function returns a non-zero status
code. It is then the responsibility of the shader to determine the
appropriate course of action.

Schön wäre noch, wenn die Hardware auf die nächstebeste gemappte Mipstufe zurückspringt, um das Sample zu bestimmen. Das muss man aber im Shadercode machen. (Oder was will man sonst machen, wenn der Sampler "unmapped" zurückliefert?)

[Coda]

Die Hardware benutzt dann schon automatisch die niedriger aufgelösten Mips, es geht wohl nur um den Fall, dass gar nichts gemappt ist.

Zumindest hoffe ich das, sonst macht's ja überhaupt keinen Sinn.

[Nighthawk13]

In der OpenGL Extension ist es nicht so, da müsste man sowas machen:
while (unmapped)
Teste nächste Mipstufe
Eventuell ist das auch gar nicht so schlimm wie es sich anhört, wenn der Texturzugriff im unmapped-Fall sehr schnell ist(early exit wenn MMU sagt unmapped).

K.A. wie das in DirectX läuft.

[Chris Lux]

Die Hardware benutzt dann schon automatisch die niedriger aufgelösten Mips, es geht wohl nur um den Fall, dass gar nichts gemappt ist.
soweit ich weiss macht sie das nicht. ich kenne jedoch aktuell nur die AMD extension:

man muss sich selbst merken ob und auf welcher mip-stufe daten resident sind:

sampler2D prt;
vec2 coord = ...;
vec4 oldStype = texture( prt, coord );
vec4 newStyle;
int returnCode = sparseTexture( prt, coord, newStyle );
if ( sparseTexelResident( returnCode ) == false ) {
returnCode = sparseTextureLod( prt, coord, lastKnownResidentLOD, newStyle );
// inform the app to swap in more texture tiles!
}


quelle: http://renderingpipeline.com/2012/03/partially-resident-textures-amd_sparse_texture/

[Coda]

Ah okay. Wenn es failed, dann muss man zurückfallen auf eins wo man weiß, dass es da ist. Ist ja ekelig ;)

Aber macht Sinn wenn man bedenkt, dass die TMUs einfach nur virtuelle Adressen generieren und nicht automatisch wissen welches LOD jetzt gemappt ist.

[Gipsel]

Ah okay. Wenn es failed, dann muss man zurückfallen auf eins wo man weiß, dass es da ist. Ist ja ekelig ;)

Aber macht Sinn wenn man bedenkt, dass die TMUs einfach nur virtuelle Adressen generieren und nicht automatisch wissen welches LOD jetzt gemappt ist.
Wenn Du wie bei Tier1 alle auf eine (sagen wir mal einfarbig graue oder schwarze) Tile mappst (oder wie von AlphaTier vorgeschlagen, den Alphakanal benutzt, um gültig oder ungültig zu enkodieren), weißt Du ja im Shader auch nicht, auf welches LOD Du zurückfallen mußt. Oder sehe ich das falsch?
Im Prinzip ist es vielleicht der Einfachheit halber (möglichst gleicher Code für Tier1 und 2) wirklich keine schlechte Idee, so eine Lösung zu benutzen wie von AlphaTier vorgeschlagen (immer alles mappen, aber nicht geladenen Tiles auf einen einfarbigen Tile mit Kennzeichnung im Alpha-Kanal). Nähert man sich einer ungeladener Mipmap, dann wird ja bei einem Tri- bzw. AF-Filter die graue, einfarbige Textur mit einem sehr geringen Gewicht dazugemixt. Das ergibt dann vielleicht eine kleine Farbverfälschung, dürfte aber nicht so tragisch sein (vor allem, wenn die fehlenden Samples wegen Transparenz nicht zur resultierenden Farbe beitragen, edit: ach, das stimmt ja nur für's Blending, beim Texturfilter wird einfach linear interpoliert und der Alpha-Wert nicht berücksichtigt, also ist grau wohl besser als schwarz). Durch Testen des Alpha-Wertes weiß man auch, ob man den nächsten Tile laden muß. Einziger Nachteil den ich sehe, ist daß man auf Texturformate mit entsprechendem Alphakanal beschränkt ist und den verschwendet bzw. nicht anderweitig nutzen kann.

[del_4901]

Wenn Du wie bei Tier1 alle auf eine (sagen wir mal einfarbig graue oder schwarze) Tile mappst (oder wie von AlphaTier vorgeschlagen, den Alphakanal benutzt, um gültig oder ungültig zu enkodieren), weißt Du ja im Shader auch nicht, auf welches LOD Du zurückfallen mußt. Oder sehe ich das falsch?Mit dem Gradienten zusammen und der Coverage koennte man abschaetzen wie weit man von der Mip entfernt sein muss, das ist aber auch nur eine Schaetzung. Bruteforce alles bis nach unten durchtesten ist warscheinlich noch am guenstigsten. Oder man macht einen weiteren Versuch und wenn der auch nicht klappt nimmt man die kleinste Mip (welche immer vorraetig sein sollte).

Einziger Nachteil den ich sehe, ist daß man auf Texturformate mit entsprechendem Alphakanal beschränkt ist und den verschwendet bzw. nicht anderweitig nutzen kann.
Ja das ist wirklich ein Problem, duerfte aber fuer den common UseCase zu verkraften sein. Alle Texturen will man eh nicht virtualisieren. Fuer Terrain macht es noch am meissten Sinn. Bei den normalen dynamischen Objekten ist es schon fast wieder ne Spielerei. Alternativ kann man auch ne 2te bitfieldtextur mappen (ich glaube so ein Format irgendwo mal gesehen zu haben).

[Coda]

Wenn Du wie bei Tier1 alle auf eine (sagen wir mal einfarbig graue oder schwarze) Tile mappst (oder wie von AlphaTier vorgeschlagen, den Alphakanal benutzt, um gültig oder ungültig zu enkodieren), weißt Du ja im Shader auch nicht, auf welches LOD Du zurückfallen mußt. Oder sehe ich das falsch?
Im Prinzip ist es vielleicht der Einfachheit halber (möglichst gleicher Code für Tier1 und 2) wirklich keine schlechte Idee, so eine Lösung zu benutzen wie von AlphaTier vorgeschlagen (immer alles mappen, aber nicht geladenen Tiles auf einen einfarbigen Tile mit Kennzeichnung im Alpha-Kanal). Nähert man sich einer ungeladener Mipmap, dann wird ja bei einem Tri- bzw. AF-Filter die graue, einfarbige Textur mit einem sehr geringen Gewicht dazugemixt. Das ergibt dann vielleicht eine kleine Farbverfälschung, dürfte aber nicht so tragisch sein (vor allem, wenn die fehlenden Samples wegen Transparenz nicht zur resultierenden Farbe beitragen, edit: ach, das stimmt ja nur für's Blending, beim Texturfilter wird einfach linear interpoliert und der Alpha-Wert nicht berücksichtigt, also ist grau wohl besser als schwarz). Durch Testen des Alpha-Wertes weiß man auch, ob man den nächsten Tile laden muß. Einziger Nachteil den ich sehe, ist daß man auf Texturformate mit entsprechendem Alphakanal beschränkt ist und den verschwendet bzw. nicht anderweitig nutzen kann.
Oder man schreibt es einfach in einen Feedback-Buffer so wie Rage es auch macht (und so wie ich gesehen habe auch das Mars-Demo).

Muss mir da mal den Shader anschauen (Notiz: Wieso hab ich das bisher eigentlich nicht gemacht?)

[del_4901]

(Notiz: Wieso hab ich das bisher eigentlich nicht gemacht?)OpenGL Profling tools are much more limited than even their DirectX counterparts already are. But the Source should be somewhere in the pak.

[Skysnake]

Ah okay. Wenn es failed, dann muss man zurückfallen auf eins wo man weiß, dass es da ist. Ist ja ekelig ;)

Aber macht Sinn wenn man bedenkt, dass die TMUs einfach nur virtuelle Adressen generieren und nicht automatisch wissen welches LOD jetzt gemappt ist.
Das bedeutet dann aber, wenn ich es richtig verstanden habe, das man im Prinzip die niedrigste Stufe für alle Texturen laden muss, oder zumindest fest auf irgend eine "dummy-Textur" referenzieren muss.

Das würde dann natürlich ziemlich bescheiden aussehen, wenn da ne komplett falsche Textur auf einmal landet ;)

Wenn ich das jetzt aber richtig verstehe, lädt bei der nVidia Lösung nichts automatisch nach oder?

Bei der AMD Lösung kann man das aber durchaus machen oder?

PS:
Wie lief dann bitte die Demo :confused:

[Coda]

Wenn ich das jetzt aber richtig verstehe, lädt bei der nVidia Lösung nichts automatisch nach oder?

Bei der AMD Lösung kann man das aber durchaus machen oder?
Kein Unterschied.

Die Demo rendert zuerst einen Residency-Buffer, der wird gesampled und dann nochmal gezeichnet. Somit weiß der Shader immer was resident ist und was nicht.

[Skysnake]

Gut.

Das bezieht sich aber auf die Demo, gibt es prinzipiell auch keinen Unterschied? Also was würde passieren, wenn man jetzt nur auf AMD hin optimiert. Könnte man dann die Hardware das Nachladen übernehmen lassen? Bisher habe ich das immer so verstanden.

[Coda]

Nein, könnte man nicht. Lies mal die OpenGL-Extension von AMD, da ist das recht gut aufgeführt alles.

Was sein könnte bei NVIDIA ist, dass man im Shader gar nicht mal fragen kann, ob es denn resident ist oder nicht. Man MUSS es wissen wenn man rendert.

[del_4901]

Die Demo rendert zuerst einen Residency-Buffer, der wird gesampled und dann nochmal gezeichnet. Somit weiß der Shader immer was resident ist und was nicht.
Speichern die sich min und max resident mip (R8G8)? Dann braucht man nichtma nen branch und ein extra bit. ein clamp wuerde dann auch ausreichen.
Paste mal nen snippet, ich bin grad zu faul zum suchen. :devil:

[Coda]

Sie rendern das LOD raus, dass sie samplen wollen (sie haben nur eine Textur).

Wie sie dann garantieren dass es auch resident ist hab ich noch nicht verstanden, hatte keine Zeit mehr den Code noch genauer zu verfolgen.

[del_4901]

Sie rendern das LOD raus, dass sie samplen wollen (sie haben nur eine Textur). Und stecken das direkt in den Sampler? Ja, das muesste auch gehen und spaart sogar noch das clamp.

[Coda]

Ja, genau.

[Chris Lux]

bekommt man die demos irgendwo? ich kann irgendwie nichts finden...

edit: gefunden. mann warum kann man das nicht wirklich googlen.

[Coda]

Für andere Interessenten: http://code.msdn.microsoft.com/Direct3D-Tiled-Resources-80ee7a6e

[Chris Lux]

Für andere Interessenten: http://code.msdn.microsoft.com/Direct3D-Tiled-Resources-80ee7a6e
sorry, hätte ich gleich posten können.

hier gibt es auch die resoucen (textures, geometry):
https://tiledresources.codeplex.com/

windows 8.1 sdk (incl. directx 11.2 sdk):
http://msdn.microsoft.com/en-us/windows/desktop/bg162891

[Coda]

Oder einfach VC++ 2013 Preview installieren, da ist das Windows SDK dabei.

[Nighthawk13]

Am Rande: Sparse textures gibt es (in der kleinen Nvidia Variante) als OpenGL ARB Extension:
http://www.opengl.org/registry/specs/ARB/sparse_texture.txt
https://developer.nvidia.com/opengl-driver

[StefanV]

Wie schaut es jetzt eigentlich bei AMD GCN Karten aus? Werden die 11.2 mit Featurelevel 11.2 können oder wahrscheinlich/vermutlich nicht?

[Iruwen]

Wars nicht so dass jede Hardware die Feature Level 11_1 erfüllt automatisch 11_2 erfüllt?

[just4FunTA]

"Tiled Resources" allows for significant enhancement of in-game textures by making it possible to simultaneously access GPU and traditional RAM memory and create a single large buffer where large textures can be stored. This technique was demonstrated with a model of Mars which displayed a 3 GB texture using just 16 MB of GPU memory and in Graphine’s Granite Flight Simulator that showed "a remarkably detailed island with gliders constructed out of 64 megapixels."

http://www.tomshardware.com/news/DirectX-11.2-Tiled-Resources-Xbox,23322.html


Mal ne laienfrage, heißt das jetzt ich könnte ne Crysis Map die sagen wir mal im Schnitt 2 gig vram nutzt auf einer dx11 Karte mit 512mb vram spielen ohne Einbrüche zu haben, oder würde man das während dem Spielen trotz Tiled Resources merken?

Oder um ein reales Beispiel zu bringen auf meiner alten graka mit 1gb vram sorgte das umstellen der Texturen von High auf Ultra in Battlefield 3 zu stottern, ich vermute mal jedesmal wenn der vram ausging kam das stottern. Wäre durch das tiled ressources feature dieses Problem behoben?

[Chris Lux]

nein.

tiled resources erlauben entwicklern texturstreaming etwas feiner zu steuern. bisher wurden nur ganze mipmap-levels von texturen am stueck gestreamt, nun kann man eben diese level noch in kacheln unterteilen und diese je nach gebrauch laden. dies ist jedoch nichts, was direkt automatisch funktioniert...

[Iruwen]

Rage's MegaTexture System hätte damit vermutlich besser funktioniert?

[del_4901]

Rage's MegaTexture System hätte damit vermutlich besser funktioniert?
Carmack hat das dem Microsoft Graphics Advisory Board schon vor Jahren vorgeschlagen.