[OpenGL] Blend/Binormal/Tangent-Attribute an OpenGL senden?

[Schrompf]

Sachma... Eisflamme? Liest Du, was ich schreibe? Bitte strapaziere meine Geduld nicht.

Wenn das Profil sagt, Du kannst 96 Shaderkonstanten haben, dann klingt das für mich sehr nach VertexShader-Modell 1.1. Das ist alt - auch die Mobility-Variante einer Radeon 4870 sollte da Meilen drüber hinaus sein. Es wird also wohl eher am verwendeten Shaderprofil liegen. Und da musst Du wohl mal die CG-Doku fragen müssen, wie man das angibt oder welche der unterstützt. Bei Direct3D kann man bei der Übersetzung des Shaders ein Shaderprofil angeben, z.B. vs1_1 oder vs3_0 - vielleicht gibt es sowas auch für CG.

Und das ein float4[100] schief geht, ist doch offensichtlich, oder? Du hast doch selbst geschrieben, dass der Getter als Maximalwert nur 96 Shaderkonstanten zurückgibt. Was genau wolltest Du mit dem Experiment rauskriegen? Wenn Du mal nach column_major googelst, würdest Du lesen, dass es zwei verschiedene Schreibweisen für eine Matrix gibt: column major und row major. Die besagt eigentlich nur, in welcher Reihenfolge die Elemente der Matrix im Speicher liegen. Für eine 4x3-Matrix könnte das so aussehen:

Code: Alles auswählen

Jx Kx Lx Tx
Jy Ky Ly Ty
Jz Kz Lz Tz

oder

Code: Alles auswählen

Jx Jy Jz 0
Kx Ky Kz 0
Lx Ly Lz 0
Tx Ty Tz 1

(nur als Beispiel, mit J, K, L als die drei Basisvektoren und T als Translationsanteil)

Ich habe hier schon dargestellt, wie die Matrix in den Konstantenregistern drinliegen würde - die Konstantenregister sind nämlich immer 4xfloat groß, egal wieviel man reinlegt. Wenn Du einen einzelnen float als Konstante definierst, wird der in einem einzelnen Konstantenregister abgelegt, also als (x, 0, 0, 1) - der Compiler kann nicht für Dich mehrere Einzelkonstanten zusammen in ein Konstantenregister legen. Daher ist bei obiger Betrachtung der Speicherlayout-Methoden auch klar, warum column_major vs. row_major auch so wichtig ist: in der einen Form brauchst Du 4 Konstanten pro Bone-Matrix, in der anderen Form nur 3. Bei 96 Shaderkonstanten macht das einen Unterschied von 24 zu 32 Bones. Ich würd mir überlegen, ob ich da nur aus Google-Faulheit soviele Bones verschenke.

[noch ein edit]Evtl. ist auch CG einfach nicht mehr unterstützt für neuere Shadermodelle. In dem Fall musst Du auf eine andere Technikbasis wechseln - es gibt da nach meinem Halbwissen auch irgendwelche ARB-Extensions, um Shader zu erstellen. Oder Du benutzt die neueste Errungenschaft von Assimp, den SplitByBoneCount-Postprocess. Der teilt Meshes auf, so dass jeder Teilmesh unterhalb einer Maximalanzahl Bones bleibt. Wenn Du den auf 20 oder wasweißich Bones konfigurierst, kriegst Du ein Rudel Teilmeshes, die Du jeweils einzeln rendern kannst.

[Eisflamme]

Hallo,

