ZFX + Developia

Hab mir mal die Windows Developer Preview mit Visual Studio 11 Express angeschaut:

• Solution explorer:
  • Man kann jetzt die Dateianzeige auf bestimmte Unterordner einschränken (ähnlich der Funktionalität, die schon die Productivity tools brachten).
  • Für jede Datei kann man die enthaltenen Klassen-, Methoden- und Attributsdefinitionen anzeigen lassen (ähnlich der Funktionalität vom „Class View“-Fenster).
• Neue solution properties:
  • Debugging → Debugger Type: GPU Only
  • Debugging → GPU Debugging Accelerator Type: GPU – DirectCompute Ref Emulator
    „The debugging accelerator type to use for debugging the GPU code.“
  • Debugging → GPU Default Breakpoint Behavior: Break once per warp
    „The CPU behavior is that every thread that hits a default breakpoint (i.e. non-conditional, non-filtered, etc) causes the debugger to break. Through this setting you can change the debugger to break only once per warp per kernel, or even only for a single warp (the first one that hits a default breakpoint) per kernel.“
  • Anscheinend steht das alles im direkten Zusammenhang mit C++ AMP; leider war in dieser Version alle weitere dahingehende Funktionalität deaktiviert.
  • C/C++ → All Options: Übersicht über alle C/C++-Optionen.
  • Linker → All Options: Dito für die Linker-Optionen.
  • HLSL Compiler: Alles einstellbar von Include directories, Entrypoint, Shader model bis Preprocessor definitions. „Effects compiler“ ist jetzt als Dateityp (so komisch es klingt) einstellbar (und bewirk natürlich, dass der fxc.exe zum Kompilieren dieser datei verwendet wird).
• Text editor:
  • Quick find / Quick replace aus den Productivity tools eingebaut.
  • Man kann jetzt Tabs pinnen (bleiben immer ganz links in der Tab-Leiste).
  • Via „Go to definition“ aufgerufene Tabs sind nur Tabs zweiter Klasse (bleiben immer ganz rechts in der Tab-Leiste); man kann sie aber zu normalen Tabs „promoten“.
  • Syntaxhighlighting für HLSL-Dateien.
  • Keinerlei Intellisense für HLSL-Dateien.
  • Die Auto-Vervollständigung von Intellisense scheint besser geworden zu sein; zumindest werden schon während des Schreibens Vorschläge gemacht (z.B. th → this).
  • Es gibt jetzt Code-Snippets, aber das wird niemand benutzen. (Es gibt wirklich ein Snippet für { … }!)
  …
• Notepad versteht noch immer keine Newlines ohne Carriage-Returns.

Von der neuen PIX-Integration war noch nichts zu sehen – dazu braucht es wohl erst ein neues DirectX-SDK. Was wohl auch der Grund ist, warum bereits so lange kein neues erschienen ist.

Alter, die **** geht! Und man sieht das geil aus!
Näheres in 2 Sekunden im WIP Thread, yay!

OOOkaay. So enttäuschend PhysX 3.0 in seiner äußeren Form war, so überraschend ist PhysX 3.1. Die haben es doch tatsächlich fertig gebracht, ihre Verzeichnisse zu ordnen, sämtliche relativen Includes zu fixen UND obendrein alles sauber in Namespaces zu verpacken. So liegt mir nun wohl das erste aufgeräumte PhysX SDK in der Geschichte vor, Wow!

Binärdateien Lesen mit Memory-Mapped Files, Zeigerarithmetik und Exception-Safety ist ein TRAUM! Wenn ich da an Java zurückdenke, als ich in den Genuss kam, zehntausende von Binärdateien wahlweise mittels Streams oder Byte-Buffer-Index-Schieberei in endlos langen Hilfsklassen auszulesen ...
Und wenn ich nicht die Hälfte meiner Zeit damit verbringen müsste, zwischen Headers und Compilation Units hin- und herzuspringen, und alle Deklarationen doppelt zu schreiben, C++ wäre DIE produktivste Sprache der Welt - DANK Zeigerarithmetik (und deterministischer Zerstörung)!

