Jammer-Thread

[Krishty]

Ich glaube, wir sehen hier den Auto-Vectorizer von VC11 in Aktion. ;)

Ich hätte nie gedacht, dass der tatsächlich funktioniert … jetzt will ich auch VC 11 :( Aber wie ich mein Glück kenne, wird er im x64-Compiler komplett versagen :D

[Krishty]

(Diese Ordnernamen habe ich seit Jahren nicht mehr gesehen, denn seit Windows 7 konnte mein Explorer keine nichteuropäischen Zeichen mehr anzeigen. Mit Vista ging es. Warum es jetzt wieder geht und für wie lange, weiß ich nicht.)

• Neu gestartet
   

• 

   
• betrifft nur Koreanisch; meine ganze Kim Ki-Duk-Reihe ist zensiert
   
• for teh luv of gawd
   
• why

[CodingCat]

Konservative Rasterisierung mit allen Spezialfällen (Clipping, Seitenansicht, Backfaces, konservative Tiefe) ist einfach nur ekelhaft. Wahrscheinlich wird sie das letzte, was fertig wird, noch nach vollständiger Optimierung.

[dot]

Wofür brauchst du denn die konservative Rasterisierung?

[CodingCat]

Für alles. ;-) Im konkreten Fall entspricht es am ehesten einer Voxelisierung aus einer bestimmten Richtung. Das Gesamtverfahren könnte man wohl als Ray Tracing/Casting rückwärts beschreiben. Tatsächlich (leider? :P) haben Sintorn, Eisemann et al. schonmal einen Vorstoß in eine ähnliche Richtung gemacht, wenn auch nur zur Schattenberechnung.

Eigentlich wäre eine vernünftige konservative Scanline-Software-Rasterisierung im Compute Shader wesentlich schmerzfreier und möglicherweise geeigneter, aber dann brauche ich wieder so viele Zwischenpuffer ...

[dot]

Und wie löst du das Problem dass manche Pixel an den Kanten nun zu mehreren Polygonen gehören?

[CodingCat]

Die meisten Pixel gehören zu unzähligen Polygonen. Atomics, Spin Locks etc. lassen grüßen.

[dot]

Ich wollte natürlich darauf hinaus, dass sowas wie eine Fillconvention mit konservativer Rasterisierung nichtmehr wirklich definierbar ist...

[CodingCat]

Naja, das Problem ist in diesem Fall dasselbe wie bei normalem Ray Tracing. :-/

[CodingCat]

Dass selbst DirectX 11 noch keine logischen Blendoperationen (Or, And, ...) anbietet, ist einfach nur zum Verzweifeln. Dieses Feature ist weiß Gott nicht neu. DX 11.1 stellt nun endlich die API bereit, dazu müsste ich jedoch auf das Windows 8 Preview SDK umsteigen, welches bei anderen bis jetzt offenbar nur Probleme gemacht hat. Wenn ich Pech habe, kostet mich das Tage, und ich muss D3DX durch die neuen abgekoppelten Bibliotheken ersetzen. :evil:

[eXile]

und ich muss D3DX durch die neuen abgekoppelten Bibliotheken ersetzen. :evil:

Ich glaube, D3DX kannst du auch noch unter Windows 8 verwenden, zumindest wenn du das DirectX-SDK installiert hast (bzw. du distributierst die paar Quelldateien und Libraries einfach mit). Zumindest konnte ich mit installiertem DirectX-SDK unter der Windows 8 Developer Preview einige Projekte, die auch D3DX verwenden, zum Laufen bringen.

[Andre]

Wenn dem so ist dann fällt mir aber ein Stein vom Herzen. Weiß jemand ob das auch mit Metro-Anwendungen noch funktioniert?

[CodingCat]

Wer will denn bitte Metro-Anwendungen? :P

OK, D3DX wäre bei mir nicht mal das große Problem, sofern ich Effects11 irgendwie am Laufen halten kann. Aber wenn das Preview SDK bei dir grundsätzlich gut läuft, obendrein noch mit D3DX, wäre das wohl tatsächlich einen Versuch wert.