Zunächst Mal vielen Dank für die ausführliche Erklärung dessen, welchem ich unfähig war selbst herauszufinden. Ich habe ich gelesen, was Du geschrieben hast. Bist du sauer, dass ich nicht nach column_major gegooglet habe? Das habe ich getan aber "cg column_major" und "cg column major" haben mir haufenweise Quellen geliefert, die nicht Mal im Ansatz so intelligente Ideen wie "jedes Konstantenregister besteht aus float4, daher ist column_major-Interpretation eines float4x3 deutlich effektiver als row_major-Interpretation" geliefert haben. :( Vielleicht bin ich auch nicht in der Lage Google zu benutzen, vielleicht denke ich zu wenig wie eine Suchmaschine, aber bzgl. cg finde ich fast nie vernünftige Dinge. Oder sollte ich die Googleseiten bis zum Ende durchblättern? Aber mit zunehmender Seitenzahl werden die Ergebnisse ja noch schlechter.

column_major habe ich dann auch gefunden, wobei er mir bei "uniform column_major float4x3 BoneMatrices[60]" meldet, dass er eine nicht-Matrix nicht column_major deklarieren kann. Keine Ahnung, was das soll und Google liefert zu "cg column_major" kein einziges Beispiel. Und wenn ich [60] testweise wegmache, sagt er mir "column_major" nicht supported. Auch mit vp30 bzw. vs_2_x ändert sich daran nichts.

Dann habe ich jetzt endlich herausgefunden, dass das Ding vs_1_1 nutzt... wird einem nicht gesagt, wenn man Fehler im Compiler erhält...

Okay, trotzdem verstehe ich nicht, wieso obiger Code läuft, wenn ich keine Konstante float4(1,1,1,1) sondern eine Variable. Wie gesagt, ohne float4 meckert er nicht Mal bei 200 Konstanten, wobei ich mich frage, wieso das so ist, wenn vs_1_1 nicht mehr kann.

Wie auch immer, vielen Dank. Das Problem scheint sich gelöst zu haben, jdf. wenn ich rausfinde, wie ich höhere Shaderversionen erzwinge -_-

[Eisflamme]

Ok, nächstes Problem: cgGLGetLatestProfile ist schlecht. Es liefert mir immer nur die ältesten Profile zurück, obwohl ganz klar mehr unterstützt werden. Hat nicht zufällig jemand ne Idee, woran das liegen könnte, oder? Ich vermute ja, das liegt an dem veralteten OpenGL-Header... Aber GLEW wird da wohl nicht helfen.

Vll. liegt's daran, dass ich CG1.x hatte... Jetzt hab ich auf CG3.x upgegraded... lol. Mal sehen, ob's klappt, werd ich später rausfinden. Danke erstmal! Und sorry.

[anonym]

Spezifikation und Manual dürften einige Fragen beantworten: Viel Spaß damit;)
Bisschen Offtopic: Meiner Erfahrung nach bringt einmal konsequent einige Stunden Entwicklerhandbuch und eventuell Spezifikation Lesen am Ende deutlich mehr, als auf gut Glück mit google und/oder Unterstützung aus einem Forum drauflos zu arbeiten. Das kostet einfach nur unnötig viel Zeit und verursacht Stress. Ich muss mich bis heute zwingen, nicht wieder in das alte Verhalten zurückzufallen, wenn mal wieder eine "geniale" Idee ansteht und ich Fortschritte sehen will, aber mir stattdessen erst einmal ein paar Stunden irgendein trockenes Handbuch reinziehe. Auf die gesamte Projektlaufzeit gesehen, führt das aber tatsächlich zu besseren und schnelleren Ergebnissen und damit am Ende auch einem deutlich größeren Erfolgserlebnis, da nicht pausenlos irgendwas hakt und google dazu nichts passendes ausspuckt oder wieder einmal nur bedingt richtiges Halbwissen auskotzt. Bei Folgeprojekten auf Basis derselben Technologie noch viel mehr.

[Schrompf]

Kein Problem. Hast Du es denn mal mit den 20 Bones probiert? Bring damit mal Deine Shader zum Laufen, danach kannst Du ja weitersuchen. Was die Details zum Syntax angeht, bin ich einfach überfragt... da kann Dir das CG-Manual weiterhelfen. Bleib dran, bleib hartnäckig.

[Eisflamme]