Die produktivste gleich nach Haskell? :D

CodingCat hat geschrieben:Binärdateien Lesen mit Memory-Mapped Files, Zeigerarithmetik und Exception-Safety ist ein TRAUM! Wenn ich da an Java zurückdenke, als ich in den Genuss kam, zehntausende von Binärdateien wahlweise mittels Streams oder Byte-Buffer-Index-Schieberei in endlos langen Hilfsklassen auszulesen ...
Und wenn ich nicht die Hälfte meiner Zeit damit verbringen müsste, zwischen Headers und Compilation Units hin- und herzuspringen, und alle Deklarationen doppelt zu schreiben, C++ wäre DIE produktivste Sprache der Welt - DANK Zeigerarithmetik (und deterministischer Zerstörung)!

Header nerven zwar in der Hinsicht, dass man sich selbst darum kümmern muss, alles so zu inkludieren und zu deklarieren, dass jeder Codepart alles kennt, was er braucht, aber dafür hat man hinterher eine schöne Übersicht direkt im Code unabhängig davon, was die IDE kann und wie gut man sich in der IDe auskennt, über das Interface einer Klasse. Dass Java, C# und co. so etwas wie Header nicht haben, ist für mich kein Plus-, sondern ein dicker Minuspunkt dieser Sprachen gegenüber C, C++ oder objC!

kaiserludi hat geschrieben:Header nerven zwar in der Hinsicht, dass man sich selbst darum kümmern muss, alles so zu inkludieren und zu deklarieren, dass jeder Codepart alles kennt, was er braucht, aber dafür hat man hinterher eine schöne Übersicht direkt im Code unabhängig davon, was die IDE kann und wie gut man sich in der IDe auskennt, über das Interface einer Klasse.

Wäre ja toll, wenn es wirklich nur die öffentliche Schnittstelle wäre. Aber nee, man muss ebenfalls alle geschützten und privaten Attribute, Methoden und Vererbungen auflisten.

Was die Kopie der Funktionsdeklarationen angeht, ist das so ein riesiger Verstoß gegen Don't Repeat Yourself, dass es der größte C++-Eiferer nicht mehr schönreden kann. Um da irgendwie rauszukommen haben sie Templates so formalisiert, dass diese abartigen Header-only-Bibliotheken entstanden sind, die deine Kompilierleistung dann endgültig mit ihrer Textwucht begraben.

Und zu guter letzt führt man damit in die Sprache ein in Zeit- und Speicherbedarf exponentielles Problem ein (da meist immer alle Header alle anderen #includen müssen, um ihre Abhängigkeiten aufzulösen), von dem ich aus Erfahrung sage, dass man es bei unter Zeitdruck entstandenen Projekten (also allem, was kommerziell ist) weder vermeiden noch durch steigende Rechenleistung besiegen kann – sondern nur durch den Rückgriff auf nicht-standardkonforme Erweiterungen wie Vorkompilierte Header. Fuck, sogar in meinem mit endloser Liebe zum Detail entstandenen Hobbyprojekt kriege ich keine Header-Struktur hin, die DirectX (und damit COM (und damit die WinAPI (und damit die CRT (und damit die STL (… merkst du, wo das hinführt?))))) vermeidet.

Es ist einfach nur ein riesiger, nutzloser Haufen stinkender Redundanz auf die ich a) keinen Bock habe; den b) zum Großteil der Compiler für mich erzeugen könnte; und c) der erst geschätzte 30 % der Entwicklungszeit frisst indem man Deklarationen mit Dokumentation anlegt, die man nie wieder aktualisiert, und danach nochmal 50 % indem man nach jeder kleinen Änderung im hintersten Popel-Header eine Viertelstunde neukompilieren muss.

So war mein Tag.

Meine allergrößte Hochachtung.

