Zero-Copy u. DxCompute

[MadMax]

Hallo zusammen,

es gibt in CUDA bzw. OpenCl ein nettes Feature welches sich zero-copy nennt. Wenn ich alles richtig verstanden habe kann ich so Speicherbereiche definieren welche im Hauptspeicher liegen aber von der GPU aus abfragbar sind (Read-Only würde mir sogar reichen). Kann man dieses Verfahren irgendwie unter DirectCompute verwenden (Dx11).
Was ich genau machen möchte:

1.) Großen Speicherbereich im Hauptspeicher (z.B. 10GB)
2.) Aus meinen Shadern greife ich darauf zu und packe die benötigten Daten in meinen GPU Speicher


Vielen Dank,
Manuel

[CodingCat]

Ohne Kopie geht es meines Wissens nicht, am nächsten kommst du wohl mit händischer Aktualisierung dynamischer Puffer.

[Krishty]

Jetzt habe ich wieder Sehnsucht nach Sparse Virtual Textures. Toll. Danke.

Mit OpenGL kannst du das als AMD-Erweiterung nutzen; der Treiber kümmert sich in diesem Fall um das Paging. Das ist aber wahrscheinlich, was du mit OpenCL meintest?

Und wo wir gerade beim Thema sind: Wann wird Direct3D voll virtualisierte Ressourcen unterstützen? Pläne, Kommentare, Hinweise? Anyone? eXile?

[dot]

IIRC is das für WDDM 2.x geplant (das und vollwertiges Preemptive Multitasking), ich hab nur leider den Link zum entsprechenden Talk nimmer..

[eXile]

Speicher, der non-pageable im RAM ist und einen Device-Pointer für den VRAM hat (das, was man in CUDA-Sprache zero-copy nennt) muss in der Regel sehr wohl kopiert werden: Immer dann, wenn man eine dedizierte GPU hat, müssen die Daten vom RAM in den VRAM kopiert werden. Nur wenn man eine integrierte GPU hat, müssen keine Daten kopiert werden, weil sie ja bereits im gleichen Speicher liegen. Das zero-copy besagt nur, dass kein explizites memcpy durchgeführt wird; CUDA wird im Hintergrund aber sehr wohl kopieren.

Der Sinn dahinter ist, dass man dadurch die Kopierlatenzen verstecken kann: Man nimmt an, dass der Kernel sehr rechenaufwändig ist; wenn der Kernel

1. auf einer dedizierten GPU eine Page-Fault verursacht, werden die Daten auf die GPU kopiert. In der Regel rechnen andere Kernels noch rum, während ein paar Kernels auf die Speichertransfers warten. Darum laufen ein paar Berechnungen parallel zu ein paar Speichertransfers ab. Problematisch wird es, wenn die Berechnungen so schnell zu Ende sind, dass die Speichertransfers noch nicht abgeschlossen sind. Dann kann man kaum etwas verstecken.
2. auf einer integrierten GPU eine Page-Fault verursacht, ist irgendwas kaputt, weil die Daten ja im RAM gehalten werden und dort als non-pageable gekenntzeichnet sind, also auch immer im RAM gehalten werden müssen. Hier muss nichts kopiert werden, Kopierlatenz ist Null.

Wie du siehst, bringt das nur richtig viel mit integrierten GPUs. Wenn dir im Vorfeld klar ist, dass alle deine Daten in den VRAM passen und deine Kernel sehr schnell bis moderat schnell sind, ist Kopieren-Berechnen-Kopieren fast immer schneller. Erst wenn die Kernels extrem lange rumrechnen und die Daten nicht komplett in den VRAM passen, könnte es etwas bringen.

Oder kurz: Das gibt es nicht in DirectCompute, weil integrierte GPUs das Schmuddelkind der Computergraphik sind, um das sich niemand kümmert; und die DirectCompute-Shader in der Regel eh nicht länger als zwei Sekunden dauern sollten, weil einem sonst der Watchdog um die Ohren fliegt.

IIRC is das für WDDM 2.x geplant (das und vollwertiges Preemptive Multitasking), ich hab nur leider den Link zum entsprechenden Talk nimmer..

In der Tat! Hier der Link.

Und wo wir gerade beim Thema sind: Wann wird Direct3D voll virtualisierte Ressourcen unterstützen? Pläne, Kommentare, Hinweise? Anyone? eXile?

In der Präsentation finden sich keine Zeitangaben. Aber man kann wohl eine ungefähre Schätzung abgeben. Der Chef von Nvidia hat gesagt:

Between now and Maxwell, we will introduce virtual memory, pre-emption, enhance the ability of the GPU to autonomously process, so that it's non-blocking of the CPU, not waiting for the CPU, relies less on the transfer overheads that we see today. These will take GPU computing to the next level, along with a very large speed up in performance.