Nächster Witz:
Nach dem Update auf CG3.x wählt cgGetLatestProfile trotzdem VP1_1 und FP1_1 aus, aaaaber die Fehlermeldung mit den max. 96 Dingern verschwindet und column_major funktioniert. Auch lustig ist, dass cgGetLatestProfile einfach nicht klappt: http://developer.nvidia.com/forums/inde ... topic=5302
Ich frag mich, was sich die Entwickler gedacht haben, wenn selbst der simpelste Durchlauf und die Verwendung von absoluten Grundfunktionen nicht anständig unterstützt wird. Zum Glück kann man die Profile von Hand setzen und gut ist.
Jetzt Mal genug zu dem Shadergehampel und auf zu der richtigen Bone-Animation-Programmierung, auch wenn bisher die Summe meiner Bonematrizen und verketteten Nodematrizen (obwohl Skelettanimation geht) bisher in keiner Verknüpfung (Bone * Parent * Childs; Bone * Child * Parent; Childs * Parent * Bone; Parent * Childs * Bone) eine Einheitsmatrix für die Bind Pose ergibt. :) Aber egal.

PS: Danke für den Link! Habe viele kürzere Dokumente und die Spezi genau gelesen und das Handbuch zumindest passagenweise gelesen und die Befehlsliste überflogen. Ein paar nützliche Hinweise waren dabei und ich hab endlich Mal was Vernünftiges zum Nachlschlagen!

[Schrompf]

Es ist entweder Offset * Node * Parent * ParentParent oder genau andersrum ParentParent * Parent * Node * Offset, aber keine Mischform davon. Welche der beiden Optionen die richtige ist, hängt von Deinem Matrix-Layout ab.

Und was die Bind Pose angeht: schau erstmal nach, ob das Skelett auch wirklich in Bind Pose geliefert wird :-) Viele Grafiker probieren ihre Anims vor dem Export noch durch und exportieren das Skelett (also die Trafos der Nodes) dann in der Pose der zuletzt angeschauten Anim. Du kannst aber auch aus den Offset-Matrizen die Bind Pose errechnen, solange keine unbenutzten Bones in der Skelettstruktur hängen. Die Offsetmatrix transformiert ja vom Mesh zum lokalen Bone. Wenn Du die invertierst, hast Du die Trafo von Bone zum Mesh. Und jetzt musst Du daraus nur noch die Trafo des Parent-Bones zum Mesh rausrechnen und hast die lokale Bind Trafo des Nodes. Klappt natürlich nur, wenn der Parent Node auch ein Bone ist und Du demzufolge dessen Offset Matrix kennst.

[Eisflamme]

Also ich arbeite gerade mit dem dwarf und dem testwuson. Da weißt Du nicht zufällig, ob die in Bind Pose sind? Ich werde die Berechnung, die du beschrieben hast, wohl auch noch ausprobieren, aber gerade bin ich mit dem Verständnis leider noch nicht so weit, da brauch ich Mal ein paar Stunden Muße, um genau drüber nachzudenken... Ich schau Mal, dass ich einfach alles in den Shader schmeiße, animiere und hoffe dann, dass ich durch ausprobieren zur Lösung komme. Wird bestimmt nix und ich muss alles nochmal komplett durchdenken, aber gut. :)

Edit:
Na super. Indexzugriff auf Matrizen via variablen Index (also über ein VertexAttribut) geht erst wieder ab VP30. Und wenn ich das manuell einstelle, da ja wie beschrieben CgGLGetLatestProfile() nicht klappt, wird mein Shader einfach nicht ausgeführt, obwohl das Programm erstellt werden kann. Mistzeug...

[Schrompf]

Unter DirectX geht der Arrayzugriff mit variablem Index schon ab VS1.0 - ich glaube, bei Dir ist ne Menge mehr im Argen als nur die Matrixmathematik. Hast Du denn schonmal einen eigenen Shader geschrieben und erprobt?

[Eisflamme]

Hi,

Also erstmal muss ich sagen, dass vp20 und vp30 NVIDIA-proprietäre Profile sind, d.h. die laufen nicht auf meiner ATI. :oops: :roll: glslv ist anscheinend das Profil, das ich wählen sollte, welches auch läuft (auch wenn ich das selbst zuweisen muss, weil CG das nicht korrekt macht). Hintergrund meiner falschen Auswahl ist, dass im CG Tutorial nur diese Formate in dem Tutorial stehen und ich mich danach gerichtet hatte.

