Jammer-Thread

[hagbard]

Ganz ehrlich gesagt wundert mich überhaupt dass sie sowas supporten. Ich wäre jedenfalls niemals auf die Idee kommen dass das funktioniert und hätte mir für 64-Bit Code extra ein 64Bit-Dual-System eingerichtet zum kompilieren und testen. Manchmal kann Paranoia auch hilfreich sein um Probleme zu umschiffen. :mrgreen:

[Krishty]

1>X.cpp(326): error C2248: 'INonCopyAssignable::operator =' : cannot access private member declared in class 'INonCopyAssignable'
1> X.hpp(547) : see declaration of 'INonCopyAssignable::operator ='
1> X.hpp(538) : see declaration of 'INonCopyAssignable'
1> This diagnostic occurred in the compiler generated function 'CChunk &CChunk::operator =(const CChunk &)'

Großartig. Der Compiler erzeugt also irgendwo einen Zuweisungsoperator, den ich verboten habe. Und sagt mir nicht, wo. Soll ich jetzt einfach alle Stellen in meinem Text durchgehen, wo = steht, oder was?!

[Helmut]

Hm, du könntest den Operator ja mal testweise implementieren und einen Breakpoint reinsetzen ;)

[Krishty]

Das wäre nichts geworden – der Compiler brauchte den Operator zum Umherschieben in einem vector; der war aber immer mit einer solchen Größe allokiert, dass ein Umherschieben nie geschehen wäre. Ist doch echt ein Kreuz.


Chrome ohne GPU-Verarbeitung

woGPU.png (1.71 KiB) 2896 mal betrachtet

und mit:

wGPU.png (1.55 KiB) 2896 mal betrachtet

Was mir ja egal wäre, würde die nicht jedes Mal wieder anspringen, wenn man ein Ogg anklickt.

Ich verstehe auch ehrlich gesagt nicht, wie man es ausgerechnet bei sowas verkacken kann, Texel präzise auf Pixel zu mappen. Das ist so ziemlich das Fundamentalste, was es da zu tun gibt und wird seit WDDM standardmäßig von der Hardware durchgeführt. Ups, ist garkein Texel-zu-Pixel-Problem sondern Jörg erleuchtet mich gerade, dass einfach ClearType abgeschaltet wurde.

[Chromanoid]

verkacktes debug/release modus chaos. erst mal drei stunden meinen ganzen code mehr oder weniger zufällig verändert bis ich dann endlich auf diese weise rausgefunden habe, dass im debug modus beim rendern eines screen aligned quads
d3dDevice->Clear( 0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER|D3DCLEAR_STENCIL, 0, 0.0f, 0);
funktioniert und im release modus nicht. da muss man
d3dDevice->Clear( 0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER|D3DCLEAR_STENCIL, 0, 1.0f, 0);
schreiben. hat irgendjemand ne ahnung woran zum teufel das liegt?

[Schrompf]

Was heißt denn "nicht funktionieren"? Scheitert der Funktionsaufruf? Oder siehst Du nur nix?

Solche Unterschiede zwischen Debug und Release sind meistens der Tatsache geschuldet, dass im Debug alle Variablen und Speicherbereiche einen definierten Wert bekommen, im Release dagegen Zufall drinsteht. Evtl. renderst Du also mit einem unsinnigen Tiefenwert und hast in einem Konstruktor irgendeiner Deiner Klassen irgendeinen klitzekleinen Bool zu initialisieren vergessen.

[Chromanoid]

ich mache eigentlich nichts außer sofort ein rendertarget mit einem pixelshader zu füllen. wird 0.0 in den z-buffer gehauen, wird nur im debug modus gerendert... eigentlich läuft kein anderer code vor dem kram...demnächst deaktiviere ich einfach den z-buffer für sowas -.-

[Schrompf]

Welchen Tiefenwert haben denn die Vertizes des Bildschirm-Rechtecks?

[Chromanoid]

0 nehme ich an...

[Schrompf]

Jetzt wird's wirr. Was heißt denn "Du nimmst an"? Womit füllst Du die Vertizes denn?

