ZFX + Developia

Ich lass' das hier einfach mal so stehen. Es hat mich heute fünf Stunden meines Lebens gekostet.

*sigh*
Erinnert mich daran, dass ich heute meinen ersten(!) Kontakt zu Windows’ Command-Shell hatte. Jemand hat einen ganz ganz ganz tollen Archiver geschrieben, der aber leider nur in einem Prozess laufen kann, weil sich sonst die temporären Dateien gegenseitig überschreiben. Also habe ich eine Stapelverarbeitungsdatei geschrieben
versucht, eine Stapelverarbeitungsdatei zu schreiben
eine Stapelverarbeitungsdatei zusammengeklaut, die den Temp-Pfad für einen Prozess zu einem Ordner zufälligen Namens umleitet.

Wäre ich 1972 geboren, wäre ich da total gut drin und mein Kopf so groß wie von den Außerirdischen in Mars Attacks – jedenfalls bis zu dem Punkt, an dem ich vor Hass einen nuklearen Holocaust provoziert hätte.
Nun bin ich aber in die Zeit der GUIs reingeboren, darum fühlt sich mein Kopf jetzt bloß so dick an und die Welt hat auch nicht mehr so viele Atomsprengköpfe wie über einer Rasse, die sowas wie die Command Shell geboren hat, eigentlich niedergehen sollten.

Krishty hat geschrieben:... und die Welt hat auch nicht mehr so viele Atomsprengköpfe wie über einer Rasse, die sowas wie die Command Shell geboren hat, eigentlich niedergehen sollten.

Ich habe gehört, dass Giftgas auch gehen soll. Ansonsten halt selber bauen. Achja die Command Shell ist schon was tolles. Aber man kann auch viel Freude mit der Bash haben. Gerade ebend habe ich nen Ordner kopiert, umbenannt und darin mit "rm *.cxx" alle cxx files gelöscht, weil da teilweise anderer Code rein soll. Dann brauchte ich noch ne zweite Kopie und bin zurück in den Ausgangsordner. Und daahaaan war ich total clever und wollte den Copy-Befehl nochmals ausführen. Also Cursor-Up gedrückt und schnell bestätigen. Und daahaaan... hmm da war doch was mit "rm *.cxx"... omg ... neeeein ... bitte nicht ... scheiße ... Ich könnt kotzen, zumal das meiste noch nicht im git liegt. :(

BeRsErKeR hat geschrieben:Ansonsten halt selber bauen.

Geht nicht; irgendwie gehen meine Zentrifugen dauernd kaputt.

Gibt's schon irgendeine offzielle Antwort auf den Ausfall? Wenn ZFX offline ist, arbeitet man direkt 250 % effektiver -- das muss sofort unterbunden werden. ;)

Die Moderatoren wissen nicht mehr als wir und die Administratoren sind momentan unterwegs.

so ist es - jedenfalls meinerseits :)

Auch, wenn es eig für den Anti-Jammer-Thread wäre – endlich passen dein und mein Post Count mal zusammen (1111 & 1444).

Upps, jetzt nicht mehr.

Wenn die Mehrzahl meiner Beiträge wenigstens wie bei dir in fachlichen Foren wären :D

„Am meisten aktiv in Thema: Jammer-Thread
(147 Beiträge / 10.17% deiner Beiträge)“

Ironisch, wenn man meine Signatur bedenkt.

Immer dran denken, Chromanoid: du hast, im Gegensatz zu ihm, die notwendigen Rechte um den Jammer–Faden zu loeschen ;-)

Dieses Privileg erscheint mir vor diesem Hintergrund allerdings fragwürdig ;)

Leute, versucht niemals unter Miktex pygmentize zum Laufen zu kriegen. Für alle, die nicht wissen was das ist: Das wohl beste Syntax-Highlighting, das man für Latex kriegen kann. Unter anderem setzen das auch github und andere ein, nur halt dann nicht unter Latex. ;)