Was ich an Shadern schon gebastelt habe, ist ein einfaches Durchreichen von Texturkoordinaten, Farben, das Umrechnen von Positionen über die ModelView-Kombimatrix und ein paar simple perVertex-Lights über Punktprodukt von Normalenvektor und einer hardgecodeten Lichtquelle. Habe ich auch Mal gemacht, indem ich Normalekoordinaten über TEXCOORD2 zugewiesen habe... d.h. ich hab bisher nicht wirklich was Gescheites gemacht, aber das funktioniert mit ARBVP1 halt alles.

Die Fehlermeldungen von CG sind halt auch nicht wirklich aussagekräftig. Ich werde den Shader später Mal posten, er ist sehr kurz und gerade versuche ich auch nur ein einzelnes Gewicht einzurechnen (auch wenn alle nicht viel mehr Aufwand sind).

PS: Ich habe hier keinen Zugriff auf den Laptop, an dem ich am WE rumspiele, da Uni. Darum kann ich hier ein wenig testen, hab aber gerade nicht den Shadercode vorliegen, nur um Irritationen auszuschließen.

[Eisflamme]

Ich komm gerade wieder nicht weiter, weil ich Shader nicht verstehe...

Ich hab folgendes einfache Programm:

Code: Alles auswählen

OUT.color		= float4(dot(IN.normal, float3(1,1,1)), 0, 0, 1);

gut, es ist etwas umständlich durch die casts und so, ich bastel hier alles mögliche rum. Der Punkt ist, dass ich entweder korrekte normals übergebe, dann wird mein Modell schön schattiert. Oder ich übergebe nur Nullen (wieso, sag ich gleich) und dann ist es schwarz, so weit so gut.

Jetzt habe ich mein anderes Programm:

Code: Alles auswählen

	for(float n = 0; n < 60; ++n)
		dummy[n] = float4x3	  (	1, 0, 0,
								0, 1, 0,
								0, 0, 1,
								0, 0, 0);

	float k = 0;

        objPos = mul(dummy[k], IN.position.xyz).xyz;

es dient zu Testzwecken, da ich ja nicht debuggen kann o.ä. Jedennfalls führt das hier dazu, dass mein Modell einfach mit einer Einheitsmatrix multipliziert wird, wenn k einen Index hat, mit dem ich arbeiten kann. Wenn ich jetzt aber k nicht auf 0 setze, sondern auf IN.normal.x, wenn ich lauter Nullen übergebe (also im Endeffekt doch wieder 0), dann dumpt mein Grafikkartentreiber. D.h. die Indexierung funktioniert so anscheinend nicht.

Wieso nicht? IN.normal sollte = float3(0.f, 0.f, 0.f) sein und damit sollte jede Komponente gleich 0.f sein also den gleichen Effekt haben wie wenn ich float k = 0 direkt schreibe (ich habe auch schon 0.f statt 0 geschrieben, daran kann das nicht liegen). Dennoch hat es einen anderen Effekt. Unschwer zu erkennen, dass dadurch meine gesamte Bone/Node-Animation auch nicht funktioniert.

Anscheinend habe ich wieder Mal irgendwas Dummes nicht verstanden, aber hat jemand eine Idee? Ich habe überlegt, ob es Rundungsfehler sein könnten oder irgendwas, aber das ergibt ja auch keinen wirklichen Sinn, wenn ich programmintern 0.f schreiben kann und es klappt. -_-

[Schrompf]

Das dummy-Array passt in keine temporären Register des Shaders. Der Code klappt nur, solange der Compiler feststellt, dass alle Eingabevars zur Compile Time bekannt sind - er rechnet dann wahrscheinlich sofort den Normalenvektor als 0 aus und schreibt das in den Shader. Sobald Dein Matrix-Index aber von einer unbestimmbaren Eingabevariable abhängen, kann er das Ergebnis nicht mehr zur Compile Time ausrechnen. Und da sprengst Du dann mit Deinem dummy-Array alle Grenzen der aktuellen Hardware.

