ZFX + Developia

Unified Memory? Dass ich das auf meine alten Tage noch erleben darf! :o

Ich liebe std::unique_ptr. Das ist einfach alles so toll durchdacht, und funktioniert so super. Jetzt ist nicht nur garantiert, dass ich keine Memory-Leaks habe, sondern auch, dass ich immer weiß, wer jetzt mein Objekt verwaltet :)

Alleine, dass das hier kompiliert: aber das hier nicht: ist einfach nur herrlich.

Definitiv, die Tiefe, mit der ein großer Teil der grundlegenden Mechanismen in C++ durchdacht ist, bedarf bei allem Ärger über die bisweilen grauenvollen Auswüchse des C-Erbes großer Bewunderung. (Die unüberlegte Fortführung des in C halb so schlimmen C-Erbes bedarf dieser leider ganz und gar nicht.) Unerfreulich bezüglich unique_ptr ist ab und an, dass der Zeiger nach der Besitzübertragung gänzlich verschwindet und in diesem Fall für nachfolgende Benutzung mit einem zusätzlichen rohen Zeiger gespiegelt werden muss. Aber gut, sehen wir das einfach als gewollten Zwang zu größtmöglicher Transaktionalität; schließlich wollen wir in der Map ja keine halbfertigen Objekte.

Ich habe nach einem Jahr Rumprobieren tatsächlich zum ersten Mal eine Stelle gefunden, an der __restrict unter x64 meinen Maschinentext verbessert.

Ich kann soweit sagen:

• __restrict wirkt nur bei der Funktionsdeklaration; bei der Definition ist es wirkungslos. Es wird also als Top-Level-C/V-Qualifier verarbeitet, weil die ja das gleiche Verhalten zeigen, wie wir mittlerweile wissen.
• __restrict wird nicht auf erbende Funktionen übertragen.
• In den meisten Fällen konnte ich __restrict weglassen und bekam den gleichen Maschinentext, indem ich den Parameter by value übergeben habe. Visual C++ optimiert wohl pass by-value zu pass by-reference, falls es dabei Aliasing ausschließen kann und die Parameter zu groß für ein Register sind.
  Jetzt kommt der Teil, den ich nicht verstehe: Pass by-reference wird nicht optimiert und erzeugt minderwertigen, Aliasing annehmenden Text. Dabei wurde ja, indem pass by-value zu pass by-reference optimiert wurde, bewiesen, dass der Compiler alle Aufrufe der Funktion erkennt und Aliasing ausschließen kann?!
• Übrigens werden structs bis hin zu Registergröße bei Übergabe by-value in einem Register übergeben und bewirken überlegenen Text, weil die einzelnen struct-Attribute aus dem Register geholt werden statt jedes einzeln zu lokalisieren und zu laden. Visual C++ optimiert die Übergabe by-reference aber nicht automatisch zu by-value, im Gegensatz zum umgekehrten Fall.

__restrict hat, zumindest für Methoden, also doch Wirkung für x64, das sehe ich nun endlich ein. Jetzt muss ich nur rausfinden, warum bloß für 1 % meiner Methoden.

Das sind übrigens selbstverständlich nur Beobachtungen auf einer Handvoll eigener Funktionen; es muss nicht wirklich so sein wie es mir erscheint.

Krishty hat geschrieben:Unified Memory? Dass ich das auf meine alten Tage noch erleben darf! :o

Da das gerade zum Thema der PS4-Einführung passt, hier ein Interview-Ausschnitt von vor fünf Jahren:

http://www.tgdaily.com/business-and-law-features/36410-tim-sweeney-part-2-directx-10-is-the-last-relevant-graphics-api hat geschrieben:TG Daily: Since you are a member of Microsoft's advisory board for DirectX, you probably have a good idea what we will see next in DirectX. What can we expect and do you see a potential for a segmentation of APIs - all over again?

Sweeney: I think Microsoft is doing the right thing for the graphics API. There are many developers who always want to program through the API - either through DirectX these days or a software renderer in the past. That will always be the right solution for them. It makes things easier to get stuff being rendered on-screen. If you know your resource allocation, you'll be just fine. But realistically, I think that DirectX 10 is the last DirectX graphics API that is truly relevant to developers. In the future, developers will tend to write their own renderers that will use both the CPU and the GPU - using graphics processor programming language rather than DirectX. I think we're going to get there pretty quickly.