Das fängt schon mit der Installation an: Python habe ich hier so wie so drauf, so weit so gut. Dann wollen die erstmal irgendwelche eigenen Installationsroutinen (easy_install, yo dawg!), um überhaupt pygmentize installieren zu können. WTF? Könnten die das bitte als ganz normales Python Paket anbieten, so wie jeder andere auch? Gut, wenn man das über sich ergehen lässt, kommt als nächstes die Installation von dem Latex Paket minted. Auf Kompilieren gedrückt, gewartet bis Miktex sich aktualisiert hat und … Schrott.

Die Programmüberprüfung via \ifAppExists im minted-Paket funktioniert nicht unter Windows. Also in der minted.sty herumhacken, spezifisch einfach den ganzen Kram auskommentieren (ich habe eine gültige pigmentize-Installation, danke!): Das ist übrigens ein bekannter Fehler. Aber warum irgendetwas ändern?

Und weiter gehts: Nochmal durchgejagt, und was kommt? Usage: C:\Programme\Python\Scripts\pygmentize-script.py [-l <lexer> | -g] [-F <filter>[:<options>]] [-f <formatter>] … sieht nicht gut aus. Die Parameter sind Müll. Also wieder in die minted.sty reingeschaut, und da steht: Nur dumm, dass wegen dem --shell-escape von Miktex alle Parameter in Anführungszeichen gesetzt werden (das ist nicht kritisch), und alle Sonderzeichen escaped werden, d.h. aus > wird ^> gemacht. Unterdessen haben sich die Leute von pygmentize gedacht, hach, machen wir doch einfach mal kein Python-Skript mehr für Windows, sondern kompilieren das als Executable. Also kommt das Herumschreiben am Python-Skript nicht in Frage. Was also machen?

Da Krishty ja bereits die vorzüglichen Vorzüge des Batch-Skriptings hier kundgetan hat, und ich firm in der Standardaufrufsreihenfolge unter Windows bin (es ist die gleiche wie für DLLs, siehe hier), muss man einfach eine pygmentize.bat in den miktex\bin Pfad von Miktex erstellen. Diese wird dann als erstes von Miktex aufgerufen, weil sie ja im lokalen Ordner liegt, und diese ruft wiederum die pygmentize.exe auf. Ganz schnell folgendes hingerotzt: Und so wie ich das sehe, funktioniert nun alles. Und diese Beschreibung enthält nicht die schätzungsweise 15 fehlgeschlagenen Versuche, das irgendwie anders hinzubekommen, und zwar auch so, dass wenn sich Miktex ein neues Paket holt, man nicht wieder alles neu machen muss. Übrigens schweigt sich sowohl die Dokumentation von pygmentize wie auch von minted vollständig über diese Sache aus.

Nachtrag: Ich habe nunmehr auch die Font-Optionen von minted zum Laufen gekriegt (für die Wissenden: Es fixt die \minted@define@extra und \minted@define@extra@switch Optionen). Ich bin nicht stolz auf obiges Skript (eigentlich schäme ich mich dafür), aber es ist nun einmal ein typischer „Kleber“ zwischen einer Anwendung und einer anderen Anwendung, die nicht so recht zusammenpassen wollen. Dieser Nachtrag ist aber meiner Meinung nach notwendig, da obige Lösung bestimmt irgendwann via Google gefunden wird (bei dem Pagerank hier!), und ich niemanden eine halb-gare Lösung anbieten will.

Und auch mal nen Screenshot gemacht:

eXile: Im Moment sieht alles nach einem schnöden Ausfall irgendwo zwischen Domain-Provider und Server aus.

Eine Sache, die mir an HLSL beständig aufstößt, ist die Trägheit bei großen Shadern. Während bei GCC ein Grundsatz ist, ausschließlich Algorithmen mit logarithmischer Laufzeit einzusetzen, explodiert der HLSL-Compiler bei großen Shadern regelrecht in Zeit- und Speicherbedarf (sogar ohne Optimierungen). Noch dazu kommt dann irgendwann so ein Müll wie Shader@0x0000000000260000(519,12): internal warning: loop values did not converge.
Mit aktivierten Optimierungen vervielfacht sich die Laufzeit dann erneut, so dass ich mittlerweile schon Shader über Nacht kompilieren lasse. Und was bringt das dann? Ein Shader mit 343 Anweisungen ist nach zwei Stunden auf 342 Anweisungen runter„optimiert“, indem zwei Anweisungen vertauscht und zwei weitere zu einem Multiply-Add zusammengefasst wurden. Bravo. Ich hasse diese Missgeburt von Flicksprache abgrundtief.