Lege das Matrix-Array mal als globale Konstanten an und setze die von außen auf Einheitsmatrix. Dann sehen wir weiter.

[Eisflamme]

Ah, danke für den Hinweis. :)

Nach ein paar Stunden Suche, was denn jetzt falsch sein könnte, hat sich herausgestellt, dass ich einfach nur dum bin (ja, nicht dumm, sondern dum):

Code: Alles auswählen

	void Mesh::SetBoneIndicesData(BoneIndicesType* boneIndices, unsigned int boneIndicesCount)
	{
		// Generate and Bind the BoneIndices Buffer
		glGenBuffers(1, &boneIndicesID_);

		// Bind Buffer
		glBindBuffer(GL_ARRAY_BUFFER, boneIndicesID_);

		// Load Data
		glBufferData(	GL_ARRAY_BUFFER,
						boneIndicesCount_ * 4 * sizeof(GL_CoordinateType),
						boneIndices,
						GL_STATIC_DRAW);

		boneIndicesCount_ = boneIndicesCount;
	}

Wer findet den Fehler :roll:

Jetzt habe ich einen arg verstümmelten Zwerg, der irgendwelche sehr irritierenden Bewegungen macht. Sind wohl noch so einige Dinge falsch, aber daran kann ich arbeiten. :)

[Eisflamme]

Sorry, aber ich habe gerade mindestens drei Stellen gleichzeitig, an denen was nicht klappt, daher bin ich absolut verloren... Ich fühl mich auch ganz klein und hässlich dabei, hier das Forum zuzuspammen, aber was soll ich tun... -_-

Also ich übergebe gerade genau 480 floats, wobei alle 12 einer Einheitsmatrix entsprechen. Mein Shadercode ist neuerdings:

Code: Alles auswählen

objPos = mul(BoneMatrices[IN.boneIndices.x], IN.position.xyz).xyz;

Gewicht habe ich Mal weggelassen, dafür auch die Zeilen für die anderen 3 Bonegewichte. Aber das Gewicht scheint sowieso immer nur auf dem ersten Index zu liegen, also ist das ja erstmal egal (sicherheitshalber, habe ich weight aber auch = (1,0,0) gesetzt).
Die BoneMatrizen sind wie gesagt ge-einheitsmatrixt. IN.boneIndices.x wird mittlerweile imo korrekt übergeben. Leider ist die Anzeige jetzt einfach leer.

Wenn ich vor der Multiplikation jetzt:

Code: Alles auswählen

IN.boneIndices.x = 0;

mache, funktioniert das und der Zwerg wird (natürlich unanimiert) angezeigt. Schreibe ich aber Folgendes:

Code: Alles auswählen

	if(IN.boneIndices.x != 0)
		IN.boneIndices.x = 0;

[/code]
ist das Bild wieder leer. So weit versteh ich Mal wieder gar nichts, aber das ist ja nichts Neues.

Ich habe dann einfach Mal hart die einzelnen Zahlen (also IN.boneIndices.x) hochgezählt. Resultat: Bis 11 wird Zwerg angezeigt, ab 12 nicht mehr. Ich habe aber einen float* von 480 Elementen, auch ab Element 12*12 = 144 sind die Werte korrekt. Und wie viele Elemente er nimmt, hängt ja von der Definition im Shader-Programm-Funktions-Header ab (uniform column_major float4x3 BoneMatrices[40] sollte ja genau stimmen).