Ich könnte mir nichts ätzenderes vorstellen,
als diesen ganzen Mist,
der die letzten 10 Jahre von CAD-Software herausgeschissen wurde,
zu analysieren, lesen und zu verpacken,
und den ganzen Mist dann
zu fixen, zu ergänzen und rundzulutschen,
und DAS dann noch
wiederverwendbar, ABI-sicher UND mit Support
allen frei zur Verfügung zu stellen.

Danke Aramis, Schrompf, kimmi. Danke, Danke, Danke!

Support für die CAD-Files stammt alles von Aramis *finger zeig*

(Wenn ich an die vielen Codeleichen und ungefixten Bugs in unserer Codebasis denke, wird mir schlecht.) Aber davon abgesehen, danke fuer die Blumen, ich freue mich immer wahnsinnig ueber ein "Dankeschoen", das nicht mit einer Supportanfrage gekoppelt ist :-)

PS: *zurueckzeig, er hat Collada gebaendigt*

Was lernen wir daraus? Supportanfragen und Dankeschöns immer separat, nicht aneinander gekoppelt -> Gefühlsachterbahnfahrt für Aramis *g*

Ich habe in der letzten Studen sieben coole Assets selbst kreiert. Blender rulet, und jetzt fühle ich mich schon fast wie ein Pro-Modeller!
(Na gut, ich gebs zu, alles aus Quadern ...)