[Chromanoid]

Ah :) noch mal geschaut, mit 1... trotzdem irgendwie seltsam, dass es im debug geht und im release nicht.

[CodingCat]

Code: Alles auswählen

#include <limits>
#include <iostream>
 
template <class Type>
struct some_source
{
        static const Type value;
};
 
template <class Type> const Type some_source<Type>::value = Type(
                (std::numeric_limits<Type>::min() != Type())
                        ? std::numeric_limits<Type>::min()
                        : std::numeric_limits<Type>::max()
        );
 
template <class Type>
struct some_dest
{
        static const Type value;
};
 
template <class Type> const Type some_dest<Type>::value(some_source<Type>::value);
 
int main()
{
   int dest = some_dest<int>::value;
   int source = some_source<int>::value;
 
   std::cout << "Dest: " << dest << "; Source: " << source << std::endl;
 
   return 0;
} 

Dest: -2147483648; Source: -2147483648 (siehe Testlauf)

Dest: 0; Source: -2147483648

Mein Gott, mein Gott, warum hast du mich verlassen?

[joggel]

Tja, Cat... diese Frage...
Diese und ander bohrenden Fragen


Weiß zwar nicht was Du genau da machst, aber Du hast mein Beileid!!

[CodingCat]

So, nach über einer Stunde Wartezeit die Gewissheit: auch VS 2010 SP1 ändert nichts, "Abhilfe" schafft eine Methode:

Code: Alles auswählen

#include <limits>
#include <iostream>
 
template <class Type>
struct some_source
{
        static const Type value;

		static Type get_value()
		{
			return (std::numeric_limits<Type>::min() != Type())
                        ? std::numeric_limits<Type>::min()
                        : std::numeric_limits<Type>::max();
		}
};
 
template <class Type> const Type some_source<Type>::value = get_value();
 
template <class Type>
struct some_dest
{
        static const Type value;
};

template <class Type> const Type some_dest<Type>::value = some_source<Type>::get_value();
 
int main()
{
   int dest = some_dest<int>::value;
   int source = some_source<int>::value;
 
   std::cout << "Dest: " << dest << "; Source: " << source << std::endl;
 
   return 0;
} 

Nachtrag: Verfolgen Sie die Ereignisse in unserem Live-Ticker.

[Krishty]

error C2622: member 'foo' of union 'bar::<unnamed-tag>' has assignment operator
Entweder hat heute nacht heimlich jemand alle meine Dateien von .cpp zu .c umbenannt oder C++’03s Definition von POD ist tatsächlich lächerlich

[CodingCat]

Ich bin stolz auf mich: Profile meine frisch gebackene Hash-Map-Klasse; Suche in optimierter und deshalb nahezu unlesbarer Disassembly nach der Ursache für die unerklärlich unterirdische Performance - Nur um irgendwann festzustellen, dass ich meine gedankenlos gewählten Test-Schlüssel-Strings zufällig genau so generiere, dass sie unter Einsatz der Standard-Hash-Funktionen der VC10-TR1-Implementierung ein meiner Willkür vollkommen unangemessenes Maximum an Kollisionen herbeiführen. Tatsächlich treffe ich bei nahezu jeder Insert-Operation mehrere belegte Slots (offenes Hashing), dabei habe ich 10000 davon, schlimmer noch, die Hash-Funktion springt praktisch zwischen einem Dutzend fester Werte hin und her. :lol:

[j.klugmann]

GIbt's auch ein paar Werte von dir, wenn du soweit fertig bist? Ich würde gerne mal ein paar Vergleichswerte für meine Hashmaps sehen.

[CodingCat]

Und weiter gehts gleich nach der nächsten Maus...

Code: Alles auswählen

#include <iostream>
#include <string>

struct int_test_class
{
   int i;
   int_test_class(int i) : i(i) { }
};
void int_test(const int_test_class &o)
{
   std::cout << "int_test:cref; "; 
}
void int_test(int_test_class &&o)
{
   std::cout << "int_test:rvref; "; 
}

