Jammer-Thread

[glassbear]

Unsere Architekten haben wieder zugeschlagen: Ich versuch hier low-level das ganze moeglichst schnell hinzubekommen, DMA-Transfers ueber Prozessgrenzen hinweg ist da noch das Kleinste :ugeek:
Und was machen die: Benutzen Exceptions um normale Rechenergebnisse durch die Gegend zu schicken :shock: Der Scheiss kostet uns jetzt 30-50% unserer Ausfuehrungszeit. Als Grund fuer diesen genialen Einfall: "Ja, mit Exceptions ist das so schoen einfach und liess sich auch ganz fix implementieren. Ich konnte ja nicht wissen, dass das so viel Performance kostet. Ich verschick doch nur ein paar..." - Klar, in seinem ultramini Testcase verschickt er nur 10. In der realen Welt sind das dann mal eben mehrere 1.000 Exceptions pro Sekunde. Und aendern geht natuerlich nicht mehr - was einmal da ist, darf nicht mehr geaendert werden :evil: Wir koennten einen zweiten Service einfuehren, der das macht, aber das dauert min. 3 Monate (ich biete 3 - 5 Tage). AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHH
Alternativer Loesungsvorschlag: Wir sollen einfach die restlichen 50% (Hardware) Ausfuehrungszeit soweit runter optimieren, dass wir da auf 5% kommen. Dann haben wir unser Target ja fast erreicht :evil: :evil: :evil: :evil: :evil: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHH

[joggel]

wtf??!!
Na wenns weiter nichts is...
Aber das mit diesen Exceptions "schicken" fande ich mal auch ne ganz tolle Geschichte, bis mich mal jemand aufgeklärt hatte, das es unheimlich auf die Performance geht...

[kaiserludi]

Ich liebe es, wenn das passiert:

fatal error C1001: An internal error has occurred in the compiler.
1>(compiler file 'msc1.cpp', line 1411)
1> To work around this problem, try simplifying or changing the program near the locations listed above.

[CodingCat]

Refactoring Complete

Code: Alles auswählen

beGraphics::ToTex<beGraphics::TextureType::Texture2D>(finalTarget);

Scheinbar funktioniert ADL bei freien Funktionen mit Template-Argumenten nicht? (finalTarget hat einen Typ aus beGraphics.)
Zudem würde ich ein PDL bei der Übergabe enumerierter Konstanten sehr begrüßen. :|

[CodingCat]

Wenn ihr wissen wollt, ob ein Effect Pass / Shader von einer bestimmten Textur Gebrauch macht, nutzt einfach ...

Code: Alles auswählen

/* Effects-only */

ID3DX11EffectPass::GetVertexShaderDesc(D3DX11_PASS_SHADER_DESC*),
ID3DX11EffectPass::GetDomainShaderDesc(D3DX11_PASS_SHADER_DESC*),
ID3DX11EffectPass::GetHullShaderDesc(D3DX11_PASS_SHADER_DESC*),
ID3DX11EffectPass::GetGeometryShaderDesc(D3DX11_PASS_SHADER_DESC*),
ID3DX11EffectPass::GetPixelShaderDesc(D3DX11_PASS_SHADER_DESC*), // und womöglich
ID3DX11EffectPass::GetComputeShaderDesc(D3DX11_PASS_SHADER_DESC*);

// für alle 5-6 der oben abgefragten
// {
      D3DX11_PASS_SHADER_DESC::pShaderVariable->ID3DX11EffectShaderVariable::GetShaderDesc(D3DX11_PASS_SHADER_DESC::ShaderIndex, D3DX11_EFFECT_SHADER_DESC*); 

      /* Effects & Shaders */

      D3DReflect(D3DX11_EFFECT_SHADER_DESC::pBytecode, D3DX11_EFFECT_SHADER_DESC::BytecodeLength,
                  IID_ID3D11ShaderReflection, reinterpret_cast<void**>(&ID3D11ShaderReflection*));

      bool TextureInUse = SUCCEEDED(ID3D11ShaderReflection::GetResourceBindingDescByName(const char *TextureName, D3D11_SHADER_INPUT_BIND_DESC*));
// }

... einmal pro Pass / Shader.

