[DX9] sorry... Texturupload beschleunigen

[Schrompf]

Sorry, wirklich DX9. Bin immer noch nicht dazu gekommen, mal auf Vulkan umzubauen. Dort hätte man ja async transfers kriegen können.

Ich hab ein Spiel mit DX9. Das Spiel erzeugt on-the-fly Texturen und Meshes. Pro Frame z.b. einen Strauß 256er, 512er oder auch mal eins zwei 2048er. All diese Teile entstehen noch komplett auf der CPU, ich bündel sie auf einen 4096er Atlas und Jedes Frame erstelle ich eine neue Textur und befülle sie:

Code: Alles auswählen

d3dDevice->CreateTexture( breite, hoehe, 1, /*flags*/, D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &mD3DTextur, NULL);
d3dDevice->CreateOffscreenPlainSurface( breite, hoehe, FMT, D3DPOOL_SYSTEMMEM, &tempsurf, nullptr);
tempsurf->LockRect( &rect, nullptr, D3DLOCK_DISCARD);
copyPixelData(dahin);
tempsurf->UnlockRect();
mD3DTextur->GetSurfaceLevel( 0, &zielSurface);
d3dDevice->UpdateSurface( tempsurf, &srcRect, zielSurface, &dstPoint);
zielSurface->Release();
tempsurf->Release();

So hab ich ne Textur, die ich dann an nem Sampler eines schlichten CopyShaders anbinde und an die eigentlichen Ziel-Positionen der Texturatlanten rendere.

Das Problem:

Code: Alles auswählen

TexturUpdate: 14 Fragmente mit MaxGröße 2048² auf 6 Ziel-Atlanten in 406.19ms

Mäh. Zugegeben, das ist ein Extrembeispiel, die Standardfälle sind 16x 128² in 70ms, aber das ist immer noch gesäßlangsam. Hat jemand ne Idee, wie ich das schneller kriegen könnte?

[Schrompf]

Ich könnt einfach mal eine separate zielgenau große Temp-Textur für jeden einzelnen Transfer erstellen und so mit erhöhtem Overhead die Transfer-Menge minimieren.

[Krishty]

Knifflig. Ich locke die Texturen direkt, ohne Off-Screen Surface, da D3DLOCK_DISCARD bereits Synchronisierung vermeidet. Keine Ahnung ob schneller oder langsamer. Ich nehme an, dass das CreateTexture() nur beispielhaft den Kontext zeigt und du die Original-Resource überschreibst statt neue zu erstellen?

[TomasRiker]

Warum nicht direkt auf der Textur LockRect aufrufen? Wäre auf jeden Fall einen Versuch wert. D3DUSAGE_DYNAMIC nehmen.
Edit: Krishty war schneller :)

[Schrompf]

DISCARD geht nicht, weil ich all die kleinen, mittleren und großen Texturen auf 1 bis x gigantischen Atlanten bündle. Gibt zwar NOOVERWRITE oder so, aber ich hab noch nie gesehen, dass das tatsächlich den Sync Stall vermieden hätte. Die trauen mir nicht :-(

Ich erstelle also wirklich ne neue Textur. Jedes Frame. Ich habe jedes Frame 0 bis x neue Images in allen möglichen Größen. Für die erstelle ich einen großen Atlas, frisch und neu nur für dieses Frame, pack die da alle drauf, und render dann von dieser Textur an die eigentlichen Stellen in den Atlanten. Die Neu-Erstellung einer Temp-Textur in jedem Frame vermeidet den GPU Sync. Ist aber leider arschlangsam. Wahrscheinlich weil ich das Ding pauschal 4096² groß mache, um genug Platz für alles zu haben.

Option also: ich mach ne Million einzelne Texturen für jede einzelne Quell-Textur, ich mach sie genau in der richtigen Größe, ich mach sie DYNAMIC und locke sie direkt. Hatte ich vorher schon, ging ganz gut... hm.

[Krishty]

DISCARD geht nicht, weil ich …

Ah, verstehe – D3DLOCK_DISCARD kann nur die gesamte Textur überschreiben oder gar nichts, und du überschreibst ja Häppchen.

Ich versuche, herauszufinden, ob der Upload selber Flaschenhals ist oder das Erzeugen neuer Texturen. Ich weiß, dass Spiele in den 90ern Pools mit Textur-Objekten angelegt haben, um den Overhead von CreateTexture() zu vermeiden. Da ging es aber vor allem auch um VRAM-Fragmentierung, und ich dachte eigentlich, die sei seit der Virtualisierung in WDDM 1.1 (um Windows 7) Geschichte.

Kannst du das Timing von CreateOffscreenPlainSurface() und CreateTexture() getrennt von Unlock() und UpdateSurface() messen? Also Ressource-Verwaltung gegenüber tatsächlichem Upload?

Ich wollte dieses Wochenende meinen Windows-7-Rechner reparieren, damit ich endlich mal wieder eine D3D-9-Debug-Runtime habe. Natürlich ging das unter. Grmpf

[TomasRiker]

Die Doku sagt übrigens (Hervorhebung durch mich):

It is a good idea to create only one dynamic texture per format and possibly per size.

Nutzt du eigentlich auch MIP Maps? Dazu hat die Doku auch eine Warnung parat:

Dynamic mipmaps [...] are not recommended because of the additional overhead in locking every level. For mipmaps, D3DLOCK_DISCARD is allowed only on the top level. All levels are discarded by locking just the top level.

Ob das auch zutrifft, wenn man D3DUSAGE_AUTOGENMIPMAP benutzt?

[Krishty]

Trifft definitiv auch zu; guter Fund. Die Mip-Map-Erzeugung sollte ja auf der GPU ablaufen und deshalb keinen CPU-Overhead zeigen; ich würde sie aber definitiv mal deaktivieren um zu prüfen, ob sich die Upload-Zeiten ändern.

Beachte, dass sich das Rendering stark verlangsamt, insbesondere mit großen Texturen. Ich hoffe, dein CPU-Timing-Code ist robust.

[Schrompf]

Jo, MipMaps hab ich für den Moment ausgeklammert, auch weil ich festgestellt habe, dass im Zuge irgendeines Umbaus in den letzten zehn Jahren mein Framework verlernt hat, in MipMaps zu rendern :-/ Sollte aber hier weniger kritisch sein als bei anderen Renderern, weil das Prinzip dieses On-The-Fly-Generierens auch dazu dient, die Daten immer genau im Detailgrad dazuhaben, der zur aktuellen Erscheinungsform auf dem Bildschirm passt.

Zum genauen Messen müsste ich das jetzt instrumentieren. Hab mal den VS-eingebauten Profiler mitlaufen lassen, aber der lässt sich anscheinend von den Fibers völlig verwirren, von 60k Samples hab ich überhaupt nur paar hundert im Profil gesehen. Der Rest war... sonstwo. Würde aber dazu passen, dass ich im VS-Debugger nur um 10% CPU Load beobachte. Sobald die Kamera still steht und alle GenJobs zur Ruhe kommen, rendert es in 3ms.

Ich probier mal die alte Version, wo ich einfach Texturen für jedes Schnipsel einzeln erzeuge und lösche. Sind dann tausende, aber wer kehrt? Geht ja erstmal, bis ich das alles auf Vulkan umschreibe.

[TomasRiker]

Kommt eine reine GPU-basierte Erzeugung der Texturen in Betracht? Also mit einem (komplizierten) Shader direkt in die Textur rendern. Dann würdest du dir den teuren Transfer von CPU zu GPU sparen. Und wenn du dann noch eine zeitliche Verzögerung einbaust (Textur, die in Frame N gerendert wird, wird erst in Frame N+x benutzt, bis dahin noch die alte Version), vermeidest du Abhängigkeiten, wo die GPU warten muss.

[Schrompf]

Ich bin noch nicht wieder dazu gekommen, irgendwas an dem Thema zu probieren.

Kurzfristig: ich will ne eigene kleine Temp-Textur für jeden Transfer zu den Texturatlanten ausprobieren. Damit übergebe ich dem Treiber den Stress, aber der müsste ja nach 20+ Jahren gut optimiert für sowas sein.

Langfristig: ja, da soll das alles auf der GPU laufen. Und aktuell ist das auch quasi ne NO-OP, was ich da in die Texturen rendere. Gedacht sind aber komplexe Operationen, die Mesh und Texturen gemeinsam verändern und jede Menge Kontext der umgebenden Szene einberechnen. Das krieg ich nicht im DX9-Shader hin, dafür brauch ich irgendwas Compute-fähiges. Und damit sind wir wieder bei der Vulkan-Portierung, die ich seit Jahren vor mir herschiebe.

Oder ich nehm DX11, das müsste alles viel einfacher sein und Computen kann ich da glaube ich auch. Kann ich? Weiß nicht. OpenGL könnte sicher alles, aber ich habe bisher nur Schlimmes über die Extension Hell gehört.

[dot]

Oder ich nehm DX11, das müsste alles viel einfacher sein und Computen kann ich da glaube ich auch. Kann ich? Weiß nicht. OpenGL könnte sicher alles, aber ich habe bisher nur Schlimmes über die Extension Hell gehört.

Portieren nach D3D11 wird auf jeden Fall um Größenordnungen einfacher als nach Vulkan. D3D11 ist effektiv eine saubere Version dessen, was D3D9 am Ende gerne gewesen wäre, mit ein paar Additions zur Pipeline. Und ja, hat basic Compute Support. OpenGL ist tot und war gegen Ende effektiv in Richtung D3D11 konvergiert und kann nicht wirklich mehr als D3D11 (abgesehen von einigen Extensions, an die du in D3D11 wenn überhaupt dann nur sehr mühsam rankommst).

Wenn Cross-platform dir egal ist und du einfach nur was Moderneres als D3D9 willst, dann ist D3D11 so ziemlich das Beste, was du dir nur wünschen könntest. Hat meiner Erfahrung nach unter Windows auch besseren Support als OpenGL.

[Schrompf]

Hmja, Danke, dot, das passt zu meinem diffusen Wissen.

News an der Texturupload-Front: der Extremfall ist immer noch langsam, und irgendwann muss ich mal instrumentiert profilen und wirklich sehen, warum. Aber der Standardfall mit nem Dutzend 256er Texturen ist jetzt rasend schnell. So funktioniert's jetzt:

- Ich geh durch alle neuen Images durch und suche das Kleinste raus. Die sind immer Zweierpotenzen, immer quadratisch, immer minimal 128 und maximal 2048.
- Ich rechne aus, mit wievielen Kacheln dieser Größe ich alle Texturen transferiert kriege.
Optional: wenn das zuviele Kacheln sind, so dass die auf einer Zeile ne maximale Texturgröße sprengen würden, mach ich mehrere Zeilen
- Ich teile jedes neue Image in solche Kacheln auf und pack sie auf die Temp-Textur
- Ich gehe über jeden GPU-Texturatlas drüber und render dort hinein alle Kacheln, die auf diesem Atlas landen sollen

Ergebnis: es gibt jetzt eine passgenau großen Temp-Textur für jedes Frame. Tatsächlich x2, weil einmal Albedo und einmal World Normal. Und das braucht jetzt so maximal 120ms für ~6k² Bilddaten und ~2ms für das Standard-Dutzend an 128ern. Ruckt immer noch merklich im Extremfall, aber das alltägliche Leben im Dungeon fällt jetzt selten unter 60fps.

[Krishty]

Kurze Rückmeldung mit meiner frischen Erfahrung:

Umgebung

Direct3D 9Ex auf Windows 10 (eigentlich Windows Server 2022) mit steinalter Nvidia-Gurke.

Konzept

Textur-Streaming im laufenden Betrieb aus separaten Threads. Die Daten dafür kommen direkt aus einer Memory Mapped File.

D3DCREATE_MULTITHREADED soll furchtbare Performance haben weil es einfach ein globaler Mutex ist (sagt jedenfalls D3D-Lead Chuck Walbourn hier in einem Kommentar. Original-Antwort stammt lustigerweise von Aramis – kleine Welt!). Deshalb verzichte ich drauf und mache meinen eigenen Blackjack-und-Nutten-Mutex, den sich der Render-Thread zwischen BeginScene() und EndScene() schnappt. Das Textur-Streaming muss warten, bis der frei ist.

Im Streaming-Thread: CreateOffScreenPlainSurface(), per LockRect() füllen. CreateTexture() und UpdateSurface(), um das CPU-Surface auf die GPU zu kopieren. (Direktes Lock/Unlock der Textur ist ja in D3D9Ex unmöglich, da es keinen D3DPOOL_MANAGED mehr gibt. D3D9Ex führt direkte Initialisierung bei CreateTexture() ein, aber die funktioniert nur auf Texturen ohne Mip Maps.)

Selbstverständlich habe ich nur die D3D-Aufrufe selber via Mutex synchronisiert; das Laden der Datei usw. geschieht außerhalb des Mutex.

Fehlgeschlagener Versuch

Die ersten Ergebnisse waren brutal: Bis zu 1500 ms für eine 4k-Textur. Dann fiel mir auf, dass die meiste Zeit für Race Conditions draufging – ich habe den Treiber wohl geflutet (oder meinen Prozess mit Page Faults auf die Memory Mapped Files lahmgelegt).

Ergebnis

Habe auf ein Producer-Consumer-Pattern umgestellt, so dass nicht mehr als eine Textur gleichzeitig gestreamt wird. Performance verzehnfachte sich. (Dafür habe ich aber nur noch ein Zehntel der Nebenläufigkeit.) Der Upload einer 4k-Textur geschieht nun regelmäßig in unter 150 ms. Das ist ein merklicher Ruckler, aber:

Von 150 ms gehen ungefähr 100 für das Kopieren der Textur-Bytes aus der Memory Mapped File in den Surface Memory drauf. Ich nutze bereits PrefetchVirtualMemory(), um Hard Page Faults zu vermeiden. Trotzdem verdoppelt sich die Kopier-Performance fast, wenn ich vor dem Upload noch schnell alle Pages ins Working Set zwinge, indem ich bspw. die Texel in 4096-Byte-Abständen aufsummiere. Ich habe die D3D-Calls gemessen – ab und zu hat ein UnlockRect() zwei Millisekunden gebraucht, oder ein Release() acht. Die sind also definitiv alle asynchron umgesetzt und lassen keine genaue Performance-Analyse zu.

Für mich ist eine 4k-Textur in 150 ms Upload-Unterbrechnung erstmal genug. Das ist ziemlich nah an deinen “120 ms für 6k²”, aber mein Rechner ist steinalt, also schätze ich, dass es nicht besser geht. (Meine tatsächliche Latenz ist viel höher, da ich vor dem Upload ja noch die Datei mappe, die Texel ins Working Set zwinge, und das Producer-Consumer-Pattern alles in eine Warteschlange zwingt.) Für besseres Multi-Threading muss ich halt auf eine neuere Grafik-API.

Moral von meiner Geschichte: Mein Locking hat viel mehr ausgemacht als die D3D-Aufrufe. Jetzt macht noch das Prefetching der Texel mehr aus.

[Schrompf]

Auch spannend, aber ich entnehme dem vor allem, dass ich erst Vulkan o.Ä. brauche, um asynchron Zeugs in den VRAM zu kriegen. Oder?

[Krishty]

Wäre mir neu. D3D11 sollte das definitiv können; D3D10 hatte IIRC bereits entsprechende Erweiterungen weil DICE drauf drängten. Ich muss mal das Paper finden.

D3D10 ist nun 19 Jahre alt. Damit ist es so alt wie VGA war, als Vista mit D3D10 released wurde (1987 vs. 2006 vs. 2025).

[Schrompf]

Jahaaa, nenn mich ruhig alt :-) Ich meine damit, dass ich das nicht in mein DX9-Framework einziehen können werde. Und wenn ich eh die API wechseln muss, dann kann ich auch gleich Vulkan nehmen.

