Re: Anti-Jammer-Thread
Verfasst: 11.04.2013, 00:09
in der Tat...
ZFX + Developia
Die deutsche Spieleentwickler-Community (seit 1999).
https://zfx.info/
Anti-Jammer-Thread
Seite 33 von 70
Re: Anti-Jammer-Thread
Verfasst: 11.04.2013, 14:53
Ich habe soeben mit dem eigenen Headset ein Kotzgeräusch eingesungen. Das ist für eine winzige Nebenhandlung im letzten Splatter-Level und erstmal nur als Platzhalter gedacht, der vielleicht oder vielleicht auch nicht vom Sounder durch was "Richtiges" ersetzt wird. Absurder Mist... Ich mag meinen Job :-)
Re: Anti-Jammer-Thread
Verfasst: 12.04.2013, 12:30
Wie hast du den Würgreiz provoziert ? ;)Schrompf hat geschrieben:Ich habe soeben mit dem eigenen Headset ein Kotzgeräusch eingesungen.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 02:36
Der Ausdruck "-100 * (90000 / (90000 + distance2(vec2(0, 0), vec2(x, z)))) + y + 90"
wird jetzt von unserem Expressionsystem aus einem String in eine Zwischen-Bytecode-Repräsentation gebracht und dann per AsmJit auf nativen Code plattformunabhängig jit-kompiliert.
Es sind noch bestimmt 50% der Anweisungen unnötige movs, trotzdem braucht eine Auswertung nur noch 15ns. Zum Vergleich: nativer gcc Code für diesen Ausdruck braucht 19ns, die Auswertung des Zwischen-Bytecodes (quasi Interpretation) braucht 1027ns.
wird jetzt von unserem Expressionsystem aus einem String in eine Zwischen-Bytecode-Repräsentation gebracht und dann per AsmJit auf nativen Code plattformunabhängig jit-kompiliert.
Es sind noch bestimmt 50% der Anweisungen unnötige movs, trotzdem braucht eine Auswertung nur noch 15ns. Zum Vergleich: nativer gcc Code für diesen Ausdruck braucht 19ns, die Auswertung des Zwischen-Bytecodes (quasi Interpretation) braucht 1027ns.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 12:43
Hervorragend! Aber was generiert gcc da für Code? Probleme mit Aliasing?Artificial Mind hat geschrieben:Es sind noch bestimmt 50% der Anweisungen unnötige movs, trotzdem braucht eine Auswertung nur noch 15ns. Zum Vergleich: nativer gcc Code für diesen Ausdruck braucht 19ns, die Auswertung des Zwischen-Bytecodes (quasi Interpretation) braucht 1027ns.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 12:47
Wir haben mal den Code verglichen, der gcc lädt noch relativ viel aus dem Ram (sowas wie Konstanten) und außerdem springt er noch recht wild zwischen GPR, x87-Registern und XMM-Registern umher. Wir haben eigentlich komplett XMM (auch wenn wir nur den ss-Modus nutzen) und ganz selten mal GPR (z. B. für die sign-Funktion)
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 16:48
Ich habe das auch mal ausprobiert.
Ein Teil der Instruktionslast bei euch im GCC liegt wohl daran, dass ihr die Datenfelder vom vec2 nicht an für SSE-Instruktionen genehmen Grenzen ausrichtet. Wenn man das Alignment einstellt, kommt schon erheblich besserer Text raus, aber immer noch nicht optimaler.
Wenn man das wohl vollständig optimieren möchte, muss man wohl so etwas wie die DirectXMath machen, und sich einen XMVECTOR-Vektor bauen, welcher direkt die Daten in SSE-Registern vorhält.
Ein Teil der Instruktionslast bei euch im GCC liegt wohl daran, dass ihr die Datenfelder vom vec2 nicht an für SSE-Instruktionen genehmen Grenzen ausrichtet. Wenn man das Alignment einstellt, kommt schon erheblich besserer Text raus, aber immer noch nicht optimaler.
Wenn man das wohl vollständig optimieren möchte, muss man wohl so etwas wie die DirectXMath machen, und sich einen XMVECTOR-Vektor bauen, welcher direkt die Daten in SSE-Registern vorhält.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 17:00
Wir generieren ja unsere SSE-Instruktionen jetzt selbst, also brauchen wir das gcc-Verhalten gar nicht optimieren. Der richtig performancekritische Teil ist die Terrain-Generierung und dort wird unser jitting genutzt. Wenn das jitting komplett funktioniert fangen wir mit statischer Analyse an. Instruction-level constant folding, reaching definitions analysis auf unserem Bytecode. Dann wahrscheinlich nochmal eigene Registerallokation inklusive mov-Optimierung auf dem SSE-Code, danach vektorisieren der SSE-Instructions (momentan nutzen wir halt nur "ss", aber wenn man das "ps" mindestens zur Hälfte ausgelastet bekäme wäre das schon cool). Am Ende Instruction Reordering fürs SSE-pairing.
Viel mehr können wir dann nicht mehr machen, oder?
(Abgesehen von noch mehr statischer Analyse auf unserem Zwischencode ;) )
NACHTRAG: Das ist unser momentaner SSE-Code für den Ausdruck von oben: http://pastebin.com/VtB43DUY (btw: distance2 ist ohne sqrt, das "2" steht für Quadrat. Sqrt selber würden wir einfach mit einer SSE-Instruktion machen.)
Viel mehr können wir dann nicht mehr machen, oder?
(Abgesehen von noch mehr statischer Analyse auf unserem Zwischencode ;) )
NACHTRAG: Das ist unser momentaner SSE-Code für den Ausdruck von oben: http://pastebin.com/VtB43DUY (btw: distance2 ist ohne sqrt, das "2" steht für Quadrat. Sqrt selber würden wir einfach mit einer SSE-Instruktion machen.)
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 17:38
Ich sehe gerade, dass die test-Funktionen aus meinem Quelltext oben gar keine calls generieren; eine jede der test-Funktionen sieht tatsächlich optimal optimiert aus (ja, lacht nur).
Ich habe mich eigentlich an dem hier gewundert:
Ich meine, ohne sqrt gibt euch der GCC:Und da ist meiner Meinung nach so ziemlich das Ende der Fahnenstange erreicht.
Ich habe mich eigentlich an dem hier gewundert:
Wenn aber der GCC für solchen oder vergleichbaren Quelltext (wie wir nun gesehen haben) so guten Text produziert; wie unglaublich gut ist dann euer Text, als dass er noch einmal 4 ns schneller ist? Ich wüsste einfach nicht, was man noch optimieren sollte.Artificial Mind hat geschrieben:Es sind noch bestimmt 50% der Anweisungen unnötige movs, trotzdem braucht eine Auswertung nur noch 15ns. Zum Vergleich: nativer gcc Code für diesen Ausdruck braucht 19ns
Ich meine, ohne sqrt gibt euch der GCC:
Code: Alles auswählen
test(float, float, float):
movss xmm3, DWORD PTR .LC0[rip]
addss xmm1, DWORD PTR .LC1[rip]
xorps xmm2, xmm3
mulss xmm2, xmm2
mulss xmm0, xmm0
addss xmm2, DWORD PTR .LC2[rip]
addss xmm2, xmm0
movss xmm0, DWORD PTR .LC3[rip]
divss xmm0, xmm2
addss xmm1, xmm0
movaps xmm0, xmm1
ret
.LC0:
.long 2147483648
.long 0
.long 0
.long 0
.LC1:
.long 1119092736
.LC2:
.long 1202702336
.LC3:
.long 3406386240
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 17:49
Die 19ns waren ohne volle Optimierung vom gcc, deswegen ist das noch etwas geschummelt: http://pastebin.com/crqAzQjC
Die vec2-Arithmetik ist aus der glm Lib, da müsste man nochmal gucken inwieweit die geinlined wird im Release build.
Der test3-Text aus deinem Link sieht ziemlich optimal aus, beim Pairing bin ich mir noch etwas unsicher (auch inwieweit man da wirklich drauf achten muss bei out-of-order execution).
Und ich steck auch noch nicht tief genug in SSE drin um zu beurteilen was die beste Art ist, Konstanten in xmm-Register zu bekommen.
Die vec2-Arithmetik ist aus der glm Lib, da müsste man nochmal gucken inwieweit die geinlined wird im Release build.
Der test3-Text aus deinem Link sieht ziemlich optimal aus, beim Pairing bin ich mir noch etwas unsicher (auch inwieweit man da wirklich drauf achten muss bei out-of-order execution).
Und ich steck auch noch nicht tief genug in SSE drin um zu beurteilen was die beste Art ist, Konstanten in xmm-Register zu bekommen.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 20:56
Mich würde interessieren, was ihr da treibt? Warum jittet ihr überhaupt? Dass ihr den Compiler damit überholt, halte ich für völlig ausgeschlossen. Ich bin da von vornherein von einem Fehler ausgegangen. Und gegen gcc im Debug Build zu vergleichen ist ja eigentlich nur ein Fehler.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 21:21
Unser Terrain basiert ja auf einer impliziten Funktion. Dies soll aber nachher durch Modder gegeben werden und kann beliebig aussehen. Also haben wir ein Node-Expression-System (vergleichbar mit Blender Nodes nur noch nicht so hübsch mit GUI) das auch noch Nodes für beliebige Ausdrücke bereitstellt, als Strings. Punkt ist: dieses System wir für das Terrain millionenmal ausgewertet. Verstehst du nun, warum wir jitten müssen? Der GCC-Vergleich ist auch nur "ground truth", wir könnten es nicht mal damit kompilieren wenn wir es wollten (muss ja portabel sein und man will seinen Spielern ja auch nicht zumuten gcc installiert zu haben).Schrompf hat geschrieben:Mich würde interessieren, was ihr da treibt? Warum jittet ihr überhaupt? Dass ihr den Compiler damit überholt, halte ich für völlig ausgeschlossen. Ich bin da von vornherein von einem Fehler ausgegangen. Und gegen gcc im Debug Build zu vergleichen ist ja eigentlich nur ein Fehler.
gcc im Debug ist quasi die Mindestqualität (guck dir http://pastebin.com/crqAzQjC an. Soo schlimm ist es nicht, auch wenn es natürlich ziemlich weit von optimal entfernt ist).
Andersherum ist gcc 4.8 mit O3 und fast-math auch etwas sehr hoch gegriffen, ist aber ein guter Wert für das was erreichbar ist. gcc 4.6 mit O1 würde ich als realistischer einschätzen.
Wenn du dir unseren Code anguckst dann sind wir bereits jetzt (mit "naiver" Kompilation) gar nicht so weit weg von was brauchbarem.
Naja TL;DR: Die Ausdrücke sind User-Input, werden aber millionenfach ausgewertet => JIT.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 22:09
Glaub ich Dir ja, keine Sorge. Ich war primär neugierig, wofür Du eine JIT brauchst. Und ich wollte halt nicht so recht glauben, dass Du damit den GCC schlagen kannst. Ich kenne mich nur mit dem VC++-Compiler aus, aber bei dem ist zwischen Debug und Release ungefähr Faktor 20 an Unterschied. Sprich: der Debug-Build ist wirklich mit einem JIT erreichbar, der Release dagegen... glaube ich nicht. Daher mein Interesse.
Re: Anti-Jammer-Thread
Verfasst: 13.04.2013, 22:23
Tschuldigung wenn ich etwas negativ klang, war nicht so gemeint. Bei GCC ist der Unterschied zwischen Release und Debug nur ca. 3 bis 5, bei VC++ ist der auch nicht so groß wenn man kein Iteratordebugging hat. (Trivia: Unser Projekt läuft auf meiner Monster-CPU mit VC11 im Release auf 200fps, mit VC11 im Debug auf 5fps - STL)
Ich bin zuversichtlich dass wir im Endeffekt (nach unseren Optimierungen) verdammt nah an die Release-Performance drankommen, da wir ja nur ein sehr kleines Subset an Features nutzen. Zum Beispiel gibt es bei uns weder Pointer noch Aliasing noch structs noch ints noch benutzerdefinierte Schleifen, es sind im Grunde nur arithmetische Ausdrücke die auf beliebigdimensionalen float-Tensoren arbeiten. Die Tensoren haben statische Typisierung und werden beim Kompilieren ausgerollt, danach bleiben nur noch float-Instruktionen über. Das Problem ist damit echt überschaubar. Sobald das System komplett läuft (momentan hängen wir an einer "Illegal Instruction" innerhalb eines 40k Instruction Ausdrucks ;) ) kann ich ja weiter berichten. Wenn wir auf Faktor 2 oder 3 an Release rankommen würde mir das sogar schon reichen.
Ich bin zuversichtlich dass wir im Endeffekt (nach unseren Optimierungen) verdammt nah an die Release-Performance drankommen, da wir ja nur ein sehr kleines Subset an Features nutzen. Zum Beispiel gibt es bei uns weder Pointer noch Aliasing noch structs noch ints noch benutzerdefinierte Schleifen, es sind im Grunde nur arithmetische Ausdrücke die auf beliebigdimensionalen float-Tensoren arbeiten. Die Tensoren haben statische Typisierung und werden beim Kompilieren ausgerollt, danach bleiben nur noch float-Instruktionen über. Das Problem ist damit echt überschaubar. Sobald das System komplett läuft (momentan hängen wir an einer "Illegal Instruction" innerhalb eines 40k Instruction Ausdrucks ;) ) kann ich ja weiter berichten. Wenn wir auf Faktor 2 oder 3 an Release rankommen würde mir das sogar schon reichen.
Re: Anti-Jammer-Thread
Verfasst: 14.04.2013, 00:15
So, gibt neue Ergebnisse für den obigen Ausdruck:
Unser JIT: 11ns
GCC 4.7 im Release: 10ns
Der Test ist ungefähr so aufgebaut: GCC Explorer
(Die Random-Aufrufe werden nochmal separat gemessen und danach rausgerechnet)
Ich denke damit sind wir im Bereich wo der Ram-Zugriff der limitierende Faktor ist. Bin zufrieden für heute.
Unser JIT: 11ns
GCC 4.7 im Release: 10ns
Der Test ist ungefähr so aufgebaut: GCC Explorer
(Die Random-Aufrufe werden nochmal separat gemessen und danach rausgerechnet)
Ich denke damit sind wir im Bereich wo der Ram-Zugriff der limitierende Faktor ist. Bin zufrieden für heute.
Re: Anti-Jammer-Thread
Verfasst: 17.04.2013, 00:19
Mein Font-Renderer hat Leerzeichen zum Zeichnen geschickt. Schön, dass ich nach so vielen Monaten immernoch kleine Verbesserungsmöglichkeiten finde.
Re: Anti-Jammer-Thread
Verfasst: 18.04.2013, 19:09
Sooo. Ich habe heute einen Prototypen hingehackt und ins nächste Projekt kommt das definitiv rein – dann werden Renderer, Dateisystem, Eingabesystem, und Klangausgabe nebenläufig initialisiert. Und alles, was ich sonst noch so finde. Mit RAII ist nichts kollidiert; es sind „normale“ globale Variablen und für den Rest des Programms sieht ihre Lebenszeit normal aus.Krishty hat geschrieben:Ich überlge, in meiner CRT bestimmte globale Variablen in eigenen Threads zu initialisieren. Anstatt dass so seriell Dateien geöffnet, Registry gelesen, und GPU-Kontext angefordert wird, geschähe das zumindest auf Makroebene parallel. Die entsprechenden Variablen wären speziell markiert.
Ich frage mich, inwieweit das überhaupt was bringen würde. Weil Windows außer dem GPU-Kontext alles cachet, ist der wahrscheinlich die eine einzige langsame Sache auf die letztendlich alles andere warten würde. Außerdem würde es RAII an sich in Frage stellen.
Ich hasse es, wenn Programme nicht sofort auf dem Bildschirm erscheinen.
Re: Anti-Jammer-Thread
Verfasst: 18.04.2013, 20:51
Ja, da bin ich mit Dir. Schön, dass es so einfach ging!
Re: Anti-Jammer-Thread
Verfasst: 19.04.2013, 08:00
Als ich heute morgen meinen PC aus dem Stand-By geweckt habe, war mein Spiel automatisch pausiert. So Malheurs wie, dass mittendrin der Bildschirmschoner anspringt (weil Windows dafür nur Tastatur- und Mauseingaben kontrolliert; aber nicht Joysticks und Lenkräder), habe ich ebenfalls ausgeschlossen.
Vielleicht poste ich dieses Wochenende eine kurze Zusammenfassung der ganzen Energieverwaltung; ich weiß nur nicht, ob sich mit Windows RT und dem ganzen Windows 8-Kram irgendwas zu stark geändert hat …
Vielleicht poste ich dieses Wochenende eine kurze Zusammenfassung der ganzen Energieverwaltung; ich weiß nur nicht, ob sich mit Windows RT und dem ganzen Windows 8-Kram irgendwas zu stark geändert hat …
Re: Anti-Jammer-Thread
Verfasst: 20.04.2013, 17:43
C++14 Best Of
Nebenbei ist clang soeben C++11-complete geworden. Das entsprechende Release wird im Sommer erwartet.Stefanus Du Toit hat geschrieben:Abgenickt:Zur Debatte?
- Variable templates ala "template <typename T> int foo<T> = ..."
- Run-time sized arrays on the stack got in as well. Very mild controversy there, but in the end it was pretty much unanimous.
- Third controversial issue, std::dynarray, got voted in as well.
- "auto f(int i) { if (i < 1) return 1; else return f(i-1) * i; }" will likely be valid C++14
- C++14 will also likely include binary literals like 0b101010. Maybe we should call it C++0b1110?
Re: Anti-Jammer-Thread
Verfasst: 20.04.2013, 17:48
C++14
Run-time sized arrays on the stack got in as well.
Re: Anti-Jammer-Thread
Verfasst: 20.04.2013, 23:50
Ich habe jetzt meinen eigenen funktionierenden C++11-kompatiblen Preprozessor fertig geschrieben. Berechnet auch direkt die Byterepräsentationen aller ppNumber- und String/Char-Literale (auch user defined strings/chars).
Auf meinem Weg zum eigenen C++11-Kompiler steht also wahrscheinlich als nächstes die C++-Syntax-Analyse an. Ich freu mich schon :)
Auf meinem Weg zum eigenen C++11-Kompiler steht also wahrscheinlich als nächstes die C++-Syntax-Analyse an. Ich freu mich schon :)
Re: Anti-Jammer-Thread
Verfasst: 22.04.2013, 13:01
Pff, ich seh's schon kommen. Leute werden Benutzereingaben ohne Längenbegrenzung so auf dem Stack speichern und sich dann über DoS Attacken wundern. Vielleicht sogar Sicherheitslücken, wenn das Programm irgendwie versucht Stack Overflow Exceptions zu recovern.Run-time sized arrays on the stack got in as well.
Re: Anti-Jammer-Thread
Verfasst: 22.04.2013, 14:01
Bin nicht ganz sicher, ob das Material für den Jammer-Thread oder für Anti-Jammer ist. Ich habe gerade einen Bug im Splatter-Lichtshader gefixt, bei dem die fiktive Höhe eines Pixels nur für die Schattenberechnung, aber nicht für Attenuation und die Spotlight Cone verwendet wurde. Der Fix hat das komplette Erscheinungsbild des Spiels subtil verändert. Manche Dinge sehen jetzt einfach nur "richtig" aus, andere dagegen sehen jetzt aus wie reinkopiert.
Leider ist die Erstellung ordentlicher Relief Maps zu allen Grafiken eine ziemlich mühsame Arbeit, die sich mein Grafiker größtenteils erspart hat. Bisher hat man das nur an den bisweilen seltsamen Schatten-Silhouetten gesehen, die bei uns ja eh relativ weichgezeichnet erscheinen. Jetzt sieht man es aber auch im Licht jedes Scheinwerfers, dass die Höhen nur wie in einem billigen NormalMap-Generator aus der Farbtextur abgeleitet wurden.
Nuja, ich muss eh vor Release nochmal über alle Grafiken drüber. Das ist dann nur ein weiterer Posten auf der ewig wachsenden Liste.
[Edit] Damit das noch etwas anti-jammeriger klingt: Das letzte Level ist fertig, inklusive Musikdynamik, Speicherpunkten und allen Dialogen und Verzweigungen. Es ist noch nicht sonderlich hübsch, weil es noch vom Grafiker aufpoliert wird, aber es funktioniert und hat ein paar coole Szenen. Und inzwischen habe ich auch ein grobes Konzept für den Bosskampf entwickelt und bastle gerade fröhlich an der ersten Phase des Kampfes.
Leider ist die Erstellung ordentlicher Relief Maps zu allen Grafiken eine ziemlich mühsame Arbeit, die sich mein Grafiker größtenteils erspart hat. Bisher hat man das nur an den bisweilen seltsamen Schatten-Silhouetten gesehen, die bei uns ja eh relativ weichgezeichnet erscheinen. Jetzt sieht man es aber auch im Licht jedes Scheinwerfers, dass die Höhen nur wie in einem billigen NormalMap-Generator aus der Farbtextur abgeleitet wurden.
Nuja, ich muss eh vor Release nochmal über alle Grafiken drüber. Das ist dann nur ein weiterer Posten auf der ewig wachsenden Liste.
[Edit] Damit das noch etwas anti-jammeriger klingt: Das letzte Level ist fertig, inklusive Musikdynamik, Speicherpunkten und allen Dialogen und Verzweigungen. Es ist noch nicht sonderlich hübsch, weil es noch vom Grafiker aufpoliert wird, aber es funktioniert und hat ein paar coole Szenen. Und inzwischen habe ich auch ein grobes Konzept für den Bosskampf entwickelt und bastle gerade fröhlich an der ersten Phase des Kampfes.
Re: Anti-Jammer-Thread
Verfasst: 24.04.2013, 09:28
Innerhalb einer Woche das neue Haus gestrichen und teil-tapeziert, umgezogen, die alte Wohnung renovieren lassen und über die Hälfte aller Kisten verstaut. Und nun wieder arbeiten. Sprich: ich sehe gerade mal keine neue Kiste :).
Guß Kimmi
Guß Kimmi
Re: Anti-Jammer-Thread
Verfasst: 25.04.2013, 00:54
Visual C++ erkennt mit /fp:precise, dass sich -x + y zu y - x optimieren lässt. Das ist … überraschend und beruhigend. Ich hatte die Hoffnung längst aufgegeben …
Re: Anti-Jammer-Thread
Verfasst: 25.04.2013, 21:07
Irgendjemand hat Videos von den ersten 8 Levels von Entropy auf Youtube gepostet (in der Xbox-Fassung, mit entsprechender Qualitaet). Irgendwie komisch das zu sehen, aber durchaus spassig :-)
Ich glaube, danach hat er aufgegeben.
[youtube]7JEOv5lanmM[/youtube]
Ich glaube, danach hat er aufgegeben.
[youtube]7JEOv5lanmM[/youtube]
Re: Anti-Jammer-Thread
Verfasst: 02.05.2013, 20:56
Hehe, zumindest ich hab mich da wieder gefunden. :D
Re: Anti-Jammer-Thread
Verfasst: 02.05.2013, 22:04
Großartig!
Re: Anti-Jammer-Thread
Verfasst: 03.05.2013, 11:42
Wie wahr :) ...