ZFX + Developia

http://msdn.microsoft.com/en-us/library/78x83000.aspx

Warum kannte ich die noch nicht <3

Weil Du zu wenig Dokumentationen liest? :P

http://code.google.com/p/google-guice
Warum kannte ich das noch nicht <3 :) ich sollte mich mehr bei anderen Communities rumtreiben und nicht in diesen Java feindlichen Gefilden :D

Wenn man weiß, dass die Daten an 16 Bytes ausgerichtet sind, kann man in zehn Zeilen ein memcpy() schreiben, das 33 % schneller als das ist, was VC eingebaut hat.

Krishty hat geschrieben:Wenn man weiß, dass die Daten an 16 Bytes ausgerichtet sind, kann man in zehn Zeilen ein memcpy() schreiben, das 33 % schneller als das ist, was VC eingebaut hat.

Was wir aber auch hier sehen wollen :) Was ist mir der Variante?

Ist ja bloß ordinary routine – identisch mit deinem Vorschlag, nur, dass ich für 2 statt 4 Schreibvorgänge abgerollt habe:Was mir zu denken gibt ist, dass ich bei ziemlich genau 6 GiB/s feststecke. Das sind 50 % mehr als memcpy() (bzw 33 % weniger Ausführungszeit für die gleiche Menge), liegt aber immernoch weit unter der theoretischen Höchstleistung meines Core i7 (die irgendwo zwischen 15 und 30 GiB/s lokalisiert sein müsste) … Prefetching hat keinen Einfluss; macht das Ganze bei zu hohen Offsets nur noch langsamer.

Der Compiler macht außerdem lustige Dinge: Adressiert Quelle und Ziel durch vier verschiedene Register statt durch zwei; Speichert xmm0–xmm6 am Anfang der Funktion und stellt sie danach wieder her.

Nachtrag: Wartewartewarte – Lois, das sind nicht meine Batman-Mnemonics! Dein Vorschlag benutzt genau die umgekehrten Befehle?! Bei mir setzt VC movdqa zum lesen und movntdq (ohne a, obwohl die Doku sagt, „Address p must be 16-byte aligned“) zum schreiben … was imho auch vollkommen sinnvoll ist – was man lädt, soll ja im Cache landen, und was man schreibt, soll so schnell wie möglich weg damit mehr Cache für zu ladendes bleibt. Die Version aus dem Link arbeitet bei mir durch die Bank 70 % langsamer; wenn ich nur movntdqa zum lesen einsetze sind es immernoch 5 %. Ich werde es mal in Verbindung mit Prefetching testen. noch langsamer, und das hier lässt vermuten, warum.

Yay, ich kann mich wieder einloggen :)

Zum Glueck ist die Frage bei zu vielen falschen Logins nicht allzu schwer :lol:

Jaaa! Das heutige Flash-Update bringt Multimonitor-Support für den Fullscreen-Modus!

Enrico_ hat geschrieben:Zum Glueck ist die Frage bei zu vielen falschen Logins nicht allzu schwer :lol:

Wir haben schon überlegt ob wir das Nivea dort nicht anheben wollen – Sozialdarwinismus quasi, indem rausfliegt, wer sich dreimal falsch einloggt (bzw. dem entsprechenden Raub-Bot zum Opfer fällt) und nicht demonstrativ den Momentverlust eines Doppelneutronensternsystems durch Gravitationswellen vorrechnen kann.

Dann fiel uns wieder ein, dass wir ja Nachwuchsprobleme haben und das Forum zu professionell wirkt … und haben uns in der Folge darauf beschränkt, solche Filterkriterien auch weiterhin nur auf unsere persönlichen Freundeskreise anzuwenden.

Dankeschön!
Ich weiß Eure Nachsicht zu schätzen.

Krishty hat geschrieben:

Enrico_ hat geschrieben:Zum Glueck ist die Frage bei zu vielen falschen Logins nicht allzu schwer :lol:

Wir haben schon überlegt ob wir das Nivea dort nicht anheben wollen – Sozialdarwinismus quasi, indem rausfliegt, wer sich dreimal falsch einloggt (bzw. dem entsprechenden Raub-Bot zum Opfer fällt) und nicht demonstrativ den Momentverlust eines Doppelneutronensternsystems durch Gravitationswellen vorrechnen kann.

Oder so. (Ein paar mal aktualisieren ;))

Die Fragen sind nicht ohne Ueberlegung entstanden. Ziel war, dass sie entweder durch Google bzw. Wissen und gesunden Menschenverstand loesbar sein sollten. Bis heute haben es sogut wie keine Bots geschafft, das zu packen.