Mir drängt sich also auf, dass dieses Ding nicht mehr als 11 Matrizen gleichzeitig annehmen kann, was mich aber sehr wundern würde, zumal er dann ja schon vorher meckern sollte, richtig? Zudem nutze ich mittlerweile GLSLV, ein CG-Profil, was angeblich GLSL1.3 unterstützt, also keinen tollen Murks... Jetzt hab ich hier Mal die Spezi von GLSL1.2 gefunden, aber ich hab nur unter uniform geschaut und sonst kA, wo ich sehen könnte, ob es ein Limit gibt: http://www.opengl.org/registry/doc/GLSL ... 1.20.8.pdf
Okay, ich hab noch unter Konstanten nachgeschaut und das hier gefunden:
const int gl_MaxVertexUniformComponents = 512;
Das sollte doch dann locker reichen (angenommen, ich nutze gerade nur GLSL 1.2 und nicht sogar 1.3; mehr als 40 Bones brauch ich gerade nich)... Hab auch nochmal im NVIDIA-Forum gepostet, vll. weiß da wer was, auch wenn der Logikfehler üblicherweise bei mir liegt.

[Eisflamme]

-

Ich bin einfach dumm wie'n Stück Brot. Ein altes, nicht mehr genießbares, schon etwas schimmeliges Stück Brot.

[Eisflamme]

Juchu!!!!!!!!!!!!!!!!!!

Endlich! Es geht! *schalala schalalala* Der Zwerg hampelt rum, wie es sich eben gehört. Dass ich das noch erleben darf, hätt ich echt nicht gedacht!!

Herzlichen Dank nochmals!!! :)

[Schrompf]

Tu Deiner Umwelt und allen, die nach Dir kommen, einen Gefallen und schreibe hin, woran es gelegen hat :-)

[Eisflamme]

Hi!

Aber gerne, auch wenn's peinlich ist. Allerdings glaube ich, dass die wenigsten dieses Problem haben werde. Ich bin nämlich einfach dämlich.

Um mit CG + OpenGL Parameter zu übergeben, muss man cgGLSetMatrixParameterArray{fd}{cr}() nutzen (f = float, d = double; c = column major, r = row major).