Ganz ähnlich geht das übrigens für uniforme globale Variablen und Constant Buffers, bei Bedarf genügt ein Blick auf ID3D11ShaderReflection::GetVariableByName(), ID3D11ShaderReflectionVariable::GetDesc(), ID3D11ShaderReflection::GetConstantBufferByName() und ID3D11ShaderReflectionConstantBuffer::GetDesc(). Für uniforme Variablen beachte man zudem D3D11_SHADER_VARIABLE_DESC::uFlags und D3D_SVF_USED.

[CodingCat]

Das IDXGIFactory1-Objekt will nicht erst mit den anderen statics zerstört werden. Dann halt nicht. Der Referenzzähler ist ein Genosse...

[kaiserludi]

Zehntausende Zeilen Code sind in Tabs eingerückt und was macht der Kollege, der ein neues Feature einbauen soll:
Er nutzt zum Einrücken Spaces statt Tabs.
Der Höhepunkt: Das Projekt kann in 3 verschiedenen IDEs geöffnet werden. Man ahnt es schon -> Der Fuchs hat in allen 3 IDEs verschiedene Tabweiten eingestellt, jeweils mit der Option aktiviert, Spaces statt Tabs einzufügen.
Wäre ja nicht wild, wenn das einmal passiert, aber ist jetzt auch schon locker die 10. Mail, in der ich darauf hinweise, das zu unterlassen und mittlerweile ist sogar ein Styleguide im Repo eingecheckt mit diesem Hinweis.

[Chromanoid]

Schon mal an statische Code Analyse gedacht? http://en.wikipedia.org/wiki/List_of_to ... e_analysis Bin mir aber nicht sicher, ob es für C++ was gibt, das auch die Einrückung überprüfen kann... http://code.google.com/p/google-styleguide/ bzw. cpplint sieht interessant aus, allerdings ist google für 2 spaces statt tabs ;)...

[kaiserludi]

Schon mal an statische Code Analyse gedacht? http://en.wikipedia.org/wiki/List_of_to ... e_analysis Bin mir aber nicht sicher, ob es für C++ was gibt, das auch die Einrückung überprüfen kann... http://code.google.com/p/google-styleguide/ bzw. cpplint sieht interessant aus, allerdings ist google für 2 spaces statt tabs ;)...

Da war doch eben noch ein anderer Link?
Ja, habe schon nach so was woe Styleguard für C++ gesucht, aber bisher noch nichts gefunden, was mich wirklich zufrieden stellt.
Der Vorteil von Tabs ist ja gerade, dass nicht alle Programmierer und Editoren des Projekts die gleiche Tabweite benutzen müssen, damit das Format lesbar bleibt. Manche bevorzguen 2, andere 4, wieder andre 8.
googles Styleguide propagiert so manches, was ich für äußerst fragwürdig halte (z.B. gibts es eine ganze Reihe C++ Sprachfeatures, die google in ihren Projekten nicht benutzt sehen will mit der Begründung, sie könnten, falsch benutzt, zu dem und dem Problem führen. Korrekt wäre es meienr Meinung nach, deswegen nicht das Feature zu verbieten, sondern es nur in dem Zusammenhang zu meiden, in dem es das Problem tatsächlich verursacht).

[Chromanoid]

Ja da war ein anderer Link -> http://www.suodenjoki.dk/us/archive/201 ... kstyle.htm. Bezügl. Google: Keine Ahnung, was da das richtige ist. Ich programmiere äußerst ungern C++. Ich schätze mal, dass man den benutzten Zusammenhang viel schlechter automatisiert überprüfen kann und in größeren Projekten ist das wahrscheinlich wichtiger als alle Sprachfeatures benutzen zu können. Über den genauen Grund, warum Leerzeichen statt Tabs propagiert werden, habe ich mir noch keine Gedanken gemacht. Netbeans formatiert für mich und nimmt Spaces, bei meinem Job übernimmt das Eclipse (mit einem angepassten Style)...

[kaiserludi]

Ich programmmiere am liebsten in C++. C++/CLI ist auch ok, D habe ich mir noch nicht genauer angeschaut. Bei allen anderen Sprachen fühle ich mich zu sehr durch die Sprache eingeschränkt.
z.B. hat C# extrem viele nervige Kleinigkeiten, wie bspw., dass man Referenzen und primitive Typen nicht einfach wie einen bool per if(foo) bzw. if(!foo) testen kann.

[j.klugmann]

