Anti-Jammer-Thread
- Lynxeye
- Establishment
- Beiträge: 145
- Registriert: 27.02.2009, 16:50
- Echter Name: Lucas
- Wohnort: Hildesheim
- Kontaktdaten:
Re: Anti-Jammer-Thread
Es ist zwar irgendwie auch ein bisschen zum heulen, aber freu mich trotzdem mal drüber.
Gestern habe ich vier Stunden lang vergeblich versucht die OpenGL Extension nv_primitive_restart in nouveau zu implementieren. Heute habe ich mir den Trace noch mal angesehen und einen richtig doofen Denkfehler gefunden.
Nunja, immerhin konnte ich jetzt innerhalb von 15 min das richtige Verhalten implementieren und damit wieder ein gutes Stück Arbeit abschließen. YAY!
Gestern habe ich vier Stunden lang vergeblich versucht die OpenGL Extension nv_primitive_restart in nouveau zu implementieren. Heute habe ich mir den Trace noch mal angesehen und einen richtig doofen Denkfehler gefunden.
Nunja, immerhin konnte ich jetzt innerhalb von 15 min das richtige Verhalten implementieren und damit wieder ein gutes Stück Arbeit abschließen. YAY!
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ich habe ihn. Ja. IHN. Nach zwei Monaten habe ich diesen Drecks-Bug in Visual C++ endlich isolieren können.
Im x86-Compiler sorgt eine lokale Variable mit 8-Byte-Alignment dafür, dass das Register, mit welchem VC Parameter adressiert, in undefiniertem Zustand zurückbleibt, nachdem ein Stack Unwinding durchgeführt wurde.
Ich denke, dass in der Register Allocation was schiefläuft. Das erklärt auch, warum er so unglaublich schwer zu finden war – man muss z.B. vom Parameter eine Memberfunktion aufrufen, die einen Rückgabewert hat; einfach auf das Objekt zugreifen geht nicht. Dass er sich durch die anderen Optimierungen mit jeder Änderung irgendwo sonst im Programm verändert hat, muss ich wohl nicht dazusagen.
Bei mir tritt der Fehler beim Laden von Cache-Dateien auf und sorgt dafür, dass die Engine die Pfadangaben nicht mehr auf dem Stack vermutet, sondern am ungünstigsten Platz überhaupt – im Programmtext des catch-Blocks, in dem sie sich gerade befindet. In selbigem werden die Parameter dann nochmal mit Dateinamen und Pfadangaben gefüllt. Wäre der .text-Abschnitt also nicht read-only, könnte man eine Dateisuche dazu missbrauchen, bei der nächsten nicht gefundenen Cache-Datei eingeschleusten Code ausführen zu lassen :) Leider habe ich das aber nicht nochmal für Microsoft reproduzieren können; in dem Minimalbeispiel landet der Parameter an einer ganz anderen Adresse.
Mal gucken, ob sie noch was dran ändern. Dass der Bug vorher nie aufgefallen ist zeigt außerdem auch, wie etabliert Exception-Handling in C++ immernoch ist …
… übrigens musste ich heute mehr als 8000 Code-Zeilen in 40 Dateien ändern und/oder löschen, um das Schwein endlich auf Zelluloid bannen zu können. Jetzt sollen sie auch gefälligst mal ihren Arsch hochkriegen.
Wer testen möchte, ob der Bug auch in früheren VC-Editionen als 2010 mit beliebiger Optimierungsstufe > 0 auftritt, kann ja mal im Debugger gucken, ob sich hier &willBecomeInvalid ändert, sobald der catch-Block betreten wird:
Im x86-Compiler sorgt eine lokale Variable mit 8-Byte-Alignment dafür, dass das Register, mit welchem VC Parameter adressiert, in undefiniertem Zustand zurückbleibt, nachdem ein Stack Unwinding durchgeführt wurde.
Ich denke, dass in der Register Allocation was schiefläuft. Das erklärt auch, warum er so unglaublich schwer zu finden war – man muss z.B. vom Parameter eine Memberfunktion aufrufen, die einen Rückgabewert hat; einfach auf das Objekt zugreifen geht nicht. Dass er sich durch die anderen Optimierungen mit jeder Änderung irgendwo sonst im Programm verändert hat, muss ich wohl nicht dazusagen.
Bei mir tritt der Fehler beim Laden von Cache-Dateien auf und sorgt dafür, dass die Engine die Pfadangaben nicht mehr auf dem Stack vermutet, sondern am ungünstigsten Platz überhaupt – im Programmtext des catch-Blocks, in dem sie sich gerade befindet. In selbigem werden die Parameter dann nochmal mit Dateinamen und Pfadangaben gefüllt. Wäre der .text-Abschnitt also nicht read-only, könnte man eine Dateisuche dazu missbrauchen, bei der nächsten nicht gefundenen Cache-Datei eingeschleusten Code ausführen zu lassen :) Leider habe ich das aber nicht nochmal für Microsoft reproduzieren können; in dem Minimalbeispiel landet der Parameter an einer ganz anderen Adresse.
Mal gucken, ob sie noch was dran ändern. Dass der Bug vorher nie aufgefallen ist zeigt außerdem auch, wie etabliert Exception-Handling in C++ immernoch ist …
… übrigens musste ich heute mehr als 8000 Code-Zeilen in 40 Dateien ändern und/oder löschen, um das Schwein endlich auf Zelluloid bannen zu können. Jetzt sollen sie auch gefälligst mal ihren Arsch hochkriegen.
Wer testen möchte, ob der Bug auch in früheren VC-Editionen als 2010 mit beliebiger Optimierungsstufe > 0 auftritt, kann ja mal im Debugger gucken, ob sich hier &willBecomeInvalid ändert, sobald der catch-Block betreten wird:
Code: Alles auswählen
struct __declspec(align(8)) Aligned {
int dummyMember;
Aligned() {
dummyMember = 0; // crucial
return;
}
int returnAnInt() const {
return 0;
}
};
void badFunction(
Aligned & willBecomeInvalid
) {
Aligned willRemainValid;
try {
throw 0;
} catch(...) {
volatile int x = willBecomeInvalid.returnAnInt();
}
}
int main() {
Aligned param;
badFunction(param);
return 0;
}
Re: Anti-Jammer-Thread
Die Posts von Kristy bestätigen meine Meinung von MS Software: Am besten immer erst benutzen wenn mindestens SP2 released ist oder auf den Vorgänger zurückgreifen. *scnr*
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Anti-Jammer-Thread
Na da bin ich mal gespannt was Krishty erst aus DEINER Software macht. Oder aus gcc.
(Im Ernst: es ist ein C++–Compiler. Eine Sprache die schwer zu parsen ist, komplexe Regeln fuer Side–Effekts, Object–Lifetime etc. hat; ein schrecklich archaisches Kompilations– und Linkagemodell besitzt, fuer x verschiedene Architekturen compiled werden muss, Hacks auf Bitebene erlaubt … Qualitaetssicherung bei einer C++–Toolchain duerfte schon alleine aus diesen Gruenden um einige Groessenordnungen muehsamer sein als z.B. bei C#).
Das einzige was man evtl. dran kritisieren kann ist Microsofts lahmes Reagieren auf Bug–Reports. Meine Erfahrung mit OSS ist allerdings dass es da nicht unbedingt schneller geht – man muss nur selber mehr machen und kriegt den ganzen Prozess mit, anstelle von aussen auf die riesige Blackbox MS zu starren.
(Im Ernst: es ist ein C++–Compiler. Eine Sprache die schwer zu parsen ist, komplexe Regeln fuer Side–Effekts, Object–Lifetime etc. hat; ein schrecklich archaisches Kompilations– und Linkagemodell besitzt, fuer x verschiedene Architekturen compiled werden muss, Hacks auf Bitebene erlaubt … Qualitaetssicherung bei einer C++–Toolchain duerfte schon alleine aus diesen Gruenden um einige Groessenordnungen muehsamer sein als z.B. bei C#).
Das einzige was man evtl. dran kritisieren kann ist Microsofts lahmes Reagieren auf Bug–Reports. Meine Erfahrung mit OSS ist allerdings dass es da nicht unbedingt schneller geht – man muss nur selber mehr machen und kriegt den ganzen Prozess mit, anstelle von aussen auf die riesige Blackbox MS zu starren.
Re: Anti-Jammer-Thread
Hm, also ich konnte es unter VS05 nicht reproduzieren. Ich weiß aber auch nicht, wie ich das mit aktivierten Optimierungen zuverlässig debuggen soll...
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Da der Compiler try-catch und volatile nicht wegoptimiert, müsste man da ganz normal durchsteppen können. Füg alternativ hinter der Zeile mit dem volatile int ein:
willBecomeInvalid.dummyMember = 123;
Wenn der Bug da ist, sollte das Programm mit einer Access Violation abstürzen.
Edit: Okay, du hast recht. Sobald Optimierungen an sind, ist die Registeranordnung wieder unterschiedlich und es funktioniert. Verdammt. Also Optimierungen deaktivieren und der Command-Line manuell /Og hinzufügen.
Inline Function Expansion muss Default, also deaktiviert, sein. Omit Frame Pointers hat keinen Einfluss. Meine Command-Line ist
/Od Disables optimization
/Og …
/Oy- Do not omit frame pointer
/Gm Enables minimal rebuild
/EHsc Use C++ exception model
/GS Enable buffer security check
/fp:precise /Zc:wchar_t /Zc:forScope /GR- /Gd /errorReport:queue
willBecomeInvalid.dummyMember = 123;
Wenn der Bug da ist, sollte das Programm mit einer Access Violation abstürzen.
Edit: Okay, du hast recht. Sobald Optimierungen an sind, ist die Registeranordnung wieder unterschiedlich und es funktioniert. Verdammt. Also Optimierungen deaktivieren und der Command-Line manuell /Og hinzufügen.
Inline Function Expansion muss Default, also deaktiviert, sein. Omit Frame Pointers hat keinen Einfluss. Meine Command-Line ist
/Od Disables optimization
/Og …
/Oy- Do not omit frame pointer
/Gm Enables minimal rebuild
/EHsc Use C++ exception model
/GS Enable buffer security check
/fp:precise /Zc:wchar_t /Zc:forScope /GR- /Gd /errorReport:queue
Re: Anti-Jammer-Thread
Ne, kanns auch mit genau der Commandline nicht reproduzieren. Wahrscheinlich ist der Bug in einer neueren Version aufgetaucht.
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
VS 2008, anyone?
- Angehängte Datei nach Visual Studio 2008\VC kopieren
- Command Prompt starten (Programme -> Visual Studio 2008 -> Visual Studio Tools -> Visual Studio Command Prompt (2008))
- cl.exe ogbug.cpp /Og /EHsc
- ogbug.exe ausführen – keine Meldung == kein Bug, ogbug.exe funktioniert nicht mehr == Bug
- Dateianhänge
-
- ogbug.cpp
- (462 Bytes) 361-mal heruntergeladen
- Chromanoid
- Moderator
- Beiträge: 4262
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
Also ich habe es mal mit einem hämischen Blick auf den Java Hass Thread mit VS2010 reproduziert :) Weiß nicht ob dir das was nützt ^^
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Nicht direkt, da meine Programmabstürze mit VS 2010 und 2010 SP1 Beta mich erst auf den Fehler aufmerksam gemacht haben. Da das aber seit zwei Monaten das erste Mal ist, dass jemand diesen Bug reproduziert, fühle ich zumindest meine Realitätserfahrung bestätigt und danke dafür :)
-
- Establishment
- Beiträge: 471
- Registriert: 01.03.2009, 19:09
Re: Anti-Jammer-Thread
Hallo Krishty
habs grad mal probier...
konnte den Bug mit VS2010 nachvollziehen, mit VS2008 jedoch nicht
Gruß
Matthias
habs grad mal probier...
konnte den Bug mit VS2010 nachvollziehen, mit VS2008 jedoch nicht
Gruß
Matthias
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Vielen Dank!
(Die Frage ist jetzt nur, ob der Bug nicht drin ist oder ob die Variablenzuordnung sich unterscheidet, so dass er nur nicht auftritt.)
(Die Frage ist jetzt nur, ob der Bug nicht drin ist oder ob die Variablenzuordnung sich unterscheidet, so dass er nur nicht auftritt.)
- Chromanoid
- Moderator
- Beiträge: 4262
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
Habe hier eben einen Teil des Anti-Jammers und zwei Antworten darauf entnommen und in das Glare-Algorithmus-Thema gepackt. Ich hoffe das sorgt nicht für Verwirrung :). (Betroffene Beiträge von: Krishty, exile und hagbard).
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ich habe gerade ein kniffliges Problem durch Laufzeittypinformation und virtuelle Vergleichsoperatoren elegant gelöst. Seit langer Zeit mal wieder ein C++-Moment, an dem ich mir dachte: Verdammt, das war jetzt der beste Code, den du seit Langem geschrieben hast.
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Chrome ist der beste Browser der Welt.
Warum? Weil ich den Task-Manager starten und darin Flash beenden kann und ich dann in allen Grafikanwendungen die doppelte Framerate habe. Versucht das mal mit Firefox.
Warum? Weil ich den Task-Manager starten und darin Flash beenden kann und ich dann in allen Grafikanwendungen die doppelte Framerate habe. Versucht das mal mit Firefox.
-
- Moderator
- Beiträge: 2117
- Registriert: 25.02.2009, 13:37
Re: Anti-Jammer-Thread
Firefox hat mittlerweile auch Out of Process Plugins. Ich vermute mal, den plugin-container abzuschießen killt alle plugins, nicht nur Flash aber möglich isses.
- Chromanoid
- Moderator
- Beiträge: 4262
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
Chrome ftw :D
ich bin neulich erst auf Chrome umgestiegen :D Addon-Entwicklung geht richtig gut - sogar mit GWT ^^.
ich bin neulich erst auf Chrome umgestiegen :D Addon-Entwicklung geht richtig gut - sogar mit GWT ^^.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ich hätte es ja heute morgen noch nicht für möglich gehalten, als unser Straßenkartenrenderer nur so vor sich hin kroch: Man kann mit Java2D (Standard built-in Java-API) tatsächlich verdammt viele Linien in verdammt kurzer Zeit rendern. Der Schlüssel zu dieser Performance-Steigerung um schlappe 200 - 300% (mit aktiviertem Anti-Aliasing, vorher wars dagegen ohne) war dabei so einfach wie effektiv das klassische Batching von Geometrie, bis zu 32.000 Linien batche ich nun, bevor ich sie am Stück rendere.
Das Erstaunliche ist, dass sich die Zahl der Draw-Calls dabei nicht verringert hat, lediglich die Zahl der State-Changes zwischen den Draw-Calls wurde drastisch reduziert (praktisch alle eliminiert), die Linien zeichne ich jedoch nach wie vor per Einzelaufruf von Graphics2D.drawLine(). Das Batching ist natürlich komplett in Java implementiert, einfach ein riesen int-Array, das die 2 Koordinatenpaare eines Liniensegments in 4 Komponenten hintereinander weg speichert und später malt. Mal ein Trost nach tagelangem Kampf mit der kaputten NIO-API. ;-)
Das Erstaunliche ist, dass sich die Zahl der Draw-Calls dabei nicht verringert hat, lediglich die Zahl der State-Changes zwischen den Draw-Calls wurde drastisch reduziert (praktisch alle eliminiert), die Linien zeichne ich jedoch nach wie vor per Einzelaufruf von Graphics2D.drawLine(). Das Batching ist natürlich komplett in Java implementiert, einfach ein riesen int-Array, das die 2 Koordinatenpaare eines Liniensegments in 4 Komponenten hintereinander weg speichert und später malt. Mal ein Trost nach tagelangem Kampf mit der kaputten NIO-API. ;-)
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Anti-Jammer-Thread
Endlich hab ich auch mal was zu anti-jammern...
Ich hab nach langer Arbeitspause an meinem toXic-Framework weitergemacht, auf neuem Betriebssystem, dementsprechend, erstmal alles neu einrichten usw.
Und trotzdem haben Heightmap und Skybox sofort funktioniert (Lacht nur, für mich ist sowas Hightech ;) )
Ich hab nach langer Arbeitspause an meinem toXic-Framework weitergemacht, auf neuem Betriebssystem, dementsprechend, erstmal alles neu einrichten usw.
Und trotzdem haben Heightmap und Skybox sofort funktioniert (Lacht nur, für mich ist sowas Hightech ;) )
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ich habe nach fünf Jahren gerade mal einen halben Himmel ohne Heightmap … aber das ist vllt der falsche Thread für sowas.SunCross hat geschrieben:Und trotzdem haben Heightmap und Skybox sofort funktioniert (Lacht nur, für mich ist sowas Hightech ;) )
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Drei Jahre hab eich gewartet dass sich die Mögichkeit bietet
Jetzt konnte ich zuem ersten Mal operator ?: als lvalue einsetzen
(halfGlareResolution ? resolveSceneToHalfSize : resolveScene).bindTo(GPUContext);
Mein C++-Können ist nun endlich vollkommen
Nein, sieh mir dabei in die Augen
vollkommen
Jetzt konnte ich zuem ersten Mal operator ?: als lvalue einsetzen
(halfGlareResolution ? resolveSceneToHalfSize : resolveScene).bindTo(GPUContext);
Mein C++-Können ist nun endlich vollkommen
Nein, sieh mir dabei in die Augen
vollkommen
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Das Verhältnis von Roh- zu Nutzleistung hat sich auf Nvidia-Karten normalisiert. Es ist jetzt genau so schlecht wie bei AMD, nicht mehr schlechter. Über Nacht fand 30 % mehr Leistung ihren Weg in meinen Schoß … ich weiß zwar nicht, warum, aber ich nehme dieses gottgegebene Geschenk einfach mal dankend und unskeptisch an.
Re: Anti-Jammer-Thread
Ich hab gerade endlich den Zugriff auf meine USB-Platine hingekriegt. Der COM-Port (die Platine ist zwar mit USB angeschlossen, emuliert aber, glaube ich, eine RS232-Schnittstelle) muss per unsigned char an die Open-Funktion des Treibers übergeben werden.
Also hab ichs wie folgt versucht:
So gings nicht, die Funktion gab mir FALSE zurück. obwohl augenscheinlich alles genau so war, wie in den beigelegten Beispielen.
Gerade ist mir eingefallen, man könne mal aus Langeweile so vorgehen:
Und siehe da...es klappt :)
Also hab ichs wie folgt versucht:
Code: Alles auswählen
unsigned char port = '4'; // COM-Port 4
HB628_Open (port, 5000); // 5000 ms Suchzeit
Gerade ist mir eingefallen, man könne mal aus Langeweile so vorgehen:
Code: Alles auswählen
int i = 4;
unsigned char port = (unsigned char) i;
HB628_Open (port, 5000);
- Krishty
- Establishment
- Beiträge: 8265
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
'4' ist der Wert des ASCII-Zeichens 4, also der Zahlenwert 52 … ohne die Hochpunkte würdest du den Wert 4 zuweisen ;)
Re: Anti-Jammer-Thread
Verdammt, du hast Recht...danke :)
sieht auch direkt 10-mal besser aus als meine cast-Lösung.
EDIT:
Hat hier zufällig jemand Erfahrung mit dem USB-I/O-Modul "HB628" ?
Ich hab da noch ein, zwei kleinere Probleme...
Code: Alles auswählen
port = 4;
EDIT:
Hat hier zufällig jemand Erfahrung mit dem USB-I/O-Modul "HB628" ?
Ich hab da noch ein, zwei kleinere Probleme...
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: Anti-Jammer-Thread
In den örtlichen Kieler Nachrichten hat sich jemand per Anzeige entschuldigt, dass er bei den letzten 2 Wahlen die FDP gewählt hat. :mrgreen: :mrgreen:
Imaging-Software und bald auch Middleware: http://fd-imaging.com
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: Anti-Jammer-Thread
WHOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
idTech5 wird Open Source!
idTech5 wird Open Source!
Imaging-Software und bald auch Middleware: http://fd-imaging.com
Re: Anti-Jammer-Thread
Ja, aber erst in ein paar Jahren.j.klugmann hat geschrieben:idTech5 wird Open Source!
http://www.bluesnews.com/s/118258/tech- ... rification
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: Anti-Jammer-Thread
Trotzdem. :)
Imaging-Software und bald auch Middleware: http://fd-imaging.com