Nur so nebenbei (auch wenn es eher in den Jammer-Thread gehoert): letzte Woche hab ich die Frage nach der Berliner Mauer bekommen und geistesabwesend 1990 eingetippt. Glaubt mir, es ist deprimierend an seinen eigenen Anti-Bot-Fragen zu scheitern.

Aramis hat geschrieben:Letzte Woche hab ich die Frage nach der Berliner Mauer bekommen und geistesabwesend 1990 eingetippt.

Die hatte ich letzte Woche ebenfalls. Und ebenfalls 1990 eingetippt. Zum zweiten Mal.

Krishty hat geschrieben: Wir haben schon überlegt ob wir das Nivea dort nicht anheben wollen – Sozialdarwinismus quasi, indem rausfliegt, wer sich dreimal falsch einloggt (bzw. dem entsprechenden Raub-Bot zum Opfer fällt) und nicht demonstrativ den Momentverlust eines Doppelneutronensternsystems durch Gravitationswellen vorrechnen kann.

Aus der Serie „Man muss nur lange genug nerven“:
http://forums.create.msdn.com/forums/t/73249.aspx

Es ist übrigens wirklich verblüffend, dass keins der SDK-Beispiele die Datentypen benutzt, die bei mir so abkacken. Sie hatten mal eine RWTexture1D im Tonemapping-Beispiel; haben sie aber rausgenommen, damit es endlich auch auf D3D10-Hardware läuft – nachdem D3D11-Hardware rauskam. Wenn mich meine ungerichtete Paranoia nicht trügt, könnte sie die verblüffend schlechte Leistung auf Karten eines bestimmten Herstellers motiviert haben. (Dieses spezielle Beispiel ist bei mir übrigens mit Compute Shader 0,1 % schneller als mit Pixel Shader; yeah.)

Nächsten Montag gibts übrigens auf der GDC einen für dich wohl nicht ganz uninteressanten Vortrag:

http://schedule.gdconf.com/session/ hat geschrieben: 5:30-6:15pm
High Performance Post-Processing (Nathan Hoobler, NVIDIA)
This talk discusses common performance concerns for effects utilizing DirectCompute by walking through a sample post-processing application, applying non-obvious but important optimizations one by one and explaining how they relate to topics such as exposing parallelism, taking advantage of shared memory, and efficient data access patterns.

Das findet im ganztägigen Programming-Track „Advanced Visual Effects with DirectX 11“ statt (die Vortragenden sind hauptsächlich von Nvidia und AMD). Da Nvidia und Konsorten gerne Mal ihre Folien vorab online stellen (bzw. „gestellt werden“), würde ich mal die Augen offen halten. ;)

Nachtrag: Ich lass das hier mal so stehen:

This session will take a look at some of AMDs favorite techniques from the last year, including the use of DirectCompute to accelerate physics, an innovative new highly efficient solver for Diffusion DOF, and DirectCompute accelerated post-processing.

Nachtrag: Klasse gemacht, eXile! Weil ich mich selbst zitieren wollte, erst einmal den Post hier kaputtgeschrieben. Schnell aus dem Google-Cache wiederhergestellt.

Da könnte ich auch sprechen! Beste Optimierung: Benutzt D3D 10.1 und CS 4.1 … so einfach ist das!

Nein, obwohl mir Post-Processing langsam zum Hals raus kommt: Es klingt tatsächlich nicht schlecht. Wäre dir sehr verbunden, wenn du das eine oder andere Schätzchen verlinken könntest.

Was Physik mit DirectCompute angeht: Die benutzen schlicht und einfach keine Texturen dafür, sondern lineare Puffer. Achtfache Performance. Thema erledigt. Bei Postprocessing sicher genau so; tut Microsoft ja auch.

Gute Nachrichten für alle Kiddies, die noch nicht auf DirectX 10 umsteigen wollen!

http://www.heise.de/newsticker/meldung/ ... 95138.html

Jay! Meine collision-sphere-tree-basierte Kollisionsabfrage funktioniert nun für rotierte, skalierte, bewegte wenn auch statische Modelle bzw. verschiedene Instanzen von Modellen auch bei 3rd-Person-Kamera. Die Zwerge rotieren und wenn einer einen anderen trifft, bleibt er stehen und macht erst weiter, wenn der andere Zwerg weg ist. Und bisher verhakt auch nichts, ich glaube sogar, das ist z.Z. nicht möglich. Außerdem ist die Performance fast perfekt, da Kugel-zu-Kugel-Kollisionsabfrage überhaupt kein Aufwand ist.