Mein Glare hat horizontal weiße Duplikate geschmissen. Hier an der Mondsichel sieht man den hellen horizontalen Streifen:Zwei Stunden habe ich den Fehler gesucht. Sogar die Fourier-Transformation habe ich schon verdächtigt. Aber nein … das Problem war die Textur mit den Augenlidern. Die habe ich nämlich für optimale Qualität aus der Originalauflösung per Lanczos-Filter herunterskaliert … und der wirft Wellen. Mal hundertfach kontrastverstärkt:Wenn die Augenlider über die Iris hinaus geöffent waren, haben diese Pixel durch Clamping Streifen geworfen und ein feines horizontales Gitter erzeugt, an dem das Licht nach links und rechts gebrochen wurde.
Ich bin nicht perfektionistisch, weil es mir Spaß macht oder weil mich mein analer Charakter dazu zwingt, sondern weil der Fehler immer im Detail liegt.

Dass man die Gruppengröße eines Compute Shaders in der Anwendung nicht abfragen kann, ist furchtbar. Ich hatte gerade versehentlich eine falsche Größe im Quelltext gelassen und dadurch alle Pixel einer Textur doppelt bearbeitet – das Resultat war, dass der Grün- und Blau-Kanal der unteren Texturhälfte voller seltsamer Ergebnisse war, die eigentlich auf falsche Texturkoordinaten schließen lassen würden, während im Rotkanal alles war, wie es sein sollte. Man hat keine Chance, aus dem Fehler irgendwie die Ursache herzuleiten. Das sollte echt nicht sein.

Achja – dass man die ganzen IDs so einfach verwechseln kann ist auch scheiße.

Wisst ihr, was das hier für ein Fehler ist?Es ist kein Fehler in den Shader-Konstanten, die zur Berechnung der Texturkoordinaten herangezogen werden.
Es ist keine ungewollte Konvertierung zwischen int und float.
Es ist kein falsch eingestellter Sampler-State und keine falsch geladene Textur.
Es ist auch kein falsch angegebenes Texturformat.
Und es ist auch kein Adressierungsfehler in dem Compute Shader, der für das Anzeigen auf dem Bildschirm zuständig ist.

Es ist ein Synchronisierungskonflikt beim Lesen aus gruppenweiten Daten. Und er tritt nur in dieser Auflösung zu Tage.
Humus hat mit seiner Einschätzung, dass in den nächsten Jahren reihenweise Spiele kaputt gehen werden weil beim Umstieg auf neue Hardware unbehandelte Race Conditions auftauchen, wahrscheinlich voll und ganz Recht.

Und weil es ja Leute gibt, die mich gern leiden sehen, gibt es noch einen Bonus.

Nur zur Info: Das Bonusbild hat sich mittlerweile als Compiler-Bug herausgestellt. Mal wieder. Ich werde den Sonntag mal damit verbringen, dem Team eine schöne Hass-Mail zu schreiben … betreffend der ständigen Fehler, der absolut unterirdischen Qualität, der katastrophalen Performance und den unnötigen Optimierungen.

Edit: Done.

Wie viel Zeit verbringen der CUDA- oder OpenCL-Compiler mit Deinen Shadern?

Nie ausprobiert und auch keine Lust, die vielen hundert Zeilen zu portieren. Für einen Umstieg ist es nun einfach zu spät :/

Der Cuda Compiler (nvcc) ist relativ fix. Fix as in es nervt nicht bei der täglichen Arbeit. Zumindest nicht bei dem was ich damit anstelle.

Seht ihr das da? Seht ihr den Schwarzen Punkt?Der kleine Ficker ist NaN; entstanden bei der double-zu-half-Konvertierung. Und er lässt das ganze Tonemapping NaN werden, sobald er ins Blickfeld kommt. Rage.