Eine Steintextur tileable gehört wohl zu den meditativsten Dingen, die ich je gemacht habe. Und dank genialer kognitiver Fähigkeiten bezüglich Mustererkennung weiß das Hirn natürlich trotzdem gleich, was Sache ist. :(

gerade drüber gestolpert: http://blogs.amd.com/developer/2011/09/ ... e-aparapi/ find ich cool. Eine vernünftige Java API für OpenCL... Java byte code wird direkt in OpenCL Code umgewandelt. http://code.google.com/p/aparapi/

Die statische Initialisierungsreihenfolge ist in C++ innerhalb von Übersetzungseinheiten wohldefiniert

Ab heute schreibe ich alles nur noch in Header, die dann von einer einzigen, gewaltigen Übersetzungseinheit #includiert werden

Krishty hat geschrieben:Die statische Initialisierungsreihenfolge ist in C++ innerhalb von Übersetzungseinheiten wohldefiniert

Ab heute schreibe ich alles nur noch in Header, die dann von einer einzigen, gewaltigen Übersetzungseinheit #includiert werden

Dürfte aufs Ganze gesehen sogar noch effektiver sein als einzelne Übersetzungseinheiten.
Und wenn der Compiler das komplette Programm kennt, kann er auch übers komplette Programm optimieren.

LTCG?

Viel Spaß damit, wenn jedes Kompilieren so lange dauert wie ein kompletter Rebuild der gesamten Solution *g*

kaiserludi hat geschrieben:Viel Spaß damit, wenn jedes Kompilieren so lange dauert wie ein kompletter Rebuild der gesamten Solution *g*

Krishty hat geschrieben:Aktuelles Projekt mit 1 MiB Quelltext in 20 Übersetzungseinheiten (.cpp-Dateien) und 70 Headern, im Debug-Modus:

1>Build succeeded.
1>
1>Time Elapsed 00:00:01.89
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Statt 20 Übersetzungseinheiten ist es dann nur noch eine; aber dafür entfällt vierfach parallele Kompilierung – also werde ich irgendwo knapp unter einer Sekunde landen. Ja; ich komme vor lauter Kompilieren schon zu garnichts Produktivem mehr.

Nein, im Ernst: Vor IntelliSense’ Verhalten fürchte ich mich da schon mehr; ich glaube, dass das bei tiefer #include-Struktur sehr wackelig wird.

Ich mach mir jetzt ne Pizza, und widme mich auch mal wieder meinen wochenendabendlichen Programmierangelegenheiten :D

Krishty hat geschrieben:

kaiserludi hat geschrieben:Viel Spaß damit, wenn jedes Kompilieren so lange dauert wie ein kompletter Rebuild der gesamten Solution *g*

Krishty hat geschrieben:Aktuelles Projekt mit 1 MiB Quelltext in 20 Übersetzungseinheiten (.cpp-Dateien) und 70 Headern, im Debug-Modus:

1>Build succeeded.
1>
1>Time Elapsed 00:00:01.89
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Statt 20 Übersetzungseinheiten ist es dann nur noch eine; aber dafür entfällt vierfach parallele Kompilierung – also werde ich irgendwo knapp unter einer Sekunde landen. Ja; ich komme vor lauter Kompilieren schon zu garnichts Produktivem mehr.

Nein, im Ernst: Vor IntelliSense’ Verhalten fürchte ich mich da schon mehr; ich glaube, dass das bei tiefer #include-Struktur sehr wackelig wird.

Bei den Kompilierzeiten sind doch eigentlich nur noch nightly builds eine akzeptabele Option...

Im ernst: Wie schaffst du es, als fleißiger Templateverwender, dass dein Code so schnell kompiliert?
Moin Hauptprojekt hat ca. 60 Sourcedateien und etwa 100 Header und kommt insgesamt auf ca. 1,5MB Quellcode bei 10 Projekten in der Solution. Dauer eines kompletten Rebuilds ist bei über 30 Sekunden, ein SDK-Build dauert über 3min nur für die Windows-Variante (das Projekt exisitiert derzeit für 5 Plattformen, die noch aktiv unterstützt werden).
Ein anderes Projekt, an dem ich arbeite, hat eine Zeit lang eine 3rd-party open-surce lib bei jedem Rebuild mit kompiliert. Da konnte ich mir während des Bauvorgangs einenKAffee machen und danch war er immer noch nicht durch. Das sind ca. 1.000 Sourcedateien mit insgesamt ca. 10MB Quellcode gewesen bei einer Rebuilddauer von über 5min.

Keine STL, absolut minimale CRT-Nutzung, boost ziehe ich garnicht erst in Betracht und WinAPI/DirectX existieren nur hinter Wrappern (landen also nur in zwei oder drei von zehn Übesetzungseinheiten).

(KA, was die ganzen Header alles machen, aber performant ist es nicht.)

Krishty hat geschrieben:Keine STL, absolut minimale CRT-Nutzung, boost ziehe ich garnicht erst in Betracht und WinAPI/DirectX existieren nur hinter Wrappern (landen also nur in zwei oder drei von zehn Übesetzungseinheiten).

(KA, was die ganzen Header alles machen, aber performant ist es nicht.)

Das kanns nicht sein. Bei mir: Keine STL, absolut minimale CRT-Nutzung, boost ziehe ich garnicht erst in Betracht und WinAPI/DirectX existieren auch nicht.

Projekteigenschaften => C/C++ => Preprocessor => Preprocess to a File

und dann guck mal, was deinen Quelltext so dick macht. Vielleicht ist deine Festplatte auch einfach langsamer oder so :) (Würde liebend gern mal auf einer SSD kompilieren …)

http://fffff.at/occupy/zfx.info :)

Ich liebe Grafikprogrammierung, endlich ist mein Zimmer wieder schön warm.

Ich <herz> C++11-Lambdas Noch schöner wär's, wenn der Compiler die Parametertypen aus dem Kontext ermitteln würde, aber das wär dann wohl zuviel der Typmagie.

[edit] Auch sehr cool: boost::bind. Die Flexibilität, beliebige Parameter des Signals umzustapeln und wegzulassen, und zusätzlich eigene Parameter an den Slot weiterzureichen, ist enorm praktisch.

Schrompf hat geschrieben: Noch schöner wär's, wenn der Compiler die Parametertypen aus dem Kontext ermitteln würde, aber das wär dann wohl zuviel der Typmagie.

Ich <herz> C#-Lambdas ;P

Einrückung leicht gemacht: printf("%.*s",tiefe,statischer_leerschritt_string); Geht sogar auf Symbian :)