R
hustbaer schrieb:
@rapso:
Haben denn aktuelle GPUs immernoch die Limitierung, dass "Shader-Units" quasio "synchron" laufen?
zu nem gewissen grad: ja
q[teuo]
So wie ich das verstehe kann ich schon ein Shader-Programm schreiben, welches z.B. Schleifen/Verzweigungen enthält, und je nach Koordinaten/Texturinhalt/... unterschiedlich arbeitet. Also z.B. auch unterschiedlich viel durchläufe einer Schleife macht.
Für Pixel 1 brauche ich dann z.B. 20 Durchläufe, für Pixel 2 nur 3, für Pixel 3 dann 5, etc.[/quote]
dann laeuft der shader 20mal fuer alle durch und maskiert nach dem dritten bzw fuenften durchlauf die resultate fuer diese pixel aus.
So wie du das beschreibst müsste man nun annehmen, dass *alle* Shader erst mit dem nächsten Pixel anfangen, wenn die 20 Durchläufe für Pixel 1 fertiggerechnet sind.
mal ein fiktives beispiel:
stell es dir als ein SIMD vor. die gpu hat eine float unit mit 64cycle latenz, bzw 4fach SIMD mit 16cycles latenz, bzw 16fach SIMD mit 4cycle latenz, egal.
fest steht, du wirst mit der instruktion bei Pixel[0] erst in 64cycles fertig. also? also arbeitest du schlauerweise 64pixel gleichzeitig ab, weil es dann im nachhinein wirkt also ob du jedes pixel mit einem-cycle-latenz pro instruktion abgearbeitet haettest.
der fallstrick ist natuerlich, angenommen du hat nun Pixel[0] mit 20 schleifendurchlaeufen und die anderen pixel halt 3 oder 5.
das resultat, wenn du die anderen pixel nicht abarbeitest, waere dass du nun immer 64cycle latenz abwarten musst, du muestest zusaetzlich eine logik einbauen die diese latenz beachtet, also die stumpfe und guenstige loesung ist, immer mit einer granularitaet von 64pixeln zu arbeiten.
So wie ich die Sache verstehe gibt es diese Limitierung aber nicht. Und von daher ist der Begriff Threads nicht so verkehrt.
NV sagt daher, dass sie ihre threads zu "wraps" zusammenfassen, intel spricht von "tuples" usw.
Die Shader haben schliesslich ihre eigenen unabhängigen Register und ihren eigenen unabhängigen Call-Stack. Die Limitierung ist bloss dass alle dasselbe Programm ausführen, und vom selben Datenstrom gefüttert werden, die selben Texturen verwenden etc.
nein, shader haben keine unabhaengigen register. es gibt ein paar tausend die sich alle teilen. es gibt auch instruktionen die auf nachbarregister zugreifen, sogar bei hlsl (DDX DDY), ohne das wuerde mipmapping nicht funktionieren.
die anzahl der 'threads' die du gleichzeitg ablaufen lassen kannst ist entsprechent HardwareRegisterCount/ThreadRegisterCount und wenn dieser wert zu klein ist, bist du vom performance keller weil die latenzen der anderen einheiten nicht gedeckt werden. (steht aber auch alles im cuda manual).
Bitte korrigiere mich wenn ich da jetzt was falsch verstanden habe.
naja, ist halt ein starkes marketing was hinter sowas steckt, wenn cuda nicht waere, duerfte ich das hier nichtmal aufklaeren und ohne beweise, wer glaubt schon dass eine shaderinstruktion 64cycles hat ;), nvidia usw. sagen immer 1cycle und einem thread sheduler der ohne 'kosten' branchen kann usw.
