[DX11] Anzahl der Compute Cores abfragen?

[CodingCat]

Ich kann gerade irgendwie nicht glauben, dass DirectX 11 Capability Flags wie TileBasedDeferredRenderer anbietet, ich aber keine Möglichkeit finde, die Anzahl der verfügbaren Compute Cores zu erfragen. Bin ich blind?

[dot]

Also ich kann auf die Schnelle auch keinen Weg finden um diese Information abzufragen. Ehrlich gesagt wundert mich das aber auch absolut ganz und gar nicht, denn es lässt sich doch nichtmal architekturunabhängig definieren, was genau so ein "Compute Core" eigentlich sein sollte...

Wofür genau brauchst du diese Info? Mir fällt atm kaum ein Anwendungsfall ein wo mir das Wissen über die Anzahl der "Compute Cores" was bringen würde, selbst wenn ich es hätte. Für die Performance wichtig ist in der Regel die richtige Aufteilung des ganzen in Thread Groups. Und D3D11 garantiert dir da einfach gewisse Limits für die Anzahl der Groups die du dispatchen kannst, die Anzahl der Threads pro Group und das verfügbare Groupshared Memory. Wenn man einfach schaut, dass die Anzahl der Threads in einer Group ein Vielfaches von 64 ist und genug Groups da sind, dann sollte man zumindest auf ATI und NVIDIA relativ optimale Performance erreichen (zumindest was das angeht).

[CodingCat]

Es geht mir um optimiertes Scheduling bei repetetiven Abarbeitungsprozessen mit sehr inkohärenten Wiederholungszahlen. In diesem Fall führt klassisches datenorientiertes Scheduling durch die GPU, wie du es beschreibst, dazu, dass das Arbeitspaket mit der größten Wiederholungszahl alle anderen Cores, deren Arbeitspaket kleiner ausgefallen ist, so lange gefangen hält, bis wirklich alle aktuell durch die entsprechende Gruppe bearbeiteten Pakete fertiggestellt sind. Erledigt man das Scheduling dagegen selbst, indem man einfach alle Cores mit genügend endlos laufenden Gruppen abdeckt, lassen sich die Arbeitspakete in Teilpakete kohärenter länge unterteilen, wobei arbeitslose Threads schon nach jedem Teilpaket die Gelegenheit bekommen, sich neue Arbeit zu beschaffen.

Für den Moment starte ich also wohl einfach genügend Threads für meine GPU. Auf GPUs mit weniger Cores werden damit eben einige Gruppen zu viel abgeschickt, was aber auch nicht weiter schlimm ist. Am Ende stellen diese einfach fest, dass keine Arbeit mehr übrig ist, und beenden sich im Anschluss sofort wieder.

[Schrompf]

Rein aus Neugier: was hast Du denn vor?

[eXile]

1. Welche Möglichkeiten es gibt, hardware-abstrahiert die Anzahl der echten Cores einer GPU herauszufinden? Meines Wissens nach: Keine.
   
   Dafür musst du CUDA oder APP nehmen. Bei CUDA ist der entsprechende Eintrag in cudaDeviceProp.multiProcessorCount zu finden. Von AMD hab' ich keine Ahnung.
2. Schrompf: Wohl das.

[dot]

AMD: OpenCL

[eXile]

AMD: OpenCL

Ja gut, das wusste ich auch schon. Keine Ahnung heiß noch immer eXile'isch-keine-Ahnung, nicht dass ich dumm wie Brot bin. Schnelle Googlierung hat noch CL_DEVICE_MAX_COMPUTE_UNITS hervorgebracht, in dessen Umgebung ich mal weiter suchen würde.