struct char_test_class
{
   const char *c;
   char_test_class(const char *c) : c(c) { }
};
void char_test(const char_test_class &o)
{
   std::cout << "char_test:cref; "; 
}
void char_test(char_test_class &&o)
{
   std::cout << "char_test:rvref; "; 
}

void string_test(const std::string &o)
{
   std::cout << "string_test:cref; "; 
}
void string_test(std::string &&o)
{
   std::cout << "string_test:rvref; "; 
}

int main()
{
   std::cout << "Implicit: ";
   int_test(5);
   char_test("a");
   string_test("a");
   std::cout << std::endl;
   
   std::cout << "Explicit: ";
   int_test(int_test_class(5));
   char_test(char_test_class("a"));
   string_test(std::string("a"));
   std::cout << std::endl;

   return 0;
}

Implicit: int_test:rvref; char_test:rvref; string_test:rvref;
Explicit: int_test:rvref; char_test:rvref; string_test:rvref; (siehe Testlauf)

Implicit: int_test:rvref; char_test:cref; string_test:cref;
Explicit: int_test:rvref; char_test:rvref; string_test:rvref;

Man beachte die besonere Relevanz für temporäre std::strings bei der Übergabe von C-Strings, die in VC2010 ohne explizite Casts auf diese Weise trotz R-Value-References nach wie vor unnötig kopiert werden. Verfolgen Sie die Ereignisse im Live-Ticker.

[CodingCat]

Der Microsoft-Compiler liebt es offenbar, den Rumpf von if-Anweisungen zu vergrößern, um die Zahl potentieller Speicherzugriffe zu verringern. So weit so löblich, leider findet das Entfernen toter Code-Zweige erst im Anschluss daran statt, der Compiler versagt aufgrund des gegenüber dem ursprünglichen C++-Quelltext vielfach weniger linearen Programmablaufs dabei kläglich (hier müsste er nun tatsächlich den Ausgang vorangegangener Vergleiche nutzen oder gar alle möglichen Pfade auswerten, um Annahmen über Registerinhalte treffen zu können).

Nebenbei: Der im vorangegangenen Post geschilderte Bug wird in der nächsten VS-Version behoben sein, siehe MS-Connect-Link. Und irgendein geistig umnachteter Nutzer hat sich doch tatsächlich angemaßt, dieses Fehlverhalten als unwichtig einzustufen.

[mirlix]

Ich finde es doch irgendwie witzig das ein Entwickler der VC++ Lib als email stl@.. hat, da die Anfangsbuchstaben seines Namen das ergeben, das muss Vorherbestimmung gewesen sein ;)

[Chromanoid]

LaTeX ist die schlechteste Erfindung mit dem hübschesten Output, die ich je gesehen habe. Benutzerunfreundlichkeit wird ganz neu definiert. Eine neue Schriftart installieren ist nerviger als mein System neu aufzusetzen -.-

[Alexander Kornrumpf]

Hmm, ist halt die Frage ob man wirklich mehr als 4 Schriftarten braucht :) Die Schriftarten die im package manager drin sind, sind ja auch problemlos installiert.

[Krishty]

Erinnert sich noch jemand, wie ich vier Monate suchen musste, bevor ich endlich herausgekriegt habe, wie sich HLSL-Objekte bei out-of-Bounds-Zugriffen verhalten? Das Ergebnis war: Laden gibt Null zurück, Schreiben ist No-Op. Womit ich sehr gut leben kann.

Jetzt lese ich im DirectX-Forum (von einem Typen des Compiler-Teams):

Any out of bounds write results in the entire UAV having undefined contents, so you should go ahead and guard it

Nochmal auf apokalyptisch: Ein out-of-bounds-Schreiben und alles ist undefiniert. Falls das stimmt, ist das der GAU und ich kann alle meine Shader samt entsprechender Frontends überarbeiten.
Aus diesen DirectX-Kaspern ist auch wirklich keine einzige Information rauszukriegen, und wenn doch, dann widerrufen sie sie drei Monate später. Sauladen.

[anonym]

da ich mich das schon lange frage: gibt es keine genauere hlsl-spezifikation als das bisschen, das in der sdk-dokumentation mitkommt?