[Andre]

Von wollen darf keine Rede sein. Aber man weiß ja nie was da noch kommt, und vielleicht wird man ja irgendwann noch dazu gezwungen. :?

[Schrompf]

Stimmt das eigentlich, dass VC11 keine Exen mehr für WinXP und älter erstellen kann?

[eXile]

Stimmt das eigentlich, dass VC11 keine Exen mehr für WinXP und älter erstellen kann?

Das stimmt so, zumindest wenn du auch den Compiler von VC11 (aka Platform Toolset v110) benutzen willst. Du kannst allerdings auch das nächste Visual Studio mit dem Compiler von Visual C++ 2010 benutzen (Platform Toolset v100). Dafür siehe auch diesen Blogpost.

[CodingCat]

Haha, sehr hilfreich, wo wohl das einzig nützliche an VS11 der neue Compiler sein wird. Die neue IDE brauche ich jedenfalls nicht. ;)

[Krishty]

Was für eine Scheiße – ich habe meinen Renderer hinter einer abstrakten Schnittstelle realisiert. Obwohl

• von dieser Schnittstelle im ganzen Programm nur eine einzige Klasse abgeleitet wird;
• sowohl diese Klasse als auch alle Implementierungen ihrer Methoden sealed deklariert sind;
• LTCG eingeschaltet ist; und
• allen Funktionen, die die Schnittstelle erwarten, immer nur eine Instanz der finalen Klasse übergeben wird,

packt Visual C++ die Virtual Function Calls nicht mit der Kneifzange an. Und das ist ein echtes Desaster, weil jedes Byte, das den Funktionen übergeben wird, am besten sofort und 1:1 in einen Buffer wandern sollte statt erst über den Stapel gereicht zu werden. Ich muss den Mist geinlinet kriegen. Templates sind aber keine Option, weil ich dank C++’ Intoleranz gegenüber Template-Funktionen aus anderen Modulen 8000 Zeilen von Hand kopieren müsste. Microsoft C/C++ „Optimizing“ Compiler ist so eine Wurst.

Und: Was ist der Zweck dieser Seite?! Die beste Optimierung ist, einfach keine Funktionen mehr aufzurufen?!

[antisteo]

Und: Was ist der Zweck dieser Seite?! Die beste Optimierung ist, einfach keine Funktionen mehr aufzurufen?!

Natürlich,
rechne dir nur mal den Speedup aus, den du damit maximal erreichen könntest.

[Schrompf]

Vielleicht kannst Du ja irgendwas drehen, so dass die Klasse nur in der Debug von der Schnittstelle ableitet und in der Release die Schnittstelle einfach ersetzt. Treue OO-Verfechter empfinden das vielleicht als Sakrileg, aber ich hätte mit solchen Konstrukten kein Problem. Wird auch hier und da in Engine-Tutorials empfohlen, wenn ich mich recht erinnere.

[Krishty]

Das Problem ist, dass ich eine Codebase für Logik habe, und zwei Rasterizers für unterschiedliche Produktversionen, die von der Logik benutzt werden könnten. Durch die .hs der Logik käme ich mit einer Forward Declaration des Rasterizers noch durch; durch die .cpps aber nicht – in dem Augenblick, in dem die Logik einen Rasterizer benutzt, muss dieser vollständig definiert sein. Um ihn vollständig zu definieren, muss die entsprechende .h eingebunden sein (es muss ja z.B. eine Größe für den Typ bekannt sein; d.h., dass alle benutzten Direct3D-Objekte definiert sein müssen; obwohl das logisch gesehen absoluter Unsinn ist. Ich hasse C++!). Die ist aber eine andere, je nachdem, welcher Rasterizer benutzt wird.