[Krishty]

Ich darf das, bin ja selber noch auf D3D9 😜

Direct3D 9 ist jetzt so alt wie die Intellivision-Konsole war, als Direct3D 9 rauskam (1979 vs. 2002 vs. 2025)

[Krishty]

Fun fact: Ich habe am Prefetching gedreht und der Upload ist zuverlässig 30 % schneller geworden. Das ist … interessant. Wenn ein Stück Code ein unabhängiges Stück Code schneller macht, suspect Caching!

Und tatsächlich: Für das Prefetching berühre ich jetzt nicht mehr jedes 4096te Byte des Mappings, um die Page ins Working Set zu zwingen. Ich berühre immer 16 Bytes der Page auf einmal via _mm_stream_load_si128() a.k.a. MOVNTDQA. Dieser Load-Befehl umgeht den CPU-Cache – der Soft Page Fault für Windows ist weiterhin da, aber die Caches werden dabei nicht gethrasht.

Ich kann mir noch immer nicht erklären, warum der Upload danach schneller ist – eine 4k-Textur passt sowieso nicht in meine CPU-Caches. Aber ich nehme die Verbesserung gern mit.

Edit: Es wird besser! MOVNTDQA dürfte gar keine Änderung bewirken, weil es nur auf Write-Combining Memory funktioniert (z.B. im AGP) und nicht auf Write-Back Memory (wie eben File Mappings).

