Okay, die Beiträge bringen mich weiter, aber
warum die Scheduler-Logik dann so enorm wäre, weiß ich immernoch nicht. Darum aus eigener Recherche:
Nvidias Fermi benutzt 16
Streaming Multiprocessor Units, von denen jede 32
CUDA Cores enthält verwaltet. Also 16 Mal das, was eigenen Speicher besitzt, seine Arbeit an 32 Rechenkerne dirigiert und man in der CS-Welt durch eine
Thread Group beschreibt.
Bei ATIs Radeon HD 5000-Serie arbeiten 20
Shader Cluster, die jeweils aus 16
Shader Units bestehen. Also 20
Thread Groups, respektive.
Wenn man für einen Compute Shader
Dispatch() aufruft, gibt man nicht an, wie viele Threads man haben will, sondern wie viele
Streaming Multiprocessor Units (Nvidia) bzw.
Shader Cluster (ATI) man anschmeißen will.
Dispatch(screen_width, screen_height, 1) bedeutete also, dass man für jeden Pixel auf dem Bildschirm eine
Streaming Multiprocessor Unit oder ein
Shader Cluster anschmisse, die/der einen einzelnen Thread ausführen würde, während die übrigen 31
CUDA Cores (Nvidia) oder 15
Shader Units (ATI) darin leer liefen.
Umgekehrt würde eXiles
Dispatch(1, 1, 1) bedeuten, dass 15
Streaming Multiprocessor Units oder 19
Shader Clusters leerliefen, während sich 32
CUDA Cores oder 16
Shader Units durch alle Pixel des Bildschirms wühlen müssten, was genauso langsam wäre als das andere Extrem. Compute Shaders unterbinden das, indem eine Thread-Gruppe aus nicht mehr als 1024 Threads bestehen darf – mehr als 32×32 Pixel pro Thread-Gruppe sind also eh nicht kompilierbar.
Die goldene Mitte, nämlich genau
so viele Threads pro Gruppe, wie die Hardware hat, ist wiederum wegen der von Lynxeye genannten Speicherlatenzen ineffizient.
Um das Ganze also architekturabhängig zu machen, hätte man einbauen müssen:
- dass das numthreads-Attribut weggelassen werden darf
- eine Funktion DispatchThreads(), die anhand der Anzahl an Thread Groups und ihrer jeweiligen Rechenkerne der verbauten Hardware die optimale Gruppengröße bestimmt und die Shader darin gruppiert zur Hardware weitergegeben hätte
- und dass nur Shader ohne numthreads-Attribut mit DispatchThreads() ausgeführt werden können.
Das wäre tatsächlich ein wenig viel Aufwand geworden. Darum ist das am wenigsten von Architektur und GPU-Entwicklung abhängige Vorgehen:
- Hat man hohe Auflösungen, z.B. für Postprocessing, möglichst alle 1024 Threads ausnutzen. Das hält die GPUs z.B. bei 1080p-Full-HD so lange in Schach, bis Modelle mit mehr als 2000 Shader Clusters herauskommen, was noch dauern dürfte (wird natürlich schon vorher langsam ineffizienter, aber wir wollen ja keine Erbsen zählen).
- Hat man niedrige Auflösungen, z.B. für kleine Texturen und Physikberechnungen – so, dass man mit 1024 Threads nicht mehr alle SMUs bzw. SCs auslasten kann – dann vertraut man darauf, dass Thread Groups auch in Zukunft nicht mehr als 32 Kerne dirigieren können werden (weil ja sonst der Verwaltungsaufwand zu groß wird) und nimmt eine Zahl wie 128, um trotz Speicherlatenz und Stalls eine gute Auslastung pro Gruppe bei möglichst vielen parallelen Gruppen zu erreichen.
- Bei echten CS-Anwendungen ist die Gruppengröße eh davon abhängig, welche Daten untereinander geteilt werden müssen, da kann man dieses Wissen nur für Feintuning nutzen.
Bleibt das Problem, dass die Größe des Ziels ein Vielfaches der Gruppengröße sein muss. Ist es legal, einfach aufzurunden und die überschüssigen Pixel mitzunehmen? Zumindest auf meiner HD 5700 kann ich beliebig über den Rand hinausschreiben und es passiert nichts – aber ich habe keine Lust darauf, dass es nach dem nächsten Treiber-Update oder einer anderen Karte kracht …
Edit: ATI hat natürlich keine 320 Shader Cluster, sondern 20. 320 waren die Shader Units.