Kurz: Ich kriege die virtuellen Funktionsaufrufe nicht weg, ohne Logik und Rasterizers auf Quelltextebene miteinander zu verweben (entweder direkt durch vollständige Typisierung oder durch #ifdef). Das ist ganz große Scheiße, weil es für den Compiler keine Kunst sein sollte, die Aufrufe eindeutig der endgültigen Klasse zuzuordnen und entsprechend zu optimieren. Ich will das auch nicht tun, so lange es der Compiler für mich tun könnte.

Ich verstehe auch nicht, warum Visual C++ das nicht macht – ich habe schon gesehen, dass Leute ihren Klassen 200 virtuelle Funktionen gegeben haben. (Da kann ich ja nicht einmal widersprechen – lieber einmal zu oft virtual als zu selten; und rein theoretisch ist das alles automatisiert wieder auf handabgewogenen virtual-Einsatz optimierbar.) Virtuelle Funktionsaufrufe für all die armseligen Dreizeilerfunktionen; das muss doch ein enormes Optimierungspotential bergen …

Aber die Rasterizers sind sowieso noch ein riesiges Schlachtfeld. Es existiert absolut keine Ordnung im Textursystem – die Texturdaten liegen an so vielen Orten verstreut, dass jeder Rasterizer von selber Pfade zusammenbauen, Dateien suchen, und die dann laden muss; inklusive dazugehöriger Fehlerbehandlung und Datenkonvertierung. Ein gigantischer Haufen gewucherter Scheiße. Bis ich da ein System reingekriegt habe, können noch Monate vergehen.

[eXile]

Aber die Rasterizers sind sowieso noch ein riesiges Schlachtfeld. Es existiert absolut keine Ordnung im Textursystem – die Texturdaten liegen an so vielen Orten verstreut, dass jeder Rasterizer von selber Pfade zusammenbauen, Dateien suchen, und die dann laden muss; inklusive dazugehöriger Fehlerbehandlung und Datenkonvertierung. Ein gigantischer Haufen gewucherter Scheiße. Bis ich da ein System reingekriegt habe, können noch Monate vergehen.

Ich habe keine Ahnung von deinem Framework, aber in der Regel will man doch den Rendering-Teil vom Resourcen-Teil abtrennen? In deinem Beispiel würden beide Rasterizers doch wohl ähnliche Dinge mit dem Dateisystem anstellen, es liest sich aber so, als ob das doppelt implementiert wäre.

[CodingCat]

Templates sind aber keine Option, weil ich dank C++’ Intoleranz gegenüber Template-Funktionen aus anderen Modulen 8000 Zeilen von Hand kopieren müsste.

Weiß ich von dieser Intoleranz? Ich kann den Satz gerade nicht einordnen.

[dot]

Und das ist ein echtes Desaster, weil jedes Byte, das den Funktionen übergeben wird, am besten sofort und 1:1 in einen Buffer wandern sollte statt erst über den Stapel gereicht zu werden.

Also ich kenn dein System jetzt nicht, aber das klingt mir irgendwie so, als ob du dein Interface einfach zu weit unten angesetzt hättest...
Könntest du nicht z.B. in einem Call den kompletten Buffer übergeben?

[Krishty]

Direkt im Voraus: Ich kann bloß die Implementierung der Schnittstelle kontrollieren; wie sie benutzt wird, steht außerhalb meiner Macht.

Ich habe keine Ahnung von deinem Framework, aber in der Regel will man doch den Rendering-Teil vom Resourcen-Teil abtrennen? In deinem Beispiel würden beide Rasterizers doch wohl ähnliche Dinge mit dem Dateisystem anstellen, es liest sich aber so, als ob das doppelt implementiert wäre.

Ist es auch. Die Texturen werden mal über Assets identifiziert, dann wieder über eine Datenbank, und einige müssen auch hard-codet werden. Und die Dateipfade unterscheiden sich entsprechend aktueller Renderer-Einstellungen. Verschlimmert wird das dadurch, dass D3D9-Hardware scheinbar kaum palettierte Texturen unterstützt, und ich deswegen einen riesigen Cache aller Texturen, je mit jeder Palette angewandt, in True Color vorhalten muss.

dat chaos

Weiß ich von dieser Intoleranz? Ich kann den Satz gerade nicht einordnen.

Entschuldige – Übersetzungseinheit statt Modul. Ich meine: Man kann ein Template nicht deklarieren, und in einer anderen Übersetzungseinheit definieren.

Also ich kenn dein System jetzt nicht, aber das klingt mir irgendwie so, als ob du dein Interface einfach zu weit unten angesetzt hättest...
Könntest du nicht z.B. in einem Call den kompletten Buffer übergeben?

Nein. Ich emuliere ein Legacy-Datenformat, und wo meine Schnittstelle ist, waren vor 15 Jahren mal einzelne glVertex3f-Aufrufe …

[dot]

Weiß ich von dieser Intoleranz? Ich kann den Satz gerade nicht einordnen.

Entschuldige – Übersetzungseinheit statt Modul. Ich meine: Man kann ein Template nicht deklarieren, und in einer anderen Übersetzungseinheit definieren.

Vielleicht hilft es schon was, das template nur zu deklarieren und einige konkrete Instanzen dann in der anderen Einheit explizit zu instanzieren?

Also ich kenn dein System jetzt nicht, aber das klingt mir irgendwie so, als ob du dein Interface einfach zu weit unten angesetzt hättest...
Könntest du nicht z.B. in einem Call den kompletten Buffer übergeben?

Nein. Ich emuliere ein Legacy-Datenformat, und wo meine Schnittstelle ist, waren vor 15 Jahren mal einzelne glVertex3f-Aufrufe …

Ok, ich geh mal davon aus dass du deine Gründe hast, aber wieso das nun nicht gehen soll erklärt das eigentlich noch nicht ;)
Vielleicht wär es auch sinnvoller, statt soviel Energie in die Optimierung einer ohnehin nicht besonders idealen Schnittstelle zu stecken, es mal dabei zu belassen und stattdessen anzufangen, den alten Code zu refactoren?