Na ja... und die Parameter hab ich einfach falsch verstanden. Parameter 1 sollte klar sein, 2 ist ein Offset (wayne, das ist 0) und der dritte ist die Anzahl von Matrizen. Ich dachte, es wäre die Anzahl von Elementen pro Matrix. Und daher stand da ne 12 -_- (früher gab's hier einen Kopf-gegen-die-Wand-schlaf-Smiley, wurde der zur Rettung von Gehirnzellen gelöscht?), s.a.: http://http.developer.nvidia.com/Cg/cgG ... rayfc.html
Das war ein Fehler. Ein anderer war, dass ich zwischendurch zwischen column/row major abgewechselt hatte, aber vergaß auch die entsprechend andere Methode zu nutzen, sodass ich ein r nutzte statt einem d.

Gut, dann musste ich noch korrigieren, dass bei mir parentParent * parent * node * offset statt offset * node * parent * parentParent die richtige Variante war.

Na ja, jetzt kommt eine angenehmere aber auch nicht sehr angenehme Arbeit. Code sauber schreiben, Architektur umbauen, Shader verbessern/genauer machen, Performance verbessern, indem ich irgendwie nicht in jedem Programmdurchlauf alle 4x4-Matrizen auf 4x3 runterrechne und erneut in nem vector speicher, pro ModelInstance unabhängige Schleifendurchläufe erzeugen, ... ... ...

PS: Sag Mal, wieso errechnet ihr das 4. Gewicht eigentlich als Punktprodukt aus float3(1,1,1) und den restlichen Gewichten und nicht einfach z = 1 - weight.x - weight.y - weight.z ?

[anonym]

Da ich mir hier gerade ArchLinux antue und somit keinen Beweis anhand eines offline compilierten HLSL-Shader-Bytecodes antreten kann, nehme ich einfach mal an, dass es der Performance zuträglich ist, anstatt 3 skalarer Instruktionen eine Instruktion für das Skalarprodukt auszuführen:

Code: Alles auswählen

weight.w = (-1) * weight.x + (-1) * weight.y + (-1) * weight.z + 1 * 1 = dot(float4(-1, -1, -1, 1), weight)

Angenommen weight wird vom Input-Assembler vom float3 im Vertexbuffer zum impliziten float4 mit w=1 im Parameter beförtert (Würde w=1 im Vertexbuffer mitgeführt könnte man sich das ganze sowieso sparen). Hier stellt sich die Frage, ob der Compiler das nicht selbst so umformt oder was dann der Treiber mit dem Bytecode noch so alles anstellt. Das Skalarprodukt sollte zumindest bei AMDs GPU-Architektur spätestens dann auch ohne die HLSL-Optimierung so rauskommen. Ich glaube nicht, dass das mit aktuellen Compilern noch eine Rolle spielt.

[Eisflamme]

hm... okay, das hab ich sogar auch vermutet, wobei im Assimp-Shader dot(float3(1,1,1), weight) steht. Aber ich versteh gerade nicht, wieso das Punktprodukt überhaupt den Rest ergibt.

[anonym]

Ob HLSL oder GLSL, am Ende spielt es keine Rolle.

Code: Alles auswählen

float4 a(in float3 p : POSITION) : SV_POSITION
{
	return 1 - dot(float3(1, 1, 1), p);
}

float4 b(in float4 p : POSITION) : SV_POSITION
{
	return dot(float4(-1, -1, -1, 1), p);
}

float4 c(in float3 p : POSITION) : SV_POSITION
{
	return 1 - p.x - p.y - p.z;
}

Code: Alles auswählen

//a
// Approximately 3 instruction slots used
vs_5_0
dcl_globalFlags refactoringAllowed
dcl_input v0.xyz
dcl_output_siv o0.xyzw, position
dcl_temps 1
dp3 r0.x, l(1.000000, 1.000000, 1.000000, 0.000000), v0.xyzx
add o0.xyzw, -r0.xxxx, l(1.000000, 1.000000, 1.000000, 1.000000)
ret

//b
// Approximately 2 instruction slots used
vs_5_0
dcl_globalFlags refactoringAllowed
dcl_input v0.xyzw
dcl_output_siv o0.xyzw, position
dp4 o0.xyzw, l(-1.000000, -1.000000, -1.000000, 1.000000), v0.xyzw
ret

// c
// Approximately 4 instruction slots used
vs_5_0
dcl_globalFlags refactoringAllowed
dcl_input v0.xyz
dcl_output_siv o0.xyzw, position
dcl_temps 1
add r0.x, -v0.x, l(1.000000)
add r0.x, r0.x, -v0.y
add o0.xyzw, r0.xxxx, -v0.zzzz
ret

b funktioniert wegen

Partial (0, 0, 0, 1) - If only a subset of channels are updated, the remaining channels will default to (0, 0, 0, 1).

, da float3 zu einem float4 gemacht werden kann und w dabei als 1 gesetzt wird.
Ich denke nicht, dass es hier eine mathematische Herleitung für die Verwendung des Skalarprodukts gibt. Es ist wohl eher Zufall, dass dieses Konstrukt von Skalarprodukt etwas entspricht, was zweckentfremdet werden kann, um hier eine Berechnung auf manchen Architekturen (z.B. AMD GPU, Intel SSE4 oder ARM) effizienter durchzuführen. (Ich lasse mich aber auch gerne eines besseren belehren)

Code: Alles auswählen

weight.w 
= 1 - weight.x - weight.y - weight.z
= 1 * 1 - 1 * weight.x - 1 * weight.y - 1 * weight.z
= (-1) * weight.x + (-1) * weight.y + (-1) * weight.z + 1 * 1
= (-1, -1, -1, 1) * weight

[Eisflamme]

Na ja, ok. dot(x,y) = x1*y1 + x2*y2 + x3*y3

Da dot ne GPU-Funktion ist, läuft die halt vermutlich schneller als zwei Subtraktionen, vermutlich gibt es für dot halt ein eigenes "Ding" (<- was genau ist das technisch eigentlich?) oder so. Und in Assimp ist es halt w = 1 - dot(weights, float3(1,1,1)). Gut, gut, dann kapier ich das, danke. :)

[Krishty]

Da dot ne GPU-Funktion ist, läuft die halt vermutlich schneller als zwei Subtraktionen, vermutlich gibt es für dot halt ein eigenes "Ding" (<- was genau ist das technisch eigentlich?) oder so.