z.B. hat C# extrem viele nervige Kleinigkeiten, wie bspw., dass man Referenzen und primitive Typen nicht einfach wie einen bool per if(foo) bzw. if(!foo) testen kann.

Das macht doch durchaus Sinn. Einen Int oder einen anderen primitven Datentyp auf True zu überprüfen ohne eine Operation( /=,==) macht doch mal wirklich keinen Sinn. Bools sollten Bools bleiben und sich auch so verhalten. Dementsprechend sollte man Ints oder Doubles nicht wie Bools behandeln. Das führt nur zu Fehlern... Wie so vieles an schwacher Typisierung(Laufzeitfehler).

[Krishty]

Stilprüfung brüstet sich neuerdings als statische Analyse? Wow.

Mal gucken, wann der Erste Java-Quereinsteiger Windows’ Dateiegenschaftsdialog mit sowas wie Clang und Klee vergleicht. Der analysiert schließlich fleißig die Größe!

[eXile]

Der analysiert schließlich fleißig die Größe!

Lustig, da anscheinend das in Java sogar relativ schwierig sein soll.

[CodingCat]

Ich versuche verzweifelt, sämtliche Schnittstellenabhängigkeiten (sprich Abhängigkeiten der öffentlichen Headers) von anderen Bibliotheken wie Boost zu vermeiden, doch jede Anwendung des PImpl-Idioms fügt mir unerträgliche Schmerzen zu.

[Chromanoid]

Stilprüfung brüstet sich neuerdings als statische Analyse? Wow.

Ähm, das mit dem Stil ist natürlich nur ein Teil davon. Ich selbst hab neulich mal sonar (wikipedia eintrag) ausprobiert, das macht richtig Spaß, wenn man die Qualität des eigenen Quellcodes detailliert hübsch aufgemacht analysieren kann (So sieht das dann aus: http://nemo.sonarsource.org/dashboard/index/146590). Für Bug Warnung direkt in der IDE gibt's Späße wie FindBugs.

[CodingCat]

Es ist soweit, der Schmerz war zu groß:

Code: Alles auswählen

// Hpp
class Class
{
   struct Pass;
   lean::forward_val<Pass, 2 * sizeof(void*)> m_pass;
   [...]
};

// Cpp
struct Class::Pass
{
   lean::com_ptr<ID3D11InputLayout> inputLayout;
   lean::resource_ptr<AbstractProcessingEffectBinder> effectBinder;
   [...]
};

Class()
   : m_pass( Pass(...) )
{
}

PImpl-bedingte Speicherfragmentierung und Cache-Misses bin ich los, dafür darf ich jetzt fleißig Größen raten. Wenigstens schimpft static_assert mit mir, wenn ich daneben liege...

[eXile]

Any render targets not defined by this call are set to NULL.

Wem soll ich nun glauben, der Realität und der Doku, oder dem MVP?

[Schrompf]

Ich kann Deine riesigen Screenshots nur schwer einordnen, aber soweit ich das verstehe, hat ja die Doku recht und nicht der MVP. Korrigiere ihn freundlich und freue Dich über 2cm zusätzliche NetCred.

fup AntiJammer-Thread :-)

[CodingCat]

Zum Glück, ein anderes Verhalten hätte mich jetzt schwer enttäuscht. Das ist wirklich ein großer Schritt in die richtige Richtung, weg von der fehleranfälligen Mega-State-Machine. Ich war da am Anfang sehr skeptisch, weil ich es aus DirectX 9 gewöhnt bin, dass ich beliebige States einfach überlagern kann, und so dynamische Kombinationen implizit geschenkt bekomme. Tatsächlich sind die vier State-Block-Typen und die paar anderen blockweise verwalteten Zustandsgruppen ein Segen. Statt aus Effizienzgründen nur bestimmte States regelmäßig zurückzusetzen, kann man nun jedem Objekt bzw. jedem Renderaufruf seinen eigenen wohldefinierten Gesamtzustand geben, ein gewaltiger Fortschritt gegenüber Hunderten von weitgehend ungewissen Render States in DirectX 9.

[CodingCat]

Die Rache der alteingesessenen selbsternannten Programmier-Gurus, die keinen Fortschritt über ihrem eigenen Horizont von 1990 dulden: The prophet programmer