[CodingCat]

Weiß ich von dieser Intoleranz? Ich kann den Satz gerade nicht einordnen.

Entschuldige – Übersetzungseinheit statt Modul. Ich meine: Man kann ein Template nicht deklarieren, und in einer anderen Übersetzungseinheit definieren.

Hm, aber damit Templates überhaupt eine Option wären, bräuchtest du ja auf jeden Fall Compile-Zeit-Konstanten, die über die Implementierung entscheiden. In diesem Fall wäre das doch auch nicht anders als Implementierungswechsel mittels #ifdef? Interessant wäre, ob folgendes geht (und konform ist):

Code: Alles auswählen

// Header
template <Implementation> void foo();

// Modul 1
template <>
void foo<ImplementationA>()
{
   // Definition A
}

// Modul 2
template <>
void foo<ImplementationB>()
{
   // Definition B
}

Ich sehe gerade nichts, was dagegen spricht, finde aber auch nichts Explizites im Standard.

[dot]

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

[Krishty]

Ich checke das mit den Templates kurz.

Ok, ich geh mal davon aus dass du deine Gründe hast, aber wieso das nun nicht gehen soll erklärt das eigentlich noch nicht
Vielleicht wär es auch sinnvoller, statt soviel Energie in die Optimierung einer ohnehin nicht besonders idealen Schnittstelle zu stecken, es mal dabei zu belassen und stattdessen anzufangen, den alten Code zu refactoren?

Es ist noch nicht einmal Code: 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.
Es liegen ungefähr 8000 Assets in diesem Format vor. Zu anderen Formaten lässt sich das nicht konvertieren, weil die VM je nach Blickwinkel, LoD, und Situation einen anderen Pfad durch die Datei wählt, und dementsprechend unterschiedliche Daten ausspuckt.

eXile, jetzt bitte keine Paper über Programmflusskontrolle und Sprachoptimierung – Emulieren ist schon schwer genug; ich muss irgendwann fertigwerden ;)

Ich erreiche mit meiner Emulation bereits die 40-fache Leistung des Originals mit angehängtem Glide Wrapper. Trotzdem zeigt mir der Profiler, dass 8 % meiner Rechenzeit mit dem Kopieren der Funktionsparameter für die virtuellen Aufrufe verschwendet werden, obwohl es völlig unnötig ist. Hass.

[dot]

wtf :D

Wer macht denn sowas :shock: