Rendering von Star Swarm

[Demirug]

Das es ja nur indirekt mit Mantle zu tun hat mache ich mal einen neuen Thread dafür auf.

Wie schon gesagt rendert Star Swarm mit einer reinen Brute Force Methode in 4 Schritten.

1. Texture Space Beleuchtung. Von jedem Objekt das auf dem Bildschirm zu sehen ist wird in eine große zusätzliche Texture eine vorbeleuchtete Version der benötigten Mipmap der Texture gerendert.

2. Die in Schritt 1 erzeugten Texturkopien werden nun benutzt um jedes einzelne Objekt zu rendern. Abhängig von der Entfernung als einfache Viereck (Sprite) bis hin zu echter 3D Geometrie für die näheren Objekte. Ist Temproales AA aktiviert werden die Objekte entsprechend mehrfach gerendert.

3. Die zusätzlichen Überstrahl Effekte werden Ergänzt.

4. Das User Interface

Beim Rendercode fallen zwei Dinge auf.

1. Die Anweisungen sind in mehrere Blöcke eingeteilt welche jeweils mit einer vollständigen Initialisierung des Contextes beginnen. Es ist davon auszugehen das jeder dieser Block beim Multithreading rendering (Mantle) von einem eigenen Thread übernommen werden kann.Im Singlethread Fall hätten man bei entsprechender Optimierung die redundanten States weitgehend entfernt.

2. Schwerwiegender ist jedoch das jedes Objekt mit einem einzelnen Draw Call genrendert wird. Das fällt vorallem im ersten Schritt auf. Da dort nur Texture umkopiert und beleuchtet werden hat jeder dieser Draw Calls nur zwei Dreiecke. Entsprechend werden hier bereits mehr Drawcalls benötigt als die meisten Spiele für einen ganzen Frame brauchen.

Es ist offensichtlich das hier in Richtung maximalen Drawcall Durchsatz optimiert wurde. Bei einer Optimierung auf maximale FPS müsste man bei dieser Rendertechnik überall die Verwendung von Instaning sehen. Überschlagsweise könnte man damit mehr als 95% der Drawcalls einsparen.

Anhänge Ergebniss für Schritt 1. Ausschnitt in Originalgröße.& Vollständig auf 15% verkleinert.

[sloth9]

war doch klar, das die demo nur mantle promoten soll, mit real-life-games hat das nix zu tun.

[Mao ZeDong]

Erinnert an die DX11 Version von Crysis 2 in der massenweise GPU sinnlos verschwendet wurde an Punkten, die der AMD Karte weh tun.
Also ist Star Swarm in Wirklichkeit die lange gesuchte Demo für Mantle.

[uweskw]

......
Wie schon gesagt rendert Star Swarm mit einer reinen Brute Force Methode in 4 Schritten.

1. Texture Space Beleuchtung. Von jedem Objekt das auf dem Bildschirm zu sehen ist wird in eine große zusätzliche Texture eine vorbeleuchtete Version der benötigten Mipmap der Texture gerendert.

2. Die in Schritt 1 erzeugten Texturkopien werden nun benutzt um jedes einzelne Objekt zu rendern. Abhängig von der Entfernung als einfache Viereck (Sprite) bis hin zu echter 3D Geometrie für die näheren Objekte. Ist Temproales AA aktiviert werden die Objekte entsprechend mehrfach gerendert.

3. Die zusätzlichen Überstrahl Effekte werden Ergänzt.

4. Das User Interface

Beim Rendercode fallen zwei Dinge auf.

..........


Die Unterschiede zwischen DX11 und Mantle bei Star Swarm, betreffen die nur das Rendern oder auch KI und Physik?

Greetz
U.S.

[Demirug]

Die Unterschide zwischen DX11 und Mantle bei Star Swarm, betreffen die nur das Rendern oder auch KI und Pyhsik?

Greetz
U.S.

Das wird man ohne Zugriff auf den Sourcecode nicht zu 100% feststellen können. Persönlich gehe ich davon aus das es identisch ist.

[Hübie]

Mit anderen Worten: statt massiv im Detailgrad gesteigerten content sieht man etwas dass man mit jeder API hingekommen würde? :|
Das wäre ja pure Ressourcenverschwendung in jeder Hinsicht. Wozu soll dass dann gut sein?

[TheGoD]

Es ist offensichtlich das hier in Richtung maximalen Drawcall Durchsatz optimiert wurde. Gibt es für diese Designentscheidung bei der Entwicklung eines aktuellen Titels durch ein professionelles Team deiner Meinung nach eine andere Begründung als die naheliegenden Vermutung hiermit Mantle zu promoten (und der damit verbunden mehr Presse für das Spiel zu erhalten)? Sparen von Entwicklungskosten oder höhere Flexibilität zum Beispiel?

[deekey777]

Da hatte Crytek mit Far Cry noch richtig Glück!
X-D

[Iruwen]

Mit anderen Worten: statt massiv im Detailgrad gesteigerten content sieht man etwas dass man mit jeder API hingekommen würde? :|
Das wäre ja pure Ressourcenverschwendung in jeder Hinsicht. Wozu soll dass dann gut sein?
Eine Worst Case Demo die zeigt, welche Menge von Draw Calls mit Mantle im Gegensatz zu DX11 möglich wäre. Die Frage ist: wäre eine derartige Menge von Draw Calls in einem Spiel auch sinnvoll einsetzbar ohne dass man einen Großteil davon durch Instancing oder whatever vermeiden könnte? Hat selbiges Nachteile?

[del_4901]

Ihr stellt die Fragen falsch. Jeder der das beantworten soll, lehnt sich bei der aktuellen Informationslage entweder gefaehrlich weit aus dem Fenster. Oder geht damit soweit ins Detail und eroertert verschiedene Moeglichkeiten (wohlgemerkt keine Fakten), dass am Ende Perlen vor die Saeue geworfen werden.

[Iruwen]

Baker said that the Direct3D performance for the game absolutely outstanding. We have spent a huge amount of time optimising around D3D, and are biased in D3D's favor. “Mantle, on the other hand, we've spent far less time with and currently have only pretty basic optimizations. But Mantle is such an elegant API that it still dwarfs our D3D performance," Baker said.

http://www.fudzilla.com/home/item/33974-mantle-is-disruptive-technology

Was sagt uns das jetzt?

/e: sorry für den Crosspost, passte irgendwie in beide Topics.

[aths]

Eine Worst Case Demo die zeigt, welche Menge von Draw Calls mit Mantle im Gegensatz zu DX11 möglich wäre. Die Frage ist: wäre eine derartige Menge von Draw Calls in einem Spiel auch sinnvoll einsetzbar ohne dass man einen Großteil davon durch Instancing oder whatever vermeiden könnte? Hat selbiges Nachteile?
Es ergibt keinen Sinn, durch absichtlich aufgeblähnte Drawcalls und Contextswitches der CPU Leistung zu entziehen, die anderswo sinnvoller eingesetzt wäre.

http://www.fudzilla.com/home/item/33974-mantle-is-disruptive-technology

Was sagt uns das jetzt?

/e: sorry für den Crosspost, passte irgendwie in beide Topics.
Das sagt uns, dass sich Entwickler von diversen Herstellern für Werbeaussagen kaufen lassen. Was nicht heißt, dass ein Entwickler nur auf einer einzigen Hochzeit tanzt.

[Unicous]

Jaja. Alle gekauft.


/thread closed

[Coda]

Naja es steht eben eine Aussage im Raum, die nicht vereinbar mit der technischen Realität ist. Die Gründe dafür wissen wir nicht.

[fondness]

Das Problem ist das die Aussage aus dem Kontext gerissen wurde. Die Aussage bezieht sich auf die Drawcalls. Baker sagt das die Engine in Hinblick auf die Drawcalls Rekorde auch unter D3D aufstellt, und das hier eben sehr viel mehr für D3D optimiert wurde - nicht mehr und nicht weniger.

Allerdings hat auch AlphaTier Recht, ich würde mich hier nicht zu weit aus dem Fenster lehnen.

[Unicous]

Nö, es steht eine Behauptung im Raum, die durch eine, ich sage mal vorläufige Analyse einer Tech Demo entstanden ist, ohne Zugriff auf den Quell Code, ein zwei mal durch den Debugger laufen lassen und schon wissen wir wie dämlich doch Oxide Games ist und eigentlich nur AMD und Mantle gut aussehen lassen wollen.