Der nächste Schritt ist dann die Kollisionsabfrage mit bone-animierten Modellen, das wird nochmal ne Herausforderung. Aber auch die Variante lässt sich durch ein paar Vorberechnungen äußerst performant umsetzen. Und danach kann ich endlich mit dem eigentlichen Spiel beginnen (na ja, besser gesagt mit alternativer BoundingBox-Kollision für quaderförmige Objekte wie Mauern, aber gut)!

HLSLs nointerpolation ist nicht nur nützlich, sondern bringt bei kurzen Shadern mit vielen Parametern auch handfestes Leistungsplus. So muss das sein!

Meine Bitte, meine Steuerung für mehrere angeschlossene USB-Raketenwerfer auf der Bestellseite zu veröffentlichen, bzw. einen Link zur Homepage zu machen, wurde angenommen.

http://www.getdigital.de/products/USB_Raketenwerfer
:)

Zusätzlich bekomm ich von GetDigital nun noch nen 50%-Rabatt-Gutschein.

Und ich hab schon einiges an Netzwerkcode für mein MissileControl-Programm zusammen gerafft und hab ihn soweit auch verstanden :)
Problem ist nur noch die IP-Adressenfindung innerhalb des Netzwerkes...Ich werde es schaffen!

Boah endlich! Geil.

Obwohl

Jetzt darf ich entweder auf GCC umsteigen oder bis 2012 warten, damit die guten Features in Visual C++ implementiert sind.

Und Concepts sind ja sowieso wieder rausgeflogen.

Toll.

eXile hat geschrieben:Nächsten Montag gibts übrigens auf der GDC einen für dich wohl nicht ganz uninteressanten Vortrag:
High Performance Post-Processing (Nathan Hoobler, NVIDIA)

Ich hab meinen Beitrag gerade durch Zufall wiedergesehen, und mittlerweile sind alle Vorträge von AMD online, und zwar hier. Beim Schnellen drübergucken war es jetzt nicht wirklich berauschend, aber für Chromanoid gibts wenigstens wieder ein paar Bokeh-Bilder. ;)

(Ehrlich gesagt, hatte ich die Seite von AMD gar nicht mehr auf meinem Radar, weil die so lange unaktualisiert blieb. Ich habe extra nicht zur Nvidia-Seite gelinkt, weil die Präsentation dort nur als PDF ohne Kommentare vorliegt, die Powerpoint-Präsentation besitzt dahingegen Notizen.)

Efficient Compute Shader Programming.pps hat geschrieben:

• Try lots of different configurations
  • Avoid hard-coding variables
  • Use GPUPerfStudio to edit in-place

Die bittere Wahrheit. Kopflos rumprobieren, weil man bei dem Compiler eh nicht logisch vorgehen kann.

• HDAO [High-Definition Ambient Occlusion] at full resolution is expensive
• Running at half resolution captures more occlusion – and is obviously much faster

High-Definition Ambient Occlusion optimieren, indem man die High Definition wegnimmt. Genial.

Dir ist schon klar dass du das im Anti-Jammer Thread gepostet hast? ;)

Ich muss halt beim Thema bleiben!

Ich finds klasse, das ab Qt 4.6 Shader unterstützt werden.
Muss ich mir keinen Kopf darum machen, einfach nur Shader-Code schreiben, an QGLShader übergeben, kompilieren und linken. So einfachte sollte es laut Doku funktionieren.. Ich werde sehen. Ich werde ebenfalls sehen, wie ich mit der ganzen Shader-Sache zurecht komme... vlt. bin ich dann auch so cool :)

Gruß

http://www.heise.de/newsticker/meldung/Nachgelegt-Catalyst-Treiber-mit-OpenCL-Schnittstelle-1218277.html hat geschrieben:Zudem bietet AMD eine Vorschau auf den nächsten Catalyst-Treiber. Für Version 11.4 verspricht der Hersteller bei 3D-Spielen Performance-Zuwächse im zweistelligen Prozentbereich mit Grafikkarten der Serien Radeon HD 6800 und 6900.

Jetzt bin ich aber gespannt, ob sie mirnichtsdirnichts einen zusätzlichen Zentimeter aus der Hardware-Hose gelutscht haben oder ob sie tatsächlich mal am Compiler gedreht haben.
Aber testen kann ich das ja eh erst in fünf Monaten (wenn ein GPU Shader Analyzer raus ist, der den 11.4er unterstützt) …