I expect that by the time of the release of the next generation of consoles, around 2012 when Microsoft comes out with the successor of the Xbox 360 and Sony comes out with the successor of the PlayStation 3, games will be running 100% on based software pipelines. Yes, some developers will still use DirectX, but at some point, DirectX just becomes a software library on top of ... you know.

Die PS4 wird aber aller Voraussicht nach eine eigene, proprietäre 3D-API bekommen, und hat eben auch eine eigene GPU; und wird damit eben nicht Software-only sein. Auch sonst kann ich das nicht einsehen, zumal der Abstand von Software und 3D-Hardware mit einem Faktor von ca. Einhundert auch nicht plötzlich verschwinden kann.

Andererseits frage ich mich, was solche Leute, die keine 3D-APIs mehr wollen, dann eigentlich in einem 3D-API-Beirat zu suchen haben, und ob das für die Zukunft von Direct3D so prickelnd war.

(Ja, ich weiß, was ich gemacht habe, ist total unfair: Einfach eine Aussage von einer Person über die Zukunft genommen, dann die Zeit abgewartet und die Vorhersage mit der eingetretenen Realität verglichen. Haut mich doch.)

1> User defined type 'type_info' has different definitions or layouts in the following modules:
1> 'f:\dd\vctools\crt_bld\SELF_64_amd64\crt\src\build\amd64\dll_obj\nativecpp\ti_inst.obj (C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64\MSVCRT.lib)' ('f:\dd\vctools\crt_bld\self_64_amd64\crt\src\typeinfo' line 47)
1> 'C:\Users\Krishty\Desktop\projects\Temp\Visual C++ 2010 internal helpers.obj' ('c:\users\krishty\desktop\projects\framework\visual c++ 2010 internal helpers.cpp' line 25)
1>
1> User defined type '_GUID' has different definitions or layouts in the following modules:
1> 'f:\dd\vctools\crt_bld\SELF_64_amd64\crt\src\amd64\dll_lib\ehvecdtr.obj (C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64\MSVCRT.lib)' ('f:\dd\public\sdk\inc\guiddef.h' line 22)
1> 'o:\w8rtm.obj.amd64fre\com\published\idlole\public\objfre\amd64\cguid_i.obj (C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x64\uuid.lib)' ('d:\w8rtm.public.amd64fre\sdk\inc\guiddef.h' line 22)
1> 'C:\Users\Krishty\Desktop\projects\Temp\D3D9Rasterizer.obj' ('c:\users\krishty\desktop\projects\framework\com.hpp' line 22)
1>
1>LINK : warning LNK4262: 2 instances of type mismatch

Ich hatte es noch nicht bemerkt, aber Visual C++ hat in den Projekteigenschaften unter Configuration Properties -> Linker -> Advanced die Option Detect One Definition Rule violations bekommen.

Ich habe erst vor ein paar Tagen bemerkt, dass Visual Studio einen immer via Doppelklick aufs Ausgabefenster direkt zu einer Datei führt, so lange die Formatierung den MSBuild-Vorgaben folgt.


Das bedeutet, auf den Link von oben übertragen, dass wir nette To Do-Markierungen bauen können, die bei jedem Kompilieren auftauchen und einen bei Doppelklick direkt zur Zeile führen:

    #define TODO_INTERNAL_STRINGIZE(text) #text
    #define TODO_INTERNAL_QUOTE(text) TODO_INTERNAL_STRINGIZE(text)
    #define TODO(toDoText) __pragma(message(__FILE__" ("TODO_INTERNAL_QUOTE(__LINE__)"): TODO: "toDoText))

    ...

    TODO("get shit done")         *klicklick*


Aber es geht ja noch weiter: Das Verhalten ist ja längst nicht auf die Kompilierung beschränkt. Nett ist das z.B. für Memory Leak Detection, die statt einem endlosen Wulst aus Dateinamen und Zahlen via OutputDebugString() nette Nachrichten ins Output-Fenster ausgibt, die einen sofort zum verursachenden Quelltext führen:

    internal\D3D9.cpp (53): leaking 32 B at 0x000000000202ACDB