Ich weiß ja nicht, wer die News auf der Startseite verb... geschrieben hat, aber alle Indizien und Antworten (Präsentation, diverse Interviews) der Star Swarm Entwickler deuten darauf hin, dass diese Tech Demo, nichts anderes ist, als eine Tech Demo. Es soll gezeigt werden, wozu die Engine in der Lage ist, und was sie mit Hilfe von Mantle alles herausholen können um die Draw Calls bzw. Batches zu erhöhen. Ich glaube niemand hat gesagt, dass das so in einem heutigen Spiel zu sehen sein wird.

Die Oxide Leute haben immer wieder darauf hingewiesen, wie es heutzutage aussieht und wo es mal hingehen könnte. All das wird aufs Schärfste kritisiert, als ob die Leute jedem in der Branche ans Bein pissen wollen weil ihre Lösung das Maß aller Dinge ist.

Dan Baker und Co. sind nicht so verbohrt , dass Mantle der Heilsbringer ist, sie wollen eine Diskussion starten und sehen einen Anhaltspunkt für bessere Leistung, mehr Drawcalls zuzulassen, anstatt krampfhaft zu versuchen sie minimieren.

Das wird hier und anderswo mE immer noch nicht verstanden.

Es geht um Denkanstöße. Sie wollen die Software und Spiele-Entwicklung wieder vorantreiben.
Wenn sie mit ihrem Vorstoß scheitern aber dennoch den Bremsklotz aus dem Getriebe stoßen, haben alle gewonnen.

Bis jetzt kam aus den anderen Lagern dahingehend wenig bis nichts. Auf einmal gibt es von Nvidia eine Präsentation bei den Steam Dev Days (die hier irgendwie untergegangen ist) über Draw Calls bei OpenGL.


Die Mantle-Proponenten sagen, sie wollten einen Neuanfang starten und nicht an OpenGL und DX xx rumdoktern. Warum?

Ganz einfach, weil Microsoft und Khronos viel zu verbohrt bzw. zerstritten sind. Die OpenxL-Entwicklung ist defacto auch stehen geblieben. Nvidia untersützt zwar offiziell immer die neuesten Versionen, aber sie drehen entweder ihr eigenes Ding (z.B. CUDA) oder versuchen das anders monetär zu verarbeiten.

AMD kümmert sich auch kaum und ist bei der Unterstützung von neuen Versionen meist mehrere Version im Hintertreffen (warum auch immer, großer *facepalm*). Intel holt zwar generell auf liegt aber weiterhin meilenweit zurück. Apple scheint sich da auch mit abgefunden zu haben, da kommen seit einer Weile auch keine großen Ideen mehr. Die anderen fokussieren sich auf "Internet", Browser extensions bzw. Android. Da kommt nichts bei rum.

Und den DirectX Zustand kann man ja an Nvidias Weigerung sehen, die Unterversionen vollständig zu unterstützen (auch da frage ich mich: Warum?).

Alles in allem eine ziemlich besch...eidene Situation.

[uweskw]

Ist doch klar. Ein Benchmark in dem NV durch exzessive Nutzung von Tesselation als Sieger hervorgeht ist ein technologischer Meilenstein und einer in dem AMD durch ebensolches mit DrawCalls vorn liegt ist Manipulation. Sagen uns doch alle Freaks und Medien. Is nun mal so!!

greetz
U.S.

[Langenscheiss]

Sehr geehrte Moderatoren,

ich möchte daran erinnern, dass das hier ein Technologie-Forum ist. Könntet ihr bitte dafür sorgen, dass nicht auch noch dieser Thread in sinnloses NV vs. AMD gebashe ausartet? Hier geht es doch einzig um die Technik von Star Swarm und darum, ob die Umsetzung sinnvoll ist oder nicht. Über potentielle Nvidia Marketing-Stunts kann man sich ja, wenn gewünscht, in einem anderen Thread unterhalten.

[Coda]

Nö, es steht eine Behauptung im Raum, die durch eine, ich sage mal vorläufige Analyse einer Tech Demo entstanden ist, ohne Zugriff auf den Quell Code, ein zwei mal durch den Debugger laufen lassen und schon wissen wir wie dämlich doch Oxide Games ist und eigentlich nur AMD und Mantle gut aussehen lassen wollen.
Mein lieber Unicous, es gibt hier in diesem Thread drei professionelle Engine-Programmierer, die alle der Meinung sind, dass Star Swarm mit DirectX nicht gerade effizient umgeht. Die Faktenlage ist sehr erdrückend. Ich brauche keinen Engine-Code sehen wenn sie einzelne Quads mit jeweils einem Draw-Call rendern.