[Krishty]

da ich mich das schon lange frage: gibt es keine genauere hlsl-spezifikation als das bisschen, das in der sdk-dokumentation mitkommt?

Doch. Aber die ist Teil der kompletten Direct3D-Spezifikation, und da kommt man nur als Hardware-Lieferant dran. Bleiben nur tröpfchenweise Fakten aus Power-Point-Präsentationen auf Veranstaltungen, wo Leute aus dem DirectX-Team sprechen.

Das mit den Out-of-Bounds-Zugriffen hat sich zum Glück erledigt – war eine Verwechslung mit Gruppenspeicher, wo das tatsächlich haarsträubende Ergebnisse haben kann. Nicht erst bei der Ausführung, sondern schon beim Kompilieren, weil die auf Zugriffsverletzungen testen indem sie … Zugriffsverletzungen auslösen. Aber das ist eine andere Geschichte.

[Krishty]

Mir ist gerade die Gültigkeitsprüfung von Bytecode explodiert als ein negativer Sprung reinkam, weil int + unsigned int in C++ unsigned int ergibt. … kotzen, … essen will.

[Krishty]

Code: Alles auswählen

struct Foo {
    int x;
    int * y;
};

class Program {
    Foo myFooArray[1000];

    Program()
        : myFooArray()
    { }

};

myFooArray wird genullt.

Code: Alles auswählen

struct Foo {
    int x;
    int * y;

    ~Foo() {
        delete y;
    };
};

class Program {
    Foo myFooArray[1000];

    Program()
        : myFooArray()
    { }

};

myFooArray wird ge0xCCCCCCCCt.

Dabei habe ich extra für diesen Fall getestet, ob man Foo test = { 1, nullptr }; schreiben kann. Allerdings gilt die Default Initialization == Value Initialization == Zero Initialization-Regel nur für PODs (was Foo nicht ist, denn es hat ja einen D’tor), nicht für Aggregates (wie Foo es ist).

Ich blicke nach Jahren immernoch nicht durch die scheiß Initialisierungsregeln durch und das

kotzt

mich

an.

[j.klugmann]

Lern Haskell. ;)

[Lynxeye]

Noch ein ganz besonderes Geschenk für Krishty:

GPU optimization tip: you can beat the compiler, don't be lazy, try different instruction and texture fetch orderings and groupings by hand!

Übersetzt etwa: nach Jahren der Arbeit an unserem Shadercompiler schaffen wir es immer nicht guten Output für unsere Grafikkarten zu erzeugen. Also Entwickler macht doch bitte weiterhin das, was eigtl. unser Compiler können sollte.

[Krishty]

GPU optimization tip: you can beat the compiler, don't be lazy, try different instruction and texture fetch orderings and groupings by hand!

Echt jetzt
Das ist doch unglaublich
Bei AMD musste ich GENAU DAS machen um das Programm überhaupt in Echtzeitfähige Bereicche zu hieven
Und dachte mia:
Nächstes mal wirds Nvidia
Kann ja nicht noch schlimmer werden
*Hieer Furzgeräusch einsetzen*

Lern Haskell. ;)

Bei der Sprachwahl ist des doch wiee bei der poltischen Wahl
Man wähtl nicht die beste Parteii, sondern das kleinste Übel was einen die nächsten Jahre am wenigsten pfählt
Und dann noch dje Compiler dabei
Steinzeit alles
Nicht, dass ich ein gottgegebenenes Geschenk an die Informatik wäre und das besser könnte, aber
das ist doch desaströs alles

Ps.: Ich bin in meinen Projekten nun vollends darauf umgestiegen, nur in der ENtwurfsphase Shader-Quelltext zu verwenden. JSobald es an die Beta geht, wird nurnoch kompilierter Bytecode beigelegt. Die gefühlte SJtartzeit halbiert sich mindestens. Das ist derr einzige Punkt, wo Nvidias Und ATIs Compiler NICHT schrott sind: Sie sidn immernoch 1000× (das ist nicht übertrieben) schneller als Microsofts HLSL-Compiler.