Auf der Arbeit bin ich ein Bisschen weitergegangen und habe unsere hunderte Lecks nach Dateien klassifiziert (darauf achten, dass __FILE__ manchmal mit Groß- und Kleinschreibung, und manchmal ohne kommt; und dass die Pfade manchmal relativ sind, und manchmal nicht!), aufsteigend nach Zeilen sortiert, und für jede Zeile zusammenfasst, wie oft wie viele Größen geleckt sind. Der Frustfaktor beim Debugging ist enorm gesunken:

    internal\D3D9.cpp (53):                                    *klicklick*
        leaking 13 x 32 B = 416 B (# 331, 332, 383, 407, …)
    internal\D3D9.cpp (183):                                   *klicklick*
        leaking 2 x 2048 B = 4096 B (# 335, 13300)
        leaking 1 x 8192 B = 8192 B (# 13304)
        leaking 1 x 32768 B = 32768 B (# 13471)

    clipping.cpp (1358):                                       *klicklick*
        leaking 480 x 32 B = 15360 B (# 412, 413, 414, 415, …)


Damit ist aber noch nicht Schluss: Lädt eure Engine Shader, Skripte, oder sonstwas? Parst ihr XML? Niemand hält euch davon ab, Nachrichten mit Verweisen auf diese Fremddateien auszugeben, falls mal was schiefgeht. Scheißegal, was für Textressourcen da durch die Anwendung geschoben werden – im Fehlerfall ist man immer nur einen Doppelklick von Datei, Zeile, und Spalte entfernt. Hat meinem Flow wirklich gutgetan.

Jep; die D3D-Compiler geben im Übrigen alle ihre Fehlermeldungen bereits in konformem Format zurück. Um auch "anonymem" Shader-Code im Speicher zu diesem Zweck eine Dateizugehörigkeit zu verpassen, bietet D3DCompile den pSourceName-Parameter. Bei Übergabe eines gültigen Strings wandert dieser als Dateipfad in die Fehlermeldungen des Shader-Compilers.

Ist ja auch kein Wunder – schließlich ist der D3D-Compiler in Visual Studio integriert ;)

ZFX geht wieder. Und ich dachte schon, ihr hättet tatsächlich eine „Krishty darf nicht eher als 24 Stunden nach dem letzten Bier posten“-Regel realisiert …

… ich erlebe aber sporadisch richtig heftige Timeouts.

Die Timeouts sehe ich auch. Und ich bin recht sicher, dass es nicht an meiner Mecker-Quote hängt. Ich ging stattdessen davon aus, dass da gerade wieder Konfig-Experimente mit Forum und Server betrieben werden.

eXile hat geschrieben:In diesem Jahr gibt es wieder schöne Ereignisse in der großen himmlischen Bespaßungsmaschine zu sehen:

• C/2011 L4:
  • Vorausichtliche maximale scheinbare Helligkeit: +1
    (Schätzung aus dem Januar 2013)
  • Entspricht ca. der scheinbaren Helligkeit vom Polarstern oder Wega
  • Datum der nächsten Annäherung: 9. März 2013

Man konnte bei klarem Himmel und niedrigem Horizont den Kometen gestern zuerst in unseren Breitengraden sehen; in den kommenden Tagen wird der Komet immer höher über dem Horizont, aber auch immer schwächer zu sehen sein. Beobachtungsrichtung ist ziemlich genau gen Westen, Beobachtungszeitpunkt ca. 19:00 Uhr; keine Bewölkung ist natürlich Voraussetzung.

Betrifft primaer die Assimp-Entwickler:

http://youtu.be/FaEvMCD4Gus?t=40m26s
40:26

Spricht eigentlich irgendwas dagegen, dass wir "the most unfortunately named library ever" zu unserem offiziellen Untertitel machen - ausser Vernunft, Zeit und unser Ruf? :-)

Ich schmeiß mich weg... Da fällt mir ein: neben Umzug und tochter sollte ich mal meine Asset-Importer-Aufgaben abarbeiten.

Gruß Kimmi

P.S.: In Englisch : nope!

Find ich gut :)

Und ich erst … werde mir das Interview mal anhören, wenn ich zu Hause bin.

AMDs CodeXL ist nicht nur das gute alte CodeAnalyst in wunderbare Visual-Studio-Integration gegossen (auch VS11!), es läuft obendrein weiterhin ohne Widerwillen auf meinem handelsüblichen Intel i7. Danke, AMD!

Ich habe unsere Beschreibung mal aktualisiert :-)
https://github.com/assimp/assimp

CodingCat hat geschrieben:AMDs CodeXL ist nicht nur das gute alte CodeAnalyst in wunderbare Visual-Studio-Integration gegossen (auch VS11!), es läuft obendrein weiterhin ohne Widerwillen auf meinem handelsüblichen Intel i7. Danke, AMD!

Naja, ich wollte neulich nochmal meine OpenGL Anwendung debuggen, und es hatte genau wie der mittlerweile alte AMDgDebugger einige Probleme. So wollte es mir z.B. einfach nicht meine Texturen anzeigen, wenn ich das Programm pausierte. Im großen und ganzen ist es schon ein sehr nützliches Tool, aber es hat zumindest für OpenGL Debugging meiner Meinung nach noch Verbesserungspotential. Und das ist insofern schade, als dass es das einzige wirklich brauchte OpenGL-Debuggin Tool zu sein scheint.

Ich nutze es ausschließlich für CPU-Profiling.

Kann es sein, dass Visual Studio 2012 weder mit noch ohne Language Extensions Operatorsynonyme unterstützt?

Die hat MSVC noch nie unterstützt. Aber: http://msdn.microsoft.com/en-us/library/ayefs2c0.aspx ;)

Warum wurde ich dann früher bei ::std::vector<::Foo> von Warnungen überschüttet?

Du meinst MSVC 11 supported digraphs? :shock:

Edit: Grad getestet und nope, der Fehler muss was Anderes gewesen sein...

Nein; 11 unterstützt sie ganz sicher nicht mehr. Ich weiß aber, dass 10 oder 9 immer irgendwas Furchtbares gemacht hat, wenn mir versehentlich ein Digraph in die Datei gerutscht ist. Darum bin ich auch im Anti-Jammer-Thread – falls die Scheiße wirklich weg ist, juble ich erstmal.

Übrigens: Kann mir jemand die Regeln für Zeilenumbrüche am Ende von Headern erklären? Ich weiß, dass in C++ jedes Übersetzungsmodul mit einem Zeilenumbruch enden muss – aber was ist mit Headern? Und Headern, die in einem Kommentar oder Präprozessorbefehl enden? Google schickt mich leider immer nur zu '\n'-vs-std::endl-Diskussionen …

Holy shit: http://msdn.microsoft.com/en-us/library/ee462497.aspx

So wie's aussieht unterstützt MSVC offenbar tatsächlich Digraphs und Trigraphs, wenn /Za da ist. Ansonsten nicht. Das war mir neu, ich hab das vor langer Zeit aus Interesse sogar mal erfolglos ausprobiert...

Edit: Das mit dem Newline stammt afaik aus prästandard Zeiten. Ich würde mal vermuten, das Problem wurde im Standard durch Translation Phase 2 gefixed:

A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file.

Ich glaube auch, bevor C++0x kam, hatte ich auch immer mit /Za (Spracherweiterungen deaktivieren) kompiliert. Daran könnte es also gelegen haben.

Entschuldige – ich wollte die Regeln für Zeilenumbrüche nicht gerechtfertigt, sondern nur erklärt haben :) Heute ist mein freier Tag, da hinterfrage ich ausnahmsweise mal nix.
Nachtrag: Danke! Aber was ist eine Source File? Nur .cpp, oder auch #includes? Vor oder nach Einsatz des Präprozessors?