Zum Rest deiner Analyse gehe ich nicht weiter ein, da das alles nur Hörensagen ist. An einer echten Diskussion bist du offensichtlich nicht interessiert. Du giftest hier jeden an, der es auch nur wagt Star Swarm zu kritisieren, weil du meinst wir wollen Mantle diskreditieren, obwohl es darum gar nicht geht.

[Gimmick]

Mein lieber Unicous, es gibt hier in diesem Thread drei professionelle Engine-Programmierer, die alle der Meinung sind, dass Star Swarm mit DirectX nicht gerade effizient umgeht. Die Faktenlage ist sehr erdrückend. Ich brauche keinen Engine-Code sehen wenn sie einzelne Quads mit jeweils einem Draw-Call rendern.


Ich frag mich da eher wie relevant das überhaupt ist.
Ist es nicht egal wie die Drawcalls zustande kommen wenn es nur darum geht das Verhalten der APIs mit einer bestimmten Menge davon zu zeigen?
Ist doch der selbe Weg wie bei fast allen Benchmarks und Techdemos. Da wird um irgendwas zu testen mit sonst was geklotzt, was auch in keinem Verhältnis zum optischen Ergebnis steht, Hauptsache der zu testende Teil wird voll in Anspruch genommen.

Von daher gehe ich mal davon aus, dass mit "Optimierungen" nicht gemeint war, dass man bei gewünschtem optischen Ergebnis auf optimale Performance hin optimiert hat, sondern, dass man versucht hat mit möglichst vielen Drawcalls möglichst effizient umzugehen.
Wenn man jetzt Methoden nutzt um die Zahl der Drawcalls wieder zu verringern ist ja irgendwie die ganze Sache an sich sinnfrei. Dann müsste man wahrscheinlich wirklich einen extremen optischen Detailgrad auffahren - mit eventuell/wahrscheinlich(?) dem selben Ergebnis, nur mit mehr Aufwand?

[Coda]

Dann hätten sie das aber auch so durchsagen sollen. Die Aussage war, dass sie auf Direct3D optimiert haben ("We have spent a huge amount of time optimising around D3D, and are biased in D3D's favor."), und das kann man eben aufgrund der Faktenlage nur sehr kritisch betrachten. Wenn sie das ernsthaft getan hätten, dann wäre Instancing eingesetzt worden.

Dass mit Mantle Draw-Calls erheblich billiger sind und man den ganzen Instancing-Kram evtl. gar nicht braucht bestreitet ja auch niemand. Nur ist die Realität halt im Moment, dass man Direct3D noch eine ganze Weile unterstützen muss und sowas gar nicht in Frage kommt. Und dann sind die Vorteile eben geringer (aber trotzdem beeindruckend im CPU-Limit wie man an BF4 sieht).

[Screemer]

quote für coda:

Das Problem ist das die Aussage aus dem Kontext gerissen wurde. Die Aussage bezieht sich auf die Drawcalls. Baker sagt das die Engine in Hinblick auf die Drawcalls Rekorde auch unter D3D aufstellt, und das hier eben sehr viel mehr für D3D optimiert wurde - nicht mehr und nicht weniger.

und nein ich werde mir das 60 minuten video nicht noch einmal ansehen. vielleicht kann da jemand aushelfen um die stelle zu ermitteln.

[StefanV]

Die Frage ist letztendlich:
WARUM hat man das gemacht? War das letztendlich Absicht, um ein Worst Case Szenario zu erstellen, um die Vorteile von Mantle besonders herausstellen zu können?

Und: Wird das in einem kaufbaren Spiel auch so sein oder ist das eine Designentscheidung für diese Demosoftware gewesen?

[Screemer]

sollte es ein spiel geben bei dem diese masse an drawcalls sinnvoll eingesetzt werden kann, dann denke ich schon das es auch bei diesem so aussehen würde. die "demo" zeigt halt den stand der dinge. ob es überhaupt einen sinnvollen weg gibt soviele drawcalls zu benutzen kann ich nicht einschätzen.