Dennoch: Wenn ich es durch ein äquivalentes MOVDQA ersetze, bricht die Performance wieder ein. Rabbit Hole …

[Hannes]

Jahaaa, nenn mich ruhig alt :-) Ich meine damit, dass ich das nicht in mein DX9-Framework einziehen können werde. Und wenn ich eh die API wechseln muss, dann kann ich auch gleich Vulkan nehmen.

Wenn du die Shaderpipeline in D3D9 verwendest musst du strukturell nicht viel ändern um den Code auf D3D11 zum laufen zu kriegen, weil die selben Konzepte auch mit D3D11 funktionieren und noch mehr. So wie ich es verstanden habe, ist die Ressourcenerstellung, in D3D11 (was das D3D11Device betrifft), Threadsafe. Sie ist darauf ausgelegt, zum Beispiel Texturenerstellung, auf mehrere Threads zu verteilen. D3D11 ist nicht so flexibel wie Vulkan, aber ein paar sachen kann D3D11 in sachen Multithreading, die D3D9 nicht kann (Wie CommandLists).

[Krishty]

Wenn du die Shaderpipeline in D3D9 verwendest musst du strukturell nicht viel ändern um den Code auf D3D11 zum laufen zu kriegen, weil die selben Konzepte auch mit D3D11 funktionieren

Hier habe ich groooße Zweifel. Schon allein die Tatsache, dass du in D3D9 an jeder Ecke Render States setzen kannst, während du in D3D11 vorab State Blocks erzeugen musst, empfinde ich als erhebliche strukturelle Änderung. (In D3D9 gibt es zwar auch State Blocks, aber a) benutzt die fast niemand und b) sind sie wesentlich weniger granular als in D3D11.)