Nachtrag 2: Zwei Kuriositäten: Google schlägt mir C++ translation phrases vor, und diesen Kniff kann ich bestimmt irgendwo zu meinem Vorteil einsetzen …

Wenn ich das richtig verstehe, dann sind "Header" im Sinne des Standard nur die Header Standardlibrary. Ein Source File ist jede Datei die Code enthält, also .cpp, .h etc.

Ein \ am Ende einer Zeile führt dazu, dass der darauf folgende Newline Character entfernt wird, was effektiv bedeutet, dass die nächste Zeile mit der aktuellen Zeile zusammengemerged wird. Wie auch in dem Stackoverflow Thread in einem Comment erwähnt, funktioniert das für das dortige Beispiel mit dem Wide String Literal aber nicht, da der Präprozessor tokenbasiert arbeitet und auf diese Weise nicht zwei Token zu einem werden können. (Man stelle sich mal vor, wie lustig das das Schreiben von mehrzeiligen Makros machen würde...)

Okay; dann versagt Visual Studio dort. Es spuckt mir für die letzten angefangenen Zeilen von #include-Dateien

} // namespace Foo

und

#endif

unerwartete Dateienden entgegen (beharrt darauf, dass Zeilenkommentare und Präprozessordirektiven mit Zeilenumbruch enden – fügt offensichtlich keinen selber ein).

Was genau meinst du mit unerwarteten Dateieneden?