[Coda]

Solange es keine Standard-API gibt, die so einen geringen Overhead hat wird man weiterhin Direct3D unterstützen müssen und kann es sich schlicht nicht leisten einen großen Teil der Benutzerbasis zu vergraulen.

Das sich OpenGL nicht weiterentwickelt ist übrigens totaler Quatsch, da hat es in letzter Zeit so viel Bewegung gegeben wie schon lange nicht mehr, auch schon vor Mantle.

[ndrs]

Mal ein Gedanke eines Laien in den Raum geworfen:
Kann es vielleicht sein, dass die Aussage "Wir haben für D3D optimiert" nicht so verstanden werden sollte:
"Verglichen mit der erzeugte Darstellungsqualität benötigen wir sehr wenig CPU-Ressourcen", sondern eher so: "Verglichen mit der Menge an Drawcalls benötigen wir sehr wenig CPU-Ressourcen" oder anders ausgedrückt "Ein einzelner Drawcall läuft sehr effizient" ?

Das könnte vielleicht die ansonsten eher unglaubwürdige Aussage in einem anderen Licht darstellen. Was meinen die Profis? Wäre das denkbar? Geht das überhaupt, also gibt es einen Unterschied zwischen "einen Drawcall absetzen" und "einen Drawcall besonders effizient abzusetzen"?

[OBrian]

wenn das eine Techdemo für die Engine ist, dann gibt es sicher viele Dinge in der Engine, die für ein in der Entwicklung befindliches Spiel nötig bzw. vorteilhaft sind, in dieser Demo aber sinnlos oder kontraproduktiv erscheinen.

Beispielsweise sind diese vielen kleinen Raumschiffe ja alle irgendwie recht ähnlich und logisch wohl sehr dumm programmiert. Aber stellen wir uns doch mal vor, das wäre ein MMORPG im Weltraumsetting und ein Haufen menschlicher Spieler würde da mit customisierten Schiffen rumfliegen (sagen wir einige hundert Leute, jeder mit einer gehörigen Handvoll von ihm gesteuerter Schiffe oder sowas). Wäre es dann ggf. sinnvoller, so zu programmieren? Oder unter welchen anderen Bedingungen würde das Sinn machen?

Ich meine, in einer Demo Mantle besser aussehen zu lassen, weil man Geld dafür kriegt, mag ja noch denkbar sein, aber Mantle an sich muß ja eine Berechtigung haben. Und der Anstoß zu Mantle kommt ja offensichtlich aus der Spieleentwicklerecke, es ist nicht wie so oft ein Feature, das einem Hardwarehersteller eingefallen ist und das nun irgendwie promotet werden muß. Tesselation ist dafür ein gutes Beispiel, schon zu Zeiten der Radeon 8500 gabs eine "ganz tolle" Hardwaretesselationseinheit, die Anwendungsbeispiele dafür waren alle irgendwie recht dämlich und sinnlos, ich erinnere mal an Counterstrike mit abgerundeten Glock-Pistolen usw. Ist dann in die Shader gewandert, auf der Fähigkeit wurde und wird bis heute drauf rumgeritten, zuletzt wieder durch Nvidia, weil sie da in einer Generation mal mehr oder weniger zufällig enorm besser waren, also muß das promotet werden. Aber irgendwie scheint mir das gar nicht das zu sein, worauf die Entwickler gewartet haben.

[Knuddelbearli]

Mal ein Gedanke eines Laien in den Raum geworfen:
Kann es vielleicht sein, dass die Aussage "Wir haben für D3D optimiert" nicht so verstanden werden sollte:
"Verglichen mit der erzeugte Darstellungsqualität benötigen wir sehr wenig CPU-Ressourcen", sondern eher so: "Verglichen mit der Menge an Drawcalls benötigen wir sehr wenig CPU-Ressourcen" oder anders ausgedrückt "Ein einzelner Drawcall läuft sehr effizient" ?

Das könnte vielleicht die ansonsten eher unglaubwürdige Aussage in einem anderen Licht darstellen. Was meinen die Profis? Wäre das denkbar? Geht das überhaupt, also gibt es einen Unterschied zwischen "einen Drawcall absetzen" und "einen Drawcall besonders effizient abzusetzen"?