Obligatorische Jammerei: Der aktuelle Zustand zur Optimierung von CUDA/OpenCL/DirectCompute ist doch beschissen. Zwar gibt es mittlerweile hinreichend gute Tools von nVidia und AMD, aber im Endeffekt optimiert man nur auf eine Graphikgeneration hin (wenn's schlimm kommt: Auf nur eine Graphikkarte); und das ist ja wohl bescheuert. Schöne neue Graphikwelt.

Oh und in fast jedem Optimierungs-„Guide“ steht sinngemäß drin: „Wenn alles bis hier hin nicht geklappt hat, sollten sie mal versuchen, mit den Parametern wild herum zu experimentieren!“ No shit Sherlock! Da ist es fast schon verständlich, dass Microsoft auf eine so rigide Hardware-Abstraktion gesetzt hat, dass so etwas wie Warp-Size oder Anzahl SMs vollkommen unbekannt hinter der HAL ist.

[dot]

Also über DirectCompute kann ich nicht urteilen, da ich es noch nie wirklich verwendet hab. Es ist wohl von allen genannten die API mit den größten Einschränkungen. Ich würde aber mal davon ausgehen, dass die verfügbaren DirectCompute Implementierungen dafür ziemlich gut funktionieren. Von OpenCL bin ich alles andere als begeistert. CUDA ist wohl die mit sehr großem Abstand am weitesten entwickelte Plattform, aber auch noch lange nicht wirklich toll...

[CodingCat]

Danke für die Hinweise, für präzise Informationen komme ich dann wohl kaum um proprietäre Hilfsbibliotheken drumrum.

Ich bin insgesamt erschüttert, wie wenig Information sich im Internet zum Thema Compute Shaders findet. Am hilfreichsten ist da noch der etwas ausführlichere SM-5.0-ASM-Teil der HLSL-Referenz, aber im Augenblick kann auch der mir nicht bei der Frage helfen, warum ein Aufruf von InterlockedAdd() auf einem RWTexture2DArray<uint> sofort zu undefiniertem Inhalt führt.

[dot]

Bist du dir sicher dass Atomic Operations für ein RWTexture2DArray überhaupt verfügbar sind? Ich dachte bisher die funktionieren nur auf UAVs...

[CodingCat]

Ein RWTexture2DArray ist prinzipiell *ein* UAV. Das ist es eben, die Nuancen stehen nirgends.

[CodingCat]

Laut ASM-Abteil arbeitet atomic_iadd einfach auf u#-Registern, welche wiederum auch Texture2DArrays schlucken. Allerdings verlässt auch mich langsam der Glaube, dass das wirklich geht.

[CodingCat]

WTF, ich muss Unordered Access Views in der Compute Stage nach Gebrauch von Hand entbinden, und zwar nicht mit CSSetUnorderedAccessViews(0, 0, nullptr, nullptr), sondern mit einem extra nullptr-Array, welches alle CS-Register überdeckt.

Dann sind atomare Operationen aber tatsächlich auch auf mehrdimensionalen Texturen definiert.

[dot]

WTF, ich muss Unordered Access Views in der Compute Stage nach Gebrauch von Hand entbinden, und zwar nicht mit CSSetUnorderedAccessViews(0, 0, nullptr, nullptr), sondern mit einem extra nullptr-Array, welches alle CS-Register überdeckt.

Ist das nicht sowieso mit allen derartigen Methoden so, also auch bei den ganzen *SetShaderResource() Methoden etc.?
Ich mach's zumindest immer so, da ich in der Doku noch nichts finden konnte was eine einfachere Variante nahelegen würde...

[CodingCat]

Ja, ich kümmere mich nur sonst nie darum, weil an anderer Stelle in der Pipeline eh keine Konflikte auftreten können. In der Regel werden Input Resource Views von Direct3D automatisch entbunden, sobald konfligierende Output Views gesetzt werden. Der umgekehrte Fall tritt in einer normalen Rendering Pipeline praktisch nie ein. Wie wir nun gelernt haben, gilt dieser Automatismus umgekehrt aber offenbar nicht, d.h. Output Views dominieren Input Views.

Und mit Vollgas gegen die Wand:

Ich sehe schon, alles mit Strahlen wird verdammt haarig (rote Pixel wurden mehr als 3000x überschrieben, dass da noch eine 4 steht, grenzt schon an ein GPU-Wunder).