Wenn du mich fragst, kommen diese Features mit Maxwell. Und Maxwell kommt 2014. Normalerweise sprechen sich Microsoft und die IHVs sich halbwegs ab (wenn man mal von der völlig lahmarschigen Implementierung von Direct3D 11 erst bei Fermi absieht); meine Antwort auf deine Frage wäre also ca. Mitte 2014. Wie du siehst, ist das alles sehr vage.

Im Jahre 2014 werde ich diesen Post zitieren und über meine Naivität lachen.

[Lynxeye]

Speicher, der non-pageable im RAM ist und einen Device-Pointer für den VRAM hat (das, was man in CUDA-Sprache zero-copy nennt) muss in der Regel sehr wohl kopiert werden: Immer dann, wenn man eine dedizierte GPU hat, müssen die Daten vom RAM in den VRAM kopiert werden. Nur wenn man eine integrierte GPU hat, müssen keine Daten kopiert werden, weil sie ja bereits im gleichen Speicher liegen. Das zero-copy besagt nur, dass kein explizites memcpy durchgeführt wird; CUDA wird im Hintergrund aber sehr wohl kopieren.

Unabhängig davon, ob die aktuellen Runtimes dies tun oder unterstützen, denn davon habe ich keine Ahnung: wieso sollte ein Kernel, welcher auf einer dedizierten GPU ausgeführt wird nicht auf Sysram Puffern arbeiten können? Der Device-Pointer welchen du erhältst ist genau das: eine virtuelle Speicheradresse im Adressraum der GPU, welche nach der virt->phys Übersetzung genauso gut auf eine PCI Busadresse zeigen kann wie auf eine VRAM Adresse. Ich muss also nicht zwangsläufig die Daten kopieren, um von der GPU auf diese zugreifen zu können. Das es bei Aufgaben, deren Geschwindigkeit maßgeblich von der verfügbaren Speicherbandbreite abhängt, trotzdem sinnvoll ist die Daten im Hintergrund in den VRAM zu schieben, während man die GPU mit etwas anderem beschäftigt, steht außer frage.

[MadMax]

Erst mal danke für all die interessanten Antworten. Mir geht es eigentlich erst in zweiter Linie um Performanz. Wichtig ist mir vielmehr das die GPU direkt Bedarf an bestimmten Ressourcen anmelden und ich so auf nahezu beliebig große Datenmengen zugreifen kann ohne irgendwelchen schweinkram wie multipass machen muss. Die Gigavoxel Engine und ich denke auch die neue Unreal Engine haben ja eine GPU Datenloader so was möchte ich auch haben und brauche für einen sinnvolle Architektur eben diesen Zugriff.

[Krishty]

Ebenfalls danke für die Antworten … dann setze ich mich mal in meine Zeitmaschine. Ach nein – bis 2014 bin ich eh durch genug anderes Zeug ausgelastet :(

[mOfl]

Die Gigavoxel Engine und ich denke auch die neue Unreal Engine haben ja eine GPU Datenloader so was möchte ich auch haben und brauche für einen sinnvolle Architektur eben diesen Zugriff.

GigaVoxels sind, wie der Name schon vermuten lässt, eine Adaption von MegaTextures für dreidimensionale Texturen. Crassin hat dazu einen sehr interessanten Tech Report und eine noch viel interessantere Dissertation verfasst:

@techreport{Crassin08,
author = {Cyril Crassin and Fabrice Neyret and Sylvain Lefebvre},
title = {{Interactive GigaVoxels}},
number = {RR-6567},
institution = {INRIA},
year = {2008}
}

@phdthesis{Crassin11,
author = {Cyril Crassin},
title = {{GigaVoxels: A Voxel-Based Rendering Pipeline For Efficient Exploration Of Large And Detailed Scenes}},
school = {University of Grenoble},
year = {2011}
}

Was dort passiert, ist nichts anderes als Virtual Texturing mit 3D-Texturen. Die Texturdaten stehen der GPU also nicht vollumfänglich zur Verfügung, sondern werden über einen Sichtbarkeitstest in einem ersten Pass zusammengesammelt und asynchron gestreamt. Dazu kommt eine Indirection Texture, die praktisch als Page Table fungiert, und dann erstellst du einen Cache im VRAM, wo du die benötigten Texturchunks reinladen kannst. Genau das gleiche, was die von Krishty angesprochene AMD-Erweiterung AMD_sparse_texture bieten soll, nur bei GigaVoxels eben noch als Softwareimplementierung. Da ist noch gar keine CUDA Magic involviert.