So habe ich es auch verstanden, PR hin oder her er wird ja niemals direkt und offensichtlich Lügen.

[Demirug]

Beispielsweise sind diese vielen kleinen Raumschiffe ja alle irgendwie recht ähnlich und logisch wohl sehr dumm programmiert. Aber stellen wir uns doch mal vor, das wäre ein MMORPG im Weltraumsetting und ein Haufen menschlicher Spieler würde da mit customisierten Schiffen rumfliegen (sagen wir einige hundert Leute, jeder mit einer gehörigen Handvoll von ihm gesteuerter Schiffe oder sowas). Wäre es dann ggf. sinnvoller, so zu programmieren? Oder unter welchen anderen Bedingungen würde das Sinn machen?

Es macht dann Sinn wenn die Datenmenge pro Instance so groß wird das man sie mit der API nicht mehr handeln kann. Das war bei DirectX 9 noch ein großes Problem. Inzwischen aber nicht mehr. Das Variationproblem kann man heute mit entsprechend großen Constantbufferrs und Texture-Arrays lösen.

Ein Drawcall pro Objekt ist nur dann der einzige Weg wenn wirklich jedes Objekt eine komplett eigene Geometry hat. Das wird bei einem Spiel aber die Content Erstellung nicht stemmen können. Und selbst in diesem Fall ist der erste Pass bei dem die Texture beleuchtet werden nach wie vor das klassische Beispiel bei dem man die ganzen Quads in einen oder einige wenige Drawcalls packt.

[fdk]

Das Gesamtpaket passt perfekt zu Brad Wardell und seinem Selbstverständnis als CEO von Stardock. Die Order an Oxide war dann wohl auch einfach "Get results".

Free publicity, yay.

[Unicous]

Es gibt jetzt einen Artikel bei PCGH. Zufall?:freak:


http://www.pcgameshardware.de/Benchmarks-Thema-58180/News/Mantle-Techdemo-Star-Swarm-CPU-Calls-1110690/


Ich schätze aber es ist nur ein Klickartikel. Denn, das Oxide für einen Kommentar angefragt wurde lese ich nicht. Schade.

[Coda]

Die Presse könnte tatsächlich ruhig mal nachfragen, das ist ihre Aufgabe kritisch zu sein. Zuvor hat sie das nicht erfüllt. Da wurde ein Benchmark gemacht, das Ergebnis abgedruckt und fertig.

[Gipsel]

So, mal gründlich durchgewischt. Bitte bleibt beim Thema und bei einer angemessenen Form!

Danke.

[Leonidas]

Auch auf der Startseite könnte ich wesentlich besser schreiben, wenn in diesem Thread die Diskussion zum Thema und nicht über eure Meinungen selber geführt werden würde. Bleibt bitte beim Thema! Wie soll ich die Essenz eines solchen Threads auf der Startseite formulieren, wenn man sich hier nur gegenseitig anblökt?!

[Hübie]

Wie wäre es wenn du mal bei Oxide oder wie die heißen nachfragst warum die sich dazu entschieden haben absurd viele drawcalls aufzurufen? Vielleicht antworten die ja einfach mal ehrlich dass die lediglich das Potenzial darstellen bzw. herausstellen wollten.
Vielleicht habe die intern eine echte für D3D optimierte Version? Ich mein wenn man beim kompilieren schon vergisst den Haken bei "multithreading" zu setzen kann es vielleicht auch aus versehen passiert sein dass man die unoptimierte Version mit herausgegeben hat ;D
Ich bin jetzt einfach mal dreist dass so gewollt zu formulieren.

[Leonidas]

Ich denke nicht, daß man von Firmen ehrliche bzw. verwertbare Antworten zu heiklen Themen bekommt.

[Iruwen]

Kommt drauf an obs um Geld geht, und wenn ja wieviel :cool:

[aths]

Ich denke nicht, daß man von Firmen ehrliche bzw. verwertbare Antworten zu heiklen Themen bekommt.
Auf der anderen Seite wäre es journalistisch geboten, nachzufragen. Solange man ein mögliches Statement der Firma nicht kommentiert mit "Ist totaler Quatsch!", kann man sich keinen Sensationsjournalismus vorwerfen lassen.