Ab heute darf ich also den Test hinzufügen, vor der Auslieferung jeden Punkt am Himmel einmal betrachtet zu haben. :)

Genau das Problem habe ich auch immer wieder, sobald nur irgendein Wert NaN liefert wird das im Tonemapping zur Katastrophe...

So und jetzt muß ich hier auch mal jammern! Mein Account wurde wohl als Ziel ausgewählt. Ich mußte gerade eine Frage beantworten, da ich die maximale Anzahl an Einlog-Versuchen bereits überschritten hatte, was definitiv nicht von mir verschuldet wurde!! Ich werde also jetzt mein Passwort ändern, nur zur Sicherheit!

Ja, die bösen NANs... die sind ansteckend.

@Stephan: Dein Account war kein konkretes Ziel - viele unserer Accounts waren in den letzten Tagen automatisiert angegriffen worden. Nach drei Versuchen sperrt die Forensoftware dann weitere Loginversuche bis zur Eingabe des Captchas, um Wörterbuchattacken zu verhindern. Die Tatsache, dass Du ein Captcha lösen musstest, heißt also, dass Deinem Account nix passiert ist :-)

Immerhin besser als beim Arcor E-Mail Service. Wenn dort irgendjemand zu einem Account 3x das falsche Passwort eingibt wird der Account komplett gesperrt. Inklusive POP3 Zugriff. Um ihn wieder zu aktivieren wird einem dann eine 0190 Nummer angezeigt.

Ich hasse den GPU Shader Analyzer. Alle Speicherlatenzen sind entweder geraten oder falsch – das zeigt allein die Tatsache, dass für ein Programm ohne Sampling-Operationen unterschiedliche Ausführungszeiten für bi-/trilinearen und anisotropen Filter ausgegeben werden –, Synchronisationen werden komplett ignoriert und beim Stream Kernel Analyzer kommt es gern vor, dass ein Shader schneller oder langsamer läuft wenn man unterschiedlich oft auf den Compile-Button drückt.

Um mal auszudrücken, wie realitätsfern die Daten sind: Ich habe in drei der 40 Fourier-Transformationen, die ich durchführe, eine von vier Synchronisationen vor einer Schreiboperation entfernt. Der GPU Shader Analyzer prognostiziert 1/48stel kürzere Laufzeit. Tatsächlich hat sich die Gesamtleistung des Programms um 20 % erhöht – das Programm ist 20 % schneller, obwohl der Shader nur 10 % der Ausführungszeit ausgemacht hat! Diese spezielle Transformation nun mindestens drei Mal so schnell ist wie vorher und ein paar der Anderen auch, weil sie von den nun niedrigeren Speicherdurchsatzspitzen und der besseren Cache-Nutzung profitieren.

Ein Achtundvierzigstel, sagt der GPUSA.

Hach, zum Glück mache ich nichts mit Shadern... :)

Was ich hasse, ist wenn man mit Templates arbeitet, und auch nur eine Kleinigkeit ändert, fast das ganze Projekt neu kompiliert wird.... *neeeeerv* :x

joggel hat geschrieben:… wenn man mit Templates arbeitet, und auch nur eine Kleinigkeit ändert, fast das ganze Projekt neu kompiliert wird.... *neeeeerv* :x

… dann hat man die Funktionalität nicht sauber getrennt ;) Seit ich mein Framework in zehn voneinander unabhängige Bereiche aufgeteilt habe, hat sich die Kompilierzeit halbiert. Seit ich die C-Runtime und die STL rausgeschmissen habe, geviertelt. Komplette Neukompilierung kommt nur noch vor, wenn ich was an den wirklich fundamentalen Templates ändere – und dazu müsste sich entweder herausstellen, dass meine Implementierung von min() oder meine typedefs fundamentaler Datentypen falsch wären, oder ich müsste Unterstützung für einen neuen Compiler hinzufügen.

Mmmhh... das kann sein! Weiß aber auch nicht was ich da noch weiter kapseln könnte, bzw. der Aufwand wäre zu hoch...
und btw:

http://zfx.info/viewtopic.php?f=9&t=307 ... 405#p14896