Jammer-Thread

[CodingCat]

Ja sowas geht per extern. Mit VC schon praktisch immer und seit C++11 auch im Standard, verwend ich ab und zu ganz gern...

Naja, mit extern geht das Ganze doch gerade wieder kaputt. Wir wollen hier schließlich einen implementierungsunabhängigen Header, und nicht für jede Spezialisierung noch einen redundanden extern-Header. Aber VC10 schluckt mein Beispiel von eben tatsächlich willig. In dieser Form sind Templates durchaus eine hübsche Alternative zu #ifdefs.

[eXile]

Es ist ein Dateiformat, das Bytecode enthält, der eine virtuelle Maschine kontrolliert, die den Rasterizer Vertex für Vertex steuert – durch 200 Opcodes inklusive Subroutinen; Schleifen; bedingter Sprünge; und allem anderen, was einem das Leben schwer macht.

[CodingCat]

what's changed in fxc from 9.29.952.3111 to 9.30.960.8229 (the one from win8 SDK) ?!

couse with 9.29.952.3111 (/O3 /Op /Gfp /Zpr /Tcs_5_0) all my compute shaders compile and run JUST FINE (about 70 different kernels - they all pass unit tests)
but with 9.30.960.8229 (/O3 /Op /Gfp /Zpr /Tcs_5_0) about 70% of my compute shaders FAILS that same unit tests !!!

they fail mainly around atomic operations on shared memory (and some of them on atomic on RWByteAddressBuffer) - the 'old' value returned from InterlockedAdd is total garbage
(looking at disassembly the return value in register is thrown away and the other unrelated register is taken as 'out' value by compiller)