Leider ist damit zu rechnen, dass die Firma ein komplexes Statement abgibt dass man fachlich nicht durchschaut. Hier erinnere ich mich an ATIs Erklär-Taktik in Bezug auf die Winkelabhängigkeit des anisotropen Filters: Die Antwort ging nicht speziell auf die Winkelabhängigkeit, sondern auf die allgemeine adaptive AF-Level-Auswahl je nach Verzerrungsfaktor ein. Vielleicht ließe sich Demirug überreden, ein mögliches Statement der Firma zum Thema D3D vs Mantle zu kommentieren. Falls er sich nicht öffentlich auf der Hauptseite wiederfinden möchte, könntest du allgemein von gutunterrichteten Kreisen beziehungsweise Experten sprechen.

[del_4901]

So nachdem ich den ganzen Abend UE4 durch den GPU Debugger gejagt habe, dachte ich mir ist es ist doch mal ne gute Gelegenheit um sich StarSwarm anzusehen.

Was mir dabei aufgefallen ist:
Sie machen das Shading im Texture Space, und sind dabei non persistent. Der Vorteil ist, dass die Shading Aufloesung von der Window-Aufloesung getrennt ist. Sprich sie machen das jeden Frame, im CB0 speichern sie dafuer alle Daten ueber das Objekt und die Position im ShadingCache. CB3 liefert daten fuer das Shading selber.
Meine Frage war warum sind Sie dabei non persistent und entkoppeln nicht gleich auch die ShadingFrequenz von der Framerate? Warscheinlich weil man zuviel Platz braucht um alles gleichzeitig in den Cache zu
bekommen. Und es ist warscheinlich zu kompiziert eine gute Replacement-Strategie oder unique mapping zu finden. Zumal die Objekte alle unterschiedliche Groessen im ShadingCache belegen koennen.

Es wird jedenfalls grosser Aufwand betrieben die Objekte nach Shader zu sortieren.
Warum instanced man dann nicht gleich auch die Objekte? Das ist die Frage die Demi und Coda stellen.

Was mir dabei aufgefallen ist:
1) Jeder Frame ist unterschiedlich das Culling ist sehr genau. deswegen aendert sich der ShadingCache auch mit jedem Frame.
2) CB0 aendert sich eigentlich immer. CB3 eher selten. Man koennte das ueber einen dynamic Buffer loesen. ABER zum einen wird man dann evtl. Fetch bound. Und zum anderen wird der Buffer dann ziehmlich gross und muss auch jeden Frame geuploaded werden (allein wenn sich die Kamera/Licht aendert). Um mal Nick zu zitieren: "The default “rename” memory size for DYNAMIC buffer on current GCN drivers is 8 MB, which means that contention on a 4MB buffer can be avoided at least once. If a DYNAMIC buffer is larger than 4 MB then a Map() DISCARD operation on this buffer will introduce a synchronization between CPU and GPU which is bad news for performance."
3) Texturen aendern sich mittel haeufig, man koennte die jetzt alle in ein TexturArray stecken. Aber da gibt es auch Groessen Limitierungen. Und da jeden Frame das Array neu zusammen zu stellen, ist auch schlecht fuer die Performance. Vorallem haben die Texturen unterschiedliche Groessen und Formate, man braucht also auch mehrere Arrays. Bindless Textures wuerden hier viel helfen.

Bei dem Aufwand der berieben wurde um die Batches zu sortieren, denke ich man hat sich schon Gedanken gemacht was sich alles instancen laesst. Es dann aber wegen Design Requirements oder sogar schlechterer Performance wieder verworfen hat.

[M4xw0lf]

Fazit: was Oxide da macht ist kein reiner Unsinn um Mantle möglichst gut zur Geltung zu bringen?

[del_4901]

Fazit: was Oxide da macht ist kein reiner Unsinn um Mantle möglichst gut zur Geltung zu bringen?Die machen halt mit ihrer Engine pioneering R&D, klar das man da mit seinen Resourcen haushalten muss. Die Hardware oder APi sind einfach mit dem Use-Case noch nicht vertraut. Ich kann jedenfalls keinen offensichtlich eindeutigen und schluessigen Grund erkennen dass man Dx in einem besonders schlechten Licht dastehen lassen will. Es gibt gute Gruende die fuer so ein Design sprechen, wie es auch Gruende dagegen gibt.