Dieser Post ist mit Abstand der größte Unfug, den ich seit langem gelesen habe. Ja, es mag Leute geben, die es mit der Standardkonformität zu weit treiben, die funktionierenden Code alleine aufgrund von irgendwelchen Idealvorstellungen im Nachhinein kaputt machen, und das ist im Rahmen einer zielgerichteten Entwicklung sicher kontraproduktiv. Aber den C++-Standard als Rezeptbuch darzustellen, das Schreiben von standardkonformem Code als robotergleiches Anwenden von vorgefertigten Lösungen gegenüber der kreativen Problemlösung durch den guten Programmierer, der alleine durch Biegen und Brechen aller Regeln überhaupt erst in der Lage ist, echte Probleme zu lösen, zu deren Lösung der "Standardprogrammierer" (standardkonform == standard, durchschnittlich!) überhaupt nicht in der Lage ist; das alles demonstriert doch nur die absolute Unwissenheit des Autors, der offensichtlich noch nie auch nur einen Blick in dieses "Rezeptbuch" gewagt hat.

[dot]

Ja, dass D3D die Mega-State-Machine losgeworden ist, ist der wesentliche Faktor, der es imo zur mit großem Abstand besten Grafik-API macht, mit der ich je arbeiten durfte. Aber der Schritt ist auch bitter notwendig. Denn globaler State und Multithreading können nicht so gut miteinander. Imo ist das eine der ganz großen Schwachstellen von OpenGL. Denn durch sein kaputtes Objektmodell ist OGL im Prinzip auf ewig dazu verdammt, sein Dasein als threadlokale Mega-State-Machine zu fristen...

[dot]

Die Rache der alteingesessenen selbsternannten Programmier-Gurus, die keinen Fortschritt über ihrem eigenen Horizont von 1990 dulden: The prophet programmer

Ignorance is bliss, wie ich immer zu sagen pflege :mrgreen:

EDIT: Gott, wie gern würd ich da einen Kommentar hinterlassen :D

[Krishty]

Einen sowieso hirnrissigen Kompressionsalgorithmus einen Abend lang überarbeitet, die Nacht durchrechnen lassen … und von 43 MiB komprimierter Größe nur 752 einzelne Bytes eingespart. Oder: Ein Einundsechszigtausendstel.

[Jörg]

Die Nächte sind wieder dunkel und ich verpasse eine Stufe 5 Aktivitaet :( http://www.gi.alaska.edu/AuroraForecast/2011/09/09

[Krishty]

..\framework\XAudio2.hpp(7): error C2757: 'XAudio2' : a symbol with this name already exists and therefore this name cannot be used as a namespace name
1>..\framework\XAudio2.hpp(96): fatal error C1903: unable to recover from previous error(s); stopping compilation

Unter den nutzlosesten Fehlermeldungen rangiert die doch mindestens in den Top 10. Irgendwo ist also schon so ein Symbol definiert … und wo soll das bitte sein?! Ich würde furchtbar gern den entsprechenden Header rausschmeißen, aber ich weiß nicht, welcher es ist und wenn ich auf Go To Declaration / Definition klicke, lande ich genau bei der namespace-Deklaration, die fehlerhaft sein soll …

[Jörg]

Schon "preprocess only" probiert? Da solltest Du schnell fuendig werden...

[Krishty]

Nö. Der Knackpunkt war

DEFINE_CLSID(XAudio2, 5a508685, a254, 4fba, 9b, 82, 9a, 24, b0, 03, 06, af);

in XAudio2.h, das zu

class __declspec(uuid(5a508685-a254-4fba- 9b82-9a24b00306af)) XAudio2;
extern "C" const GUID CLSID_XAudio2;

auflöste. Dank __declspec() in der Deklaration hätte ich da auch mit Präprozessorausgabe lange suchen können; aber zum Glück stand das alles relativ weit am Anfang des Headers.

[Krishty]

Ich will C99-Initializer Syntax in Visual C++ – jetzt, jetzt, jetzt!

Ich möchte structs statisch initialisieren, die unions beinhalten. Natürlich kriegt man damit im Augenblick immer nur das erste Attribut adressiert …

[Krishty]

http://blogs.msdn.com/b/vcblog/archive/ ... 09291.aspx

Range-based for-loop        No
Delegating constructors        No
Explicit conversion operators        No
Defaulted and deleted functions        No
Raw string literals        No

…

constexpr        No