few of them (purelly ALU kernels without atomics) fail on math operations (or index calculations for indexing ByteAddressBuffer - it's hard to tell without debugger ;])

http://forums.create.msdn.com/forums/t/103143.aspx

Ich glaube, damit ist DX 11.1 für mich erstmal wieder gestorben ...

[Krishty]

wtf :D

Wer macht denn sowas :shock:

Das muss vor 20 Jahren mal ziemlich effizient gewesen sein: Damals gab es keine Z-Buffer, und statt die Polygone im Programm zu sortieren, wurden sie zu Bytecode kompiliert, der sie je nach Betrachtungswinkel in der korrekten Zeichenreihenfolge ausspuckt. Und wenn man eh schon Sprünge drin hat, kann man auch Animationen u.Ä. damit realisieren und muss sich in der eigentlichen Programmlogik um nichts weiter kümmern, als ein paar Variablen hochzuzählen und die VM machen zu lassen.


Aaalso, bezüglich der Templates:

Das Template ist die Hauptschleife der virtuellen Maschine. Die ist ein riesiges fettes Stück von 8000 Zeilen; da hängen nochmal 2000 Zeilen privater Abhängigkeiten dran; und mit zunehmender Optimierung wird es auch immer mehr Text. Ich weigere mich deshalb vehement, die Definition in irgendeinen Header zu stecken – sie wird nur in logic.hpp deklariert:

template <bool debug> void run(IRasterizer & r);

Es gibt nun eine logic.cpp, in der sie definiert wird:

template <
    bool debug // 'if's mit globalen Variablen kosten 2,7 % Leistung gegenüber 'if's mit Template-Parametern, Branch Prediction und OOOE am Arsch
> void run(IRasterizer & r) {
    r.draw();
    // lots
    // of
    // fucking
    // complicated
    // stuff
}

Dort werden gleichzeitig Instanzierungen ausgelöst, damit die von den Übersetzungseinheiten, die sie aufrufen, gefunden werden können (fehlende spitze und runde Klammern beachten, da es sich nicht um Funktionsaufrufe oder Spezialisierungen handelt):

template void run<true>;
template void run<false>;

Schließlich, im GUI-Teil:

if(isInDebugMode) {
    run<true>(myRasterizer);
} else {
    run<false>(myRasterizer);
}

Nehmen wir rein hypothetisch an, ich machte nun den Rasterizer zu einem Template-Parameter, damit die Funktionsaufrufe nicht mehr durch die Schnittstelle gehen müssten. Das wäre bei der Deklaration der Funktion kein Problem; beim Aufruf auch nicht, weil ich dort den endgültigen Rasterizer-Typ kenne. Bei der Definition der Funktion flöge ich aber auf die Schnauze: Um das Template für den Rasterizer instanzieren zu können, brauche ich den Quelltext. Ich müsste also die Definition der VM-Template-Funktion aus der Logik herausziehen, und im Rasterizer- oder GUI-Quelltext mitsamt aller Abhängigkeiten #includen, um dort die Instanzierung mit dem definierten und bekannten Rasterizer als Template-Parameter auszulösen.

Möglich wäre es schon, aber ich würde es hassen. Das soll der Compiler für mich machen; der kennt sowieso das ganze Programm und muss sich nicht darum scheren, Logik und Rasterizer und GUI getrennt zu halten um in diesem Irrsinn nicht dem Wahnsinn zu verfallen …

[CodingCat]

Bei der Definition der Funktion flöge ich aber auf die Schnauze: Um das Template für den Rasterizer instanzieren zu können, brauche ich den Quelltext. Ich müsste also die Definition der VM-Template-Funktion aus der Logik herausziehen, und im Rasterizer- oder GUI-Quelltext mitsamt aller Abhängigkeiten #includen, um dort die Instanzierung mit dem definierten und bekannten Rasterizer als Template-Parameter auszulösen.

Ja, es sei denn, du begnügst dich mit Forward Declarations der Rasterizer-Implementierungen und freien Funktions-Templates. :|

[Krishty]

es sei denn, du begnügst dich mit Forward Declarations der Rasterizer-Implementierungen und freien Funktions-Templates. :|

Kluges Kätzchen! Freie Funktionen und Funktionsparameter lassen sich perfekt vordeklarieren. Statt rasterizer.draw(vertex); müsste ich also draw(vertex, rasterizer); schreiben, könnte aber dafür die Implementierung der draw-Funktion zur Implementierung des Rasterizers verschieben. Clever. Kriegst auch ein Brekkie.

[CodingCat]

Jep. Das Grundproblem, das Klassen im C++-Modulsystem streng genommen unbrauchbar macht. :evil:

[CodingCat]

Die Debug Runtime meckert: Texture2D-HLSL-Objekte sind nicht kompatibel mit einelementigen Texture2DArray-Views. Tatsächlich funktioniert das aber prima, wie ich es von einer vernünftigen API auch erwartet hätte. Diese ganze Pseudoabstraktion steht mir bis hier oben, soll ich jetzt ernsthaft sämtlichen HLSL-Code für beide Fälle identisch kopieren? :twisted:

[Artificial Mind]

/usr/bin/ld: warning: libnvidia-tls.so.280.13, needed by /usr/lib/nvidia-current/libGL.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libnvidia-glcore.so.280.13, needed by /usr/lib/nvidia-current/libGL.so, not found (try using -rpath or -rpath-link)
/usr/lib/nvidia-current/libGL.so: undefined reference to `_nv018tls'
...

Ich bekomme CUDA auf Linux nicht zum Laufen weil ich den 295er Treiber habe, aber CUDA anscheinend den 280er haben möchte ... oder irgend sowas. Wieso kann man auf Linux nichts einfaches haben? Wieso kann das nicht im Repo liegen und mit sudo apt-get install nvidia-cuda oder so ohne Probleme funktionieren ... gut wie man produktiv man auf Linux ist, wenn man irgendwas installieren möchte, was nicht im Repo ist.

EDIT: Ich bin über jeden Lösungsvorschlag erfreut!

[simbad]

Mach nen symbolischen link
ln -s <source> <destination>

[Artificial Mind]

und das ist ok, selbst wenn das unterschiedliche Versionen sind? Oo

Es schien nur ein Pfad in der ld.so.conf zu fehlen, denn die gewünschten Libs waren irgendwo bei CUDA dabei...

[antisteo]

Wieso kann man auf Linux nichts einfaches haben? Wieso kann das nicht im Repo liegen und mit sudo apt-get install nvidia-cuda oder so ohne Probleme funktionieren ... gut wie man produktiv man auf Linux ist, wenn man irgendwas installieren möchte, was nicht im Repo ist.

EDIT: Ich bin über jeden Lösungsvorschlag erfreut!

Du kannst nicht alles haben.
Du kannst nicht erwarten, dass die OpenSource-Community dir proprietäre Treiber pflegt.
Lösungsvorschlag: An Mesa mitwirken, sodass NVIDIA auch einen OpenSource-Treiber für OpenCL/CUDA bekommt.

[Artificial Mind]

Ist es nicht auch in NVIDIAs Interesse, einen vernünftigen Support und einfachen Einstieg in CUDA zu haben, auch für Linux?

Deinen Lösungsvorschlag finde ich ok, sobald ich genügend Erfahrung habe, um auch wirklich eine Hilfe sein zu können, werde ich mir das auch ernsthaft überlegen.

[antisteo]

Ist es nicht auch in NVIDIAs Interesse, einen vernünftigen Support und einfachen Einstieg in CUDA zu haben, auch für Linux?

Ja,
mit ihrem proprietären Treiber.

Deinen Lösungsvorschlag finde ich ok, sobald ich genügend Erfahrung habe, um auch wirklich eine Hilfe sein zu können, werde ich mir das auch ernsthaft überlegen.

Feel free.
Der erste Schritt ist sowieso, den Sourcecode des bisherigen Treibers zu lesen und ein bisschen Daten-Mitschnitte zur Grafikkarte analysieren.

[CodingCat]

GPU Computing - wenn alles richtig aussieht, und doch nichts geht. Wie schön, dass man nicht reingucken kann (wenn NSight mal nicht abstürzt, zeigt es mir ausgerechnet das, was mich am wenigsten weiterbringt).

Stream Compaction

[CodingCat]

Man kommt ja doch nicht drumrum: Debug Kernels mit Farbkodierung. Grün heißt korrekt. Nichts geht. Jetzt beginnt der Spaß. Zurück in den Jungle von Resource Bindings.

Green means correct

[eXile]

Dürfte ich eigentlich fragen, ob du die GUI (auch irgendwo auf einem älteren Screenshot besser zu sehen; hier nur in der unteren linken Ecke zu sehen) selbst programmiert hast, oder irgendeine Library dafür benutzt hast?

[Jonathan]

Dürfte http://www.antisphere.com/Wiki/tools:anttweakbar sein. Hab ich auch damals für den Aufbaustrategiebeitrag vom dritten Zfx-Action benutzt.

[CodingCat]

Ja, Jonathan hats erkannt.

[eXile]

Warum scheißt einem C++ in die Suppe, wenn man es gerade am wenigsten gebrauchen kann? (Ich frage mich eher, warum ich jetzt erst auf dieses Problem stoße.)

Achja, unique_ptr<void> geht natürlich auch nicht, aber das hätte ich auch nicht erwartet, sondern wäre vom Gegenteil überrascht gewesen. Ist auch besser so.

[Artificial Mind]

C++/CLR um WPF Applikationen zu schreiben, die auch mal die Windows.h brauchen.

Code: Alles auswählen

mWindow->FindResource("something");

compiled nicht, da es ein

Code: Alles auswählen

#define FindResource FindResourceW

in der Windows.h gibt.
Ja, man kann es undefinen. Toll ist das trotzdem nicht.

[Jonathan]

Ja, man kann es undefinen. Toll ist das trotzdem nicht.

Also ich kenn nix schlimmeres, als die windows.h. Wenn auf einmal dein Vectorklassen-min-Template nicht mehr kompiliert wegen einer komischen Meldung die du nicht verstehst, ist das echt so ziemlich das nervigste, was es gibt. Kann man sich drüber aufregen, nützt aber wohl nichts. Wenn man den Fehler einmal kennt, kann man ihn ja auch recht schnell beheben.

[Krishty]

Ja, es sei denn, du begnügst dich mit Forward Declarations der Rasterizer-Implementierungen und freien Funktions-Templates. :|

Freie Funktionen waren mit dem Rasterizer außerordentlich hässlich, darum habe ich das Folgende gemacht, was ich einfach mal Krishty's static single-overridden virtual method dispatching-Muster nenne:

// Rasterizer.hpp
    class Rasterizer {
    public:
        void draw(…); // NICHT virtual
    };


// Rasterizer.cpp
    // Leer!


// Model.cpp
    void drawModel(Rasterizer & r) {
        r.draw(…);
        …
    }


// D3D9Rasterizer.hpp
    class D3D9Rasterizer : public Rasterizer {
    public:
        void draw(…); // immernoch nicht virtual
    };


// D3D9Rasterizer.cpp
    void D3D9Rasterizer::draw(…) {
        // Mein Sorgenkind
    }

    // Die Magie!
    void Rasterizer::draw(…) {
        return static_cast<D3D9Rasterizer *>(this)->draw(…); // this is gonna be so inlined
    }


Damit habe ich ca. 6 % Leistungsplus gegenüber virtuellen Methoden einkassiert* und abgesehen davon, dass die Implementierung der Basismethoden im Quelltext zur Implementierung der endgültigen Methoden gewandert ist, hat sich nichts geändert. Katzeschööööön!

————
* Meine Maschine ist seit ein paar Tagen ausgelastet, darum rauschen die Messungen sehr. Jedenfalls zwischen 5 und 9 %.

[Krishty]

Ja, man kann es undefinen. Toll ist das trotzdem nicht.

Also ich kenn nix schlimmeres, als die windows.h. Wenn auf einmal dein Vectorklassen-min-Template nicht mehr kompiliert wegen einer komischen Meldung die du nicht verstehst, ist das echt so ziemlich das nervigste, was es gibt. Kann man sich drüber aufregen, nützt aber wohl nichts. Wenn man den Fehler einmal kennt, kann man ihn ja auch recht schnell beheben.

Darum benutze ich nur noch selber verfasste Windows-Header.

[dot]

Ja, man kann es undefinen. Toll ist das trotzdem nicht.

Also ich kenn nix schlimmeres, als die windows.h. Wenn auf einmal dein Vectorklassen-min-Template nicht mehr kompiliert wegen einer komischen Meldung die du nicht verstehst, ist das echt so ziemlich das nervigste, was es gibt. Kann man sich drüber aufregen, nützt aber wohl nichts. Wenn man den Fehler einmal kennt, kann man ihn ja auch recht schnell beheben.

exakt: #define NOMINMAX ;)
Für das Problem dass viele "Funktionen" eigentlich Makros sind, gibts aber leider keine Lösung...

[CodingCat]

Freie Funktionen waren mit dem Rasterizer außerordentlich hässlich, darum habe ich das Folgende gemacht, was ich einfach mal Krishty's static single-overridden virtual method dispatching-Muster nenne: [...]

Ja, dieses Muster nutze ich auch für einige Rendering-bezogene Klassen.

[Jonathan]

Ohne jemanden zu nahe treten zu wollen, aber: Assimp Materialien sind eine Qual. Bei den ganzen Makros und Funktionsparametern die Kombination zu finden, die den Wert liefert/setzt den man haben will, so dass es kompiliert und nicht abstürzt ist echt derbe fummelig. Und die Dokumentation ist auch nur sehr begrenzt hilfreich, weil nur Makros aufgelistet werden (vor die man noch einen 'versteckten' Präfix packen muss), aber nicht, wie die jetzt genau auf die generellen get/set Funktionen passen. Und was "The MATKEY_UVWSRC property is only present if the source format doesn't specify an explicit mapping from textures to UV channels." heißen soll, versteh ich auch nicht (der Attribut, welche Textur welchen Uv-Channel benutzt ist nur vorhanden, wenn dies in der Modelldatei nicht stand? Häh?)
Ich weiß, das Zeug ist alt und C-Kompatibel, aber für mich ist halt 'Materialwert abfragen', etwas, das man mit nachschlagen innerhalb von 30 Sekunden hinkriegen können sollte.

[eXile]

Wie wäre es mit

Die MATKEY_UVWSRC-Eigenschaft ist nur vorhanden, falls das Quellformat keine explizite Abbildung von Texturen zu UV-Kanälen vorgibt.

Aber das ändert ja an deiner dargelegten, grundsätzlichen Problematik nichts. ;)

[Schrompf]

Ich empfinde das Design der Material-Strukturen und Methoden auch als unglücklich. Mir fallen aber als Alternativen auch nur Ansätze ein, die andere Probleme hätten, und ich habe nicht die Zeit, um alternative Ideen umzusetzen. Zumal wir in Anbetracht der inzwischen beachtlichen Nutzeranzahl auch für Abwärtskompatibilitär sorgen müssten, wenn wir da was neues erfinden.

[Jonathan]

Wie wäre es mit

Die MATKEY_UVWSRC-Eigenschaft ist nur vorhanden, falls das Quellformat keine explizite Abbildung von Texturen zu UV-Kanälen vorgibt.

Aber das ändert ja an deiner dargelegten, grundsätzlichen Problematik nichts. ;)

Versteh ich immer noch nicht. Ich will doch bloß wissen, welche Textur welchen Uv-Channel benutzt. Was genau ist da mit Abbildung gemeint? Entweder man hat UV-Maps, oder generiert die halt, aber das wird doch durch MATKEY_MAPPING gesteuert?

Zum Thema neues erfinden: Vielleicht wäre es ja möglich, neue Get/Set Methoden dazuzupacken, die ohne diese seltsamen Makros und so auskommen. Man könnte die alten immernoch benutzen, aber eben auch die schönen, neuen.
Jetzt zum Beispiel hab ich:

Code: Alles auswählen

aiMaterial->Get(AI_MATKEY_UVWSRC(0, DiffuseId), &UvChannel, 1);

(analog zum setzen) und bekomme:

error C2664: 'aiReturn aiMaterial::Get<int>(const char *,unsigned int,unsigned int,int *,unsigned int *) const': Konvertierung des Parameters 5 von 'int' in 'unsigned int *' nicht möglich

und der Fehler sagt mir erstmal rein gar nichts. Und weder ein Blick in die Doku über das Makro und die Get-Funktion sagt mir, was da jetzt falsch ist, weil die Get-Parameter so generisch sind, dass ich keine Ahnung hab, wofür sie eigentlich sind, und das Makro nur sagt, wofür es gut ist, aber nicht, was es eigentlich macht. Und das ganze logisch, Schritt für Schritt durchzudenken fällt echt schwer, wenn man so genervt ist, wie ich jetzt gerade :D

Achja: Und dann stellt man fest, dass

Code: Alles auswählen

aiMaterial->Get(AI_MATKEY_UVWSRC(0, DiffuseId), UvChannel);

funktioniert. Warum ich jetzt diese Version nehmen muss, weiß ich allerdings nicht (wie gesagt, ich wollte es analog zum setzen machen).