Da das Skalarprodukt früher eine der am häufigsten genutzten Rechenoperationen in Grafikprozessoren war (wegen Transformation und Beleuchtung der Vertices) bietet das Rechenwerk (Arithmetic Logical Unit, ALU) das üblicherweise als native Rechenoperation in einem einzigen Takt an. Da das das größte Verhältnis von Takt zu Anzahl ausgeführter Rechenoperationen ergibt, wurde es oft herangezogen, um das Leistungspotential von GPUs (in FLOPS) zu bewerten … heute ist es aber eher öfter die Multiply-Add-Anweisung; wegen der Verschiebung von Superparallelität zu Superskalarität, glaube ich.

[Eisflamme]

Ah, okay, danke.

Ich verstehe nur den letzten Satz nicht ganz. Wieso ergibt dot, mit einem Takt, das größte Verhältnis von Rechenoperationen zu Takt an? Wenn da "kleinste" stünde, würd ich's verstehen, meintest Du das oder hab ich falsch gedacht?
Und die Superbegriffe sind wohl was zum Nachschlagen in der Vorlesung morgen. ^^

[Krishty]

Ein DP4-Befehl führt in einem Takt vier Multiplikationen und drei Additionen auf seine Operanden aus, also sieben Rechenoperationen pro Takt. Ein Additionsbefehl führt bloß eine Addition pro Takt aus. Wenn du also einen 100-Mhz-Prozessor mit Skalarprodukten fütterst, kannst du 700 MFLOPS Rechenleistung erreichen; bei einer Fütterung mit Additionen nur 100. Dass man als Hersteller lieber die hohe Zahl nennt, dürfte klar sein. Aber heute ist das, wie gesagt, nicht mehr so einfach (ich weiß garnicht, ob moderne GPUs das DP4 noch in einem Takt schaffen).

[Eisflamme]

Okay, jetzt hab ich's kapiert. Also zu Superparallelität habe ich eigentlich gar nichts gefunden. Laut wiki bedeutet Superskalarität aber anscheinend eine Erweiterung der Ausführung eines Befehls pro Takteinheit. Ist Superparallelität dann, dass mehrere Prozessoren gleichzeitig laufen, während Superskalarität halt mehrere Befehle pro Takt hat? Gibt es denn sogar mehrere Kerne für GPUs?

[Schrompf]

Aber ja :-) Die aktuelle Geforce hat 512 Shaderkerne, von denen jeder gleichzeitig 4 floats verrechnen kann.

Nach meiner Rechnung wäre übrigens ein MAD besser für GFLOP-Rechnungen: 4 muls und 4 adds. Ein dot bringt ja nur 4 muls und 3 adds auf die Waage :-)

[anonym]

Ich dachte, nVidias Strategie (Superthreaded) wäre seit der G80, Skalar- anstatt Vektorprozessoren zu verwenden. Die machen aufgrund der deutlichen höheren Auslastung der einzelnen Streamprozessoren die theoretisch fast 3x so hohe Streamprozessorzahl der AMD-Karten platt. Die sind als MIMD-Einheiten ausgelegt und haben deshalb massive Probleme mit Abhängigkeiten von Berechnungen zu vorhergehenden Ergebnissen, z.B. x1 = a + b, x2 = x1 + c, x3 = x2 + d, ....

[Schrompf]

Hm. Dafür stecke ich nicht genug in der Material. Nach meinem Wissen sind die enormen Rechenkern-Zahlen von ATI nur Marketing-Mathematik: man gibt halt die skalaren Einheiten an anstatt der Vektoreinheiten.

[anonym]

Genau dieses Marketing meinte ich, da eben nicht alle Registerplätze bei jeder Instruktion genutzt werden und somit je nach Aufgabe viel Leistung verloren geht.
Endlich habe ich die Seite wieder gefunden: Zur nVidia G80-Architektur

Each math processor is a scalar (1-channel) ALU with exposed FP32 precision