PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Shader? WTF sind Shader?// aus "ATi und die Meinung zu Profilen..."


Gast
2006-05-07, 15:48:14
The_Invisible[/POST]']wie können sie in sachen technik total (ich liebe diese sinnlosen übertreibungen hier im forum :D) überlegen sein wenn ihre chips herdplatten sind, im crossfire mode mehr verbrauchen als Quad-SLI und nicht schneller sind als die konkurrenz? das musste mir erklären...

zudem müsste dann die 6800er reihe der x8y0 reihe in sachen technik ja sowas von krass überlegen sein, da sie ja nichtmal SM3 oder HDR hatten :eek: aber wehe man hatte das früher als argument gebracht...

mfg

Mhh...da hats du recht.
Es ist aber wie immer etwas problematisch zu betrachten.
Was ist wichtiger?
HDR+AA
oder Stromverbrauch
(Nur als Beispiel)
Ich meinerseits würde mir eher eine X1900XT kaufen als eine 7900gtx, da für mich einige Kriterien mehr überwiegen.

Der NV40 war oder ist zu schwach für SM3, die R400-Serie konnte nur Fakehdr darstellen.
Es wäre schön gewesen wenn die X8X0-Serie Ps 3.0 und HDR gehabt hätte, aber man sieht es ja wo es hinausläuft.
Man kann nichteinmal CSS mit HDR und hohen Details flüssig darstellen, die Frames sinken manchmal wirklich ins bodenlose.


Aber warum sehen wir in die Vergangenheit, zurzeit sind die Konkurrenten der R580 und der G71, warum sich mit der Vergangenheit beschäftigen?
Gesplittet aus:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=295072&page=1&pp=20

Gast
2006-05-07, 16:23:40
Gast[/POST]']Der NV40 war oder ist zu schwach für SM3Bitte nicht schon wieder dieses Märchen.

Mr. Lolman
2006-05-07, 17:14:13
AnarchX[/POST]'][ ] Ich weiss was Shadermodel 3.0 ist und für eine Graka bedeutet? ;)

Er hat trotzdem recht. Die notwendige Rechenleistung für ein Spiel mit Effekten, die nur mit SM3 zu bewerkstelligen sind, ist bei einem NV40 nicht unbedingt gegeben.

Odal
2006-05-07, 18:06:53
um nochmal das SM3 Ding aufzugreifen ^^

Ich mein es ist ja richtig das Devs die Möglichkeit haben mit SM3 shader zu beschleunigen...aber sie müssens auch machen. Shaderprogramme die von SM3 deutlich profitieren werden sind sicherlich eher die Leistungfressenden und für die kurzen bzw. einfachen Shader (nicht so rechenlastigen) sagt sich der Dev wahrscheinlich: "Na ob ich da jetzt mit SM3 noch ein halbes FPS heraushole oder nicht ist dann auch egal die erhöhte Instruktionsmenge vom SM2_a bzw. SM2_b Profil reicht hin zur Passreduzierung."
siehe Oblivion.
Falls man jetzt meint "naja der Dev kann aber seine Faulheit durch das nutzen von static Branching unterstützen" so sollte man doch bedenken das man irgendwie sowieso einen SM2(_x) Pfad braucht, da man es sich im Allgemeinen nicht leisten kann auf soviele potentielle Käufer zu verzichten.

klar kann man immer Beispiele konstruieren wo ein sehr aufwendiger SM2_x Shader zu einem sehr schnell zu berechnenden SM3 Shader umfunktionierbar ist. Aber kommt sowas wirklich häufig vor? Farcry hat zwar etwas Profitiert vom "SM3 Patch" aber fast/genausoviel hat es vom SM2_x Profil profitiert.

Coda
2006-05-07, 20:04:34
Mr. Lolman[/POST]']Ich weiss so ca. wo die Limits bei SM2 liegen und dass neben so netten Dingen wie der Einführung von bedingten Verzweigungen auch die max. Instructionlenght erhöht wurde. Nun ists ja so, dass man die NV4x/R4x0 auch schon mit reinen SM2 Effekten ziemlich in die Knie zwingen kann.
Das meinte ich nicht. Du solltest mal verstehen was ein Vertex- und ein Pixelshader für Inputs und Outputs hat und was er genau machen kann und was nicht. Weil manchmal kommts mir so vor als rezitiert ihr immer wieder den gleichen Müll den ihr halt irgendwo aufgeschnappt habt.

Gast
2006-05-07, 20:25:05
Coda[/POST]']Das meinte ich nicht. Du solltest mal verstehen was ein Vertex- und ein Pixelshader für Inputs und Outputs hat und was er genau machen kann und was nicht. Weil manchmal kommts mir so vor als rezitiert ihr immer wieder den gleichen Müll den ihr halt irgendwo aufgeschnappt habt.

Was man so im Netz für Informationen bekommt sind teilweise wirklich ernüchternd, ich würde wirklich gerne wissen wo man mehr Informationen bekommen kann, und ich gebe zu das ich mich nur mit den Grundlagen etwas auskenne und das ich kein so ein 3D-Guru bin wie du...*heul*

Gast
2006-05-07, 20:29:45
Mr. Lolman[/POST]']Ja, SC:CT hat damals die SM3 Diskussion ganz schön angeheizt. Und die Gesichter wurden aufeinmal alle lang, als ein (von ATi programmierter) SM2 Pfad fast die gleichen Effekte ermöglichte.Der SM2-Pfad war aber bei weitem nicht so schön, wie SM3 + HDRR. Vor allem gab es dort zum Teil übelstes Colorbanding.

Coda
2006-05-07, 20:35:43
Gast[/POST]']Was man so im Netz für Informationen bekommt sind teilweise wirklich ernüchternd, ich würde wirklich gerne wissen wo man mehr Informationen bekommen kann, und ich gebe zu das ich mich nur mit den Grundlagen etwas auskenne und das ich kein so ein 3D-Guru bin wie du...*heul*
Den Zynismus kannst du dir sparen. Viele Infos gibts z.B. in der DirectX-Dokumentation die jedem zugänglich ist.

Mr. Lolman
2006-05-07, 22:29:03
Coda[/POST]']Das meinte ich nicht. Du solltest mal verstehen was ein Vertex- und ein Pixelshader für Inputs und Outputs hat und was er genau machen kann und was nicht. Weil manchmal kommts mir so vor als rezitiert ihr immer wieder den gleichen Müll den ihr halt irgendwo aufgeschnappt habt.

Anstatt dass du mir andauernd Unwissenheit vorwirfst, sag lieber mal worauf du hinauswillst. Andere wie Deppen dastehen lassen, nur weil sie bisher vll. keinen so tiefen Einblick in die Materie genossen haben, spricht nicht für eine feine Diskussionskultur.

Coda
2006-05-07, 22:32:47
Mr. Lolman[/POST]']Anstatt dass du mir andauernd Unwissenheit vorwirfst, sag lieber mal worauf du hinauswillst.
Ich will darauf hinaus dass für fast alle (wenn nicht alle) die noch nie nen Pixelshader programmiert haben die Diskussion eine reine "mag ich ATi oder nVIDIA"-Sache ist, nichts mit der Technik zu tun hat und die Argumente eben entsprechend von Leuten die etwas davon verstehen herausgepickt werden wie sie einem passen.

Das ist keine Diskussion, das ist nur fortlaufende Propaganda.

Mr. Lolman
2006-05-07, 23:06:37
Coda[/POST]']Ich will darauf hinaus dass für fast alle (wenn nicht alle) die noch nie nen Pixelshader programmiert haben die Diskussion eine reine "mag ich ATi oder nVIDIA"-Sache ist und nichts mit der Technik zu tun hat.

Das find ich jetzt anmaßend.

Die in Computerspielen mögliche Grafikqualität setzt sich aus Featureset und Leistungsfähigkeit der Chips zusammen. Mit SM3 als Featureset limitiert nur mehr die Leistungsfähigkeit. Und wenn diese so sehr limitiert dass der Consumer kaum zusätzlichen Eyecandy aktivieren kann, ohne dass die Spielbarkeit darunter leidet, ist SM3 für den Spieler sinnlos. Das war natürlich nicht der Fall, jedoch war der NV40 imo keine zukunftssicherere Investition als der R420 weil das Leistungslimit durch das größere Featureset (und der damit verbundenen "Bürde" komplexere Berechnungen durchführen zu müssen) viel früher zu tragen kam.

Dass der R420 nicht des Developers Freund war ist ja hinlänglich bekannt. Aber betrachtet man die Kosten/Nutzen Rechnung für den Spieler kann man sogar verstehen, warum manche ihre 6800GT gegen eine X800XT getauscht haben.

Nur als Beispiel mal die Performance von SC:CT. Zur besseren Vergleichbarkeit hat man sogar HDR (verständlich aufgrund von Darstellungsunterscheiden zw. SM2 und SM3 Karten) und Parallax Mapping (unverständlich) deaktiviert. Und trotzdem ist ne 6800 Ultra um tw. mehr als 30% langsamer als ne X850XT PE: http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_club3d_radeon_x1800_xt_256_mb/18/#abschnitt_splinter_cell_3

Odal
2006-05-07, 23:07:42
Coda[/POST]']Ich will darauf hinaus dass für fast alle (wenn nicht alle) die noch nie nen Pixelshader programmiert haben die Diskussion eine reine "mag ich ATi oder nVIDIA"-Sache ist, nichts mit der Technik zu tun hat und die Argumente eben entsprechend von Leuten die etwas davon verstehen herausgepickt werden wie sie einem passen.

Das ist keine Diskussion, das ist nur fortlaufende Propaganda.

ich denke mal jeder der überhaupt mal was in einer low level programmiersprache programmiert hat kann sich das in etwa vorstellen.

Coda
2006-05-07, 23:10:04
Mr. Lolman[/POST]']Das find ich jetzt anmaßend.
Nein, das ist bloß die Wahrheit.

Mr. Lolman[/POST]']...
Glaubst du ernsthaft du kannst meine Meinung dazu ändern?
Du weißt genau dass ich stets versuche einen Mittelweg zu finden. Wenn jemand behauptet SM3 ist das absolute Wunderding, dann halte ich dagegen. Wenn jemand behauptet es ist nutzlos (wie du es propagierst in diesem Kontext) halte ich ebenso dagegen.

Es ist einfach beides Schwachsinn. Komischerweise kommen genau diese beiden Richtungen immer von Leuten die entweder nVIDIA oder ATI fanatisieren (was du sicher auch leugnen wirst).

Odal[/POST]']ich denke mal jeder der überhaupt mal was in einer low level programmiersprache programmiert hat kann sich das in etwa vorstellen.
Wenn er dann noch versteht was die Unterschiede zw. SM2 und SM3 sind, dann wohl schon. Nur glaube ich das bei denen die ich jetzt meine nicht :tongue:

Odal
2006-05-07, 23:35:50
Coda[/POST]']Das meinte ich nicht. Du solltest mal verstehen was ein Vertex- und ein Pixelshader für Inputs und Outputs hat und was er genau machen kann und was nicht. Weil manchmal kommts mir so vor als rezitiert ihr immer wieder den gleichen Müll den ihr halt irgendwo aufgeschnappt habt.

afaik haben pixelshader als input ne art textur/texturierte fläche...und ein shaderprogramm...und als output wieder ne art textur/texturierte Fläche

das shaderprogramm ist eine art low level programmiersprache (auch wenn CG usw. was anderes suggeriert..mit SM3 gehts natürlich mehr richtung higlevel wie mit SM2 da man mehr möglichkeiten für schleifen usw. hat) und lässt z.b. eine mathematische funktion auf jeden pixel der Textur/texturierte fläche zu...

die mathematische funktion besteht dabei mehr oder minder aus add, mult etc. womit sich komplexere mathematische funktionen darstellen lassen...
praktisch die farbwerte der pixel der textur mit wirgendwelchen werten addieren/multiplizieren....(der shadercompiler von DX kann natürlich komplexere operationen in mehrere adds mults inverse whatever umwandeln...ähnlich wie es ein C-Compiler (c->assembler) macht.

das jetzt nun dynamische (also bedingte) sprünge interessant sind um sowas wie while schleifen etc. zu realisieren ist mir klar...
das jetzt statische sprünge die faulheit des entwicklers und die instrutionsmenge schonen ist mir auch klar..

bsp. eine for schleife for(i=1;i<10;i++){blubb[i]=machblubb*i}; muss entrollt werden in
blubb[1]=machblubb*1;
blubb[2]=machblubb*2;
blubb[3]=machblubb*3;
....
blubb[10]=machblubb*10;

was die instruktionsmenge enorm nach oben treibt ist mir klar...

und ab einem gewissen instruktionslimit is halt schluss (glaube 96 bei ps2.0 und 256 bei ps2.x)

dann muss das shaderprogramm in 2 aufgesplittet werden und nach dem 1. ne art zwischenergebniss erzeugt werden was mit dem 2. nochmal durch die pixelprozessoren gejagt wird (multipass)

das das für den Dev ziemlich nervig ist da er immer ien Auge auf den Instruktionscount haben muss und nicht typische schleifen usw. höherer Programmiersprachen nutzen kann so das das schon fast in lowlevel assembler verkommt (zumindest vom algorithmus des eigentlichen shaderprogramms her) ist mir klar

das man mit sm3 viel einfachere möglichkeiten hat seinen shader zu schreiben ist dann auch klar...nur gibts eben noch genug sm2(.x) karten für die eh lauffähige shaderprogramme erstellt werden müssen....
und sehr lange komplexe shader sind (nicht einzeln angewendet fürs testen sondern in der masse wie sie im spiel vorkommen) dann einfach für einen 350Mhz NV40 mit 16 pixelprozessoren zu langsam....so das diese anspruchsvollen shader eh durch einfache shader (aus dem sm2 Pfad) ersetzt werden müssen..nicht weil man mit SM3 nicht die SM2 shader kürzer oder schneller machen könnte, sondern weil die SM2 shader einfach weniger genaue oberflächenberechnungen anstellen dafür eben die GPU nicht so fordern und sie sind halt da (abwärtskompatiblität).


(ich hoffe ich lag jetzt nicht soooooo falsch :D )

Coda
2006-05-07, 23:43:11
Odal[/POST]']afaik haben pixelshader als input ne art textur/texturierte fläche...und ein shaderprogramm...und als output wieder ne art textur/texturierte Fläche
Genau das ist die falsche Vorstellung davon.

Odal
2006-05-07, 23:43:53
und was ist die richtige vorstellung?

was machen denn die pixelprozessoren soinmst ausser ein vertexgebilde+textur+shaderprogramm zu nehmen und das zusammenzuschmeissen?

Coda
2006-05-07, 23:46:13
Inputs sind die interpolierten Werte der Vertexshader über das Polygon für diese Stelle & Konstanten. Output ist die Pixelfarbe an dieser Stelle und evtl. noch die Tiefe. Man kann damit Texturen samplen, muss aber nicht.

Ein Pixelshader verarbeitet also nicht eine "Textur" sondern immer nur Dinge an einem Punkt und gibt auch nur Dinge an diesem Punkt aus. Er läuft auch für jeden der Punkte neu durch.

Odal
2006-05-07, 23:50:32
naja also nimmt er mehrere vertex (also pratisch punkte mit 3 bzw. 4 koordinaten) die ein polygon (oder vielleicht sogar schon trianguliert Dreieck) aufspannen und die passende textur (anhand der texturreferenz zum vertexgebilde) und rechnet für jeden punkt im vertexgebilde aus textur und shaderprogramm farb/alphawerte whatever aus...alo kommt da ein array von punkten mit RGB+Alpha+XYZ werten heraus?

Odal
2006-05-07, 23:53:05
Coda[/POST]']
Ein Pixelshader verarbeitet also nicht eine "Textur" sondern immer nur Dinge an einem Punkt und gibt auch nur Dinge an diesem Punkt aus. Er läuft auch für jeden der Punkte neu durch.

ja das ist mir schon klar das das shaderprogramm auf jeden punkt angewandt werden muss....und das jeder punkt einzeln in einen pixelprozessor gepusht werden ist mir dann jetzt auch klar...

also zerlegen die vertexprozessoren eine Fläche aus vertex(es) (vertices wie auch immer man den plural ausdrückt) nur in einen sack voller punkte mit xyz koordinaten..natürlich noch mit texturreferenz und referenz auf ein shaderprogramm für die fläche?

damit werden dann die pixelprozessoren gefüttert?

Coda
2006-05-07, 23:59:56
Ok fangen wir von vorne auf. Die Vertexdatendaten (Position, Farbe, Texturkoordinaten) kommen in die Vertexshader werden dort für jeden Vertex verwurschtelt (perspektivische Projektion, etc.) und diese geben pro Vertex bis zu 10 4D-Werte aus die nachher über das Dreieck interpoliert werden sollen (z.B. Farbe, Texturkoordinaten)

Danach wirds interessanter. Das Triangle-Setup nimmt jetzt 3 Eckpunkte und berechnet davon die nötigen Daten um das Dreieck zu zeichnen (Edge-Konstanten, Interpolationskonstanten).

Dann kommt der Rasterizer nimmt die Daten und fängt an das Dreieck in jeder beliebigen Reihenfolge der Pixel abzuarbeiten (das ist übrigens bei nVIDIA sehr seltsam kreuz- und quer, weil sie da irgendwie die Cachezugriffe optimieren).

An jedem dieser Pixel wird dann für jeden der 10 Werte die die 3-Vertexshader-Durchläufe ausgespuckt haben interpoliert (d.h. vereinfacht gesagt je näher man an einem Vertex desto "näher" kommt man dem an diesem Vertex vorhandenen Wert. Bei Farben ergibt sich z.B. einfach ein Farbverlauf).

Diese interpolierten Werte bekommt jetzt der Pixelshader reingestopft und rechnet sein Zeug damit durch (sampled z.B. Texturen an den Texturkoordinaten aus dem interpolierten Input) und spuckt ne Farbe aus.

Die Farbe wandert dann noch an die ROPs und wird entweder einfach in den Framebuffer geschrieben oder damit nochmal verrechnet (Blending).

Übrigens ist immer nur ein Vertex- und Pixelshader aktiv. Wenn man unterschiedliche Effekte hat muss man nochmal einen Draw-Call abfeuern. Wenn man also 1000 Polygone hat die 1000 unterschiedliche Texturen haben sollen muss man jedes einzeln zeichnen lassen und dazwischen die Texturen ändern bsw.

Odal
2006-05-08, 00:17:46
Coda[/POST]']Ok fangen wir von vorne auf. Die Verdatendaten (Position, Farbe, Texturkoordinaten) kommen in die Vertexshader werden dort für jeden Vertex verwurschtelt (perspektivische Projektion, etc.) und gibt bis zu 10 4D-Werte aus die nachher über das Dreieck interpoliert werden sollen (z.B. Farbe, Texturkoordinaten)

wieso bis zu 10 4D werte? Besteht ein Polygon dann aus bis zu 10 "vertexes" oder wie?


Danach wirds interessanter. Das Triangle-Setup nimmt jetzt 3 Eckpunkte und berechnet davon die nötigen Daten um das Dreieck zu zeichnen (Edge-Konstanten, Interpolationskonstanten).

Also praktisch die Triangulierung. Wo passiert das? In den Vertex Einheiten noch oder?


Dann kommt der Rasterizer nimmt die Daten und fängt an das Dreieck in jeder beliebigen Reihenfolge der Pixel abzuarbeiten (das ist übrigens bei nVIDIA sehr seltsam kreuz- und quer, weil sie da irgendwie die Cachezugriffe optimieren).


ROPs sind das aber nicht? Also bestimmt man sämtliche Punkte die in einem Dreieck liegen oder wie?


An jedem dieser Pixel wird dann für jeden der 10 Werte die die 3-Vertexshader-Durchläufe ausgespuckt haben interpoliert (d.h. vereinfacht gesagt je näher man an einem Vertex desto "näher" kommt man dem an diesem Vertex vorhandenen Wert. Bei Farben ergibt sich z.B. einfach ein Farbverlauf).

Wieso gerade 3 Durchläufe? Werden da nur Farbwerte interpoliert oder alle dieser 19 Werte (welche das auch immer alle sind ^^)


Diese interpolierten Werte bekommt jetzt der Pixelshader reingestopft und rechnet sein Zeug damit durch (sampled z.B. Texturen an den Texturkoordinaten aus dem interpolierten Input) und spuckt ne Farbe aus.


Also mischt der Pixelshader Farbwert des Vertex..Farbwert der Textur(en) an dieser Stelle durch Berechnung anhand des Shaderprogramms

Aber ansonsten ist doch der unterschied von SM2 und SM3 ungefähr was ich beschrieben hab?

Übrigens ist immer nur ein Vertex- und Pixelshader aktiv. Wenn man unterschiedliche Effekte hat muss man nochmal einen Draw-Call abfeuern. Wenn man also 1000 Polygone hat die 1000 unterschiedliche Texturen haben sollen muss man jedes einzeln zeichnen lassen und dazwischen die Texturen ändern bsw.

versteh ich nicht so ganz...soll heissen das man immer nur ein polygon und eine textur gleichzeitig in forn die pipeline füttern kann...


oder meinst du jetzt mit Vertex- Pixelshader shaderprogramm?

Coda
2006-05-08, 00:22:21
Odal[/POST]']wieso bis zu 10 4D werte? Besteht ein Polygon dann aus bis zu 10 "vertexes" oder wie?
Nein pro Vertex gibt es bis zu 10 Ausgabewerte. Das ist begrenzt weil für jeden Output ein Interpolator in Hardware vorhanden sein muss.

Edit: Ich muss vorsichtig sein, für D3D10 wird das Limit natürlich erhöht. Ich gehe jetzt gerade von D3D9 aus.

Odal[/POST]']Also praktisch die Triangulierung. Wo passiert das? In den Vertex Einheiten noch oder?
Danach.

Odal[/POST]']ROPs sind das aber nicht?
Nein. Die sind nach den Pixelshadern

Odal[/POST]']Also bestimmt man sämtliche Punkte die in einem Dreieck liegen oder wie?
Im Prinzip arbeitet man halt mit irgend nem Algorithmus alle Pixel ab die innerhalb des Dreiecks liegen - ja.

Odal[/POST]']Wieso gerade 3 Durchläufe? Werden da nur Farbwerte interpoliert oder alle dieser 19 Werte (welche das auch immer alle sind ^^)
Ein Dreieck hat 3 Eckpunkte. Es wird alles linear interpoliert was der Vertexshader so ausspuckt (was für einen Zweck es letztlich hat definiert ja eh erst das Pixelprogramm).

Odal[/POST]']Also mischt der Pixelshader Farbwert des Vertex..Farbwert der Textur(en) an dieser Stelle durch Berechnung anhand des Shaderprogramms
Nö, er kann die Texturen an beliebigen Stellen samplen. Wenn man aber die Texturkoordinaten in den Vertexshadern an die Interpolatoren weitergibt und mit dem interpolierten Wert im Pixelshader sampled bekommt man normales Texturmapping.

Odal[/POST]']versteh ich nicht so ganz...soll heissen das man immer nur ein polygon und eine textur gleichzeitig in forn die pipeline füttern kann...
Nein, aber nur gleichzeitig Polygone die die gleichen Konstanten, Texturen, Pixel- und Vertexprogramme haben.

Odal[/POST]']Aber ansonsten ist doch der unterschied von SM2 und SM3 ungefähr was ich beschrieben hab?
Naja so gaaanz grob.

Odal
2006-05-08, 01:00:28
Coda[/POST]']Nein pro Vertex gibt es bis zu 10 Ausgabewerte. Das ist begrenzt weil für jeden Output ein Interpolator in Hardware vorhanden sein muss.

kann man irgendwo nachlesen was die 10 möglichen werte sind? ICh kann mir nur xyz koordinaten farbwerte texturreferenz und referenz auf ein shaderprogramm vorstellen....vielleicht noch irgendwie eine ID zu welchem polygon der/das vertex gehört.


Nein. Die sind nach den Pixelshadern


so war mir auch ^^


Ein Dreieck hat 3 Eckpunkte.


Also berechnen die Vertexprozessoren z.b. einen Farbverlauf zwischen den 3 Vertex des aufgespannten dreiecks...... ähnlich bei opengl....wo ich z.b. den dreien vertexes welche ein Dreieck aufspannen unterschiedliche farbwerte verpasse und wenn der spass gerendert wird gibts einen interessanten farbverlauf ^^ (ich kann leider nur auf basis wissen von computergrafik von vor etlichen jahren zurückgreifen :D )



Nö, er kann die Texturen an beliebigen Stellen samplen. Wenn man aber die Texturkoordinaten in den Vertexshadern an die Interpolatoren weitergibt und mit dem interpolierten Wert im Pixelshader sampled bekommt man normales Texturmapping.

ok dann wird erstmal gesampled und interpoliert damit jedem vertex aus der textur ein farbwert zusammengemixt werden kann... 1 zu 1 geht ja nicht weil ja normalerweise nicht jedem texturpixel ein vertex zugeordnet ist...

ok dann hat nun jeder vertex einen texturfarbwert...bzw. bekommt noch eine andere textur drüber mit deren werten dieser dann noch (per ADD) verrechnet wird....und dann jagen wir den vertex mit allen bisher erhaltenen werten + dem shaderprogramm in die pixelprozessoren...


Nein, aber nur gleichzeitig Polygone die die gleichen Konstanten, Texturmappings, Pixel- und Vertexprogramme haben.

wie oft kommt denn das vor das eine fläche (polygon) die gleichen texturen und die gleichen shaderprogramme verpasst (referenziert) bekommt?
Ich stell mir das dann aber nicht sooooo häufig vor.

aber man kann diesbezüglich doch aber wenigstens bei 16 pipelines 16 durchjagen... bzw. eher weniger weil ja meist nur 6 oder 7 vertexshader vorhanden sind oder?

das man mit sm3 viel einfachere möglichkeiten hat seinen shader zu schreiben ist dann auch klar...nur gibts eben noch genug sm2(.x) karten für die eh lauffähige shaderprogramme erstellt werden müssen....
und sehr lange komplexe shader sind (nicht einzeln angewendet fürs testen sondern in der masse wie sie im spiel vorkommen) dann einfach für einen 350Mhz NV40 mit 16 pixelprozessoren zu langsam....so das diese anspruchsvollen shader eh durch einfache shader (aus dem sm2 Pfad) ersetzt werden müssen..nicht weil man mit SM3 nicht die SM2 shader kürzer oder schneller machen könnte, sondern weil die SM2 shader einfach weniger genaue oberflächenberechnungen anstellen dafür eben die GPU nicht so fordern und sie sind halt da (abwärtskompatiblität).

ist es nicht mehr oder weniger mit SM3 so? also das sich der Dev sagt wir müssen eh irgendwie einen SM2(.x) Pfad haben....da wird dann eben nicht so genau gerechnet (z.b. schatten auf dem wasser bei AOE3) also haben wir einmal shader die nicht so realistisch rechnen und recht einfach gehalten sind...und shader die sehr realistische berechnungen anstellen (für die gleiche fläche) und je nach shaderpfad wird geswitcht..

nun sagt sich der dev...bei den einfach gehaltenen shadern bringt noch eine SM3 (optimierte) version eh praktisch nix da die kurz sind und die mathematische funktion wenig komplex ist....
die aufwendigen effekte (z.b. AoE3 schatten werden auf dem wasser realistisch anhand der wellen verzerrt) sind aber ziemlich lang (Die Regel etwas bessere Optik -> exponentiell steigender Rechenaufwand) und da lohnt sich mit SM3 rausholen was......

nur versucht ein Dev immer Spitzen Grafik herauszuholen die HighEnd Grafikkarten voll ausnutzt....d.h. die shaderprogramme sind dann so aufwendig und berechnen dann so genau das sie highend GPUs tüchtig ins schwitzen bringen.....ist es dann nicht logisch das man mit langsamen (zwar SM3 fähigen) Karten auf die ungenaueren einfacheren Shader (optionen herunterstellen) ausweiche muss...und da eh nicht wirklich was mit den möglichkeiten von SM3 optimiert wird?

Coda
2006-05-08, 01:06:54
Odal[/POST]']kann man irgendwo nachlesen was die 10 möglichen werte sind? ICh kann mir nur xyz koordinaten farbwerte texturreferenz und referenz auf ein shaderprogramm vorstellen....vielleicht noch irgendwie eine ID zu welchem polygon der/das vertex gehört.
Das ist doch frei definierbar, das Zeug heute heißt nicht umsonst "programmierbare Grafikpipeline".

Odal[/POST]']Also berechnen die Vertexprozessoren z.b. einen Farbverlauf zwischen den 3 Vertex des aufgespannten dreiecks......
Nö. Ein Vertexshader berechnet nur für einen Vertex Inputs und Outputs. Das Interpolieren kommte danach im Rasterizer.

Odal[/POST]']ok dann wird erstmal gesampled und interpoliert damit jedem vertex aus der textur ein farbwert zusammengemixt werden kann... 1 zu 1 geht ja nicht weil ja normalerweise nicht jedem texturpixel ein vertex zugeordnet ist...

ok dann hat nun jeder vertex einen texturfarbwert...bzw. bekommt noch eine andere textur drüber mit deren werten dieser dann noch (per ADD) verrechnet wird....und dann jagen wir den vertex mit allen bisher erhaltenen werten + dem shaderprogramm in die pixelprozessoren...
Da is irgendwie vieles durcheinandergewurschtelt :|
Soll das ein Fallbeispiel darstellen?

Odal[/POST]']wie oft kommt denn das vor das eine fläche (polygon) die gleichen texturen und die gleichen shaderprogramme verpasst (referenziert) bekommt?
Ich stell mir das dann aber nicht sooooo häufig vor.
Tja, deshalb sollte man auch die Polygone einer Szene auch nach States sortieren.

So wenige Polygone pro Renderstate hat man nun auch nicht. Ein Mesh hat z.B. normalerweise für seine Polygone die gleichen Einstellungen.

Odal[/POST]']aber man kann diesbezüglich doch aber wenigstens bei 16 pipelines 16 durchjagen... bzw. eher weniger weil ja meist nur 6 oder 7 vertexshader vorhanden sind oder?
Nö, wie die Hardware aussieht interessiert ja die API nicht.

Odal
2006-05-08, 01:25:30
Coda[/POST]']Das ist doch frei definierbar, das Zeug heute heißt nicht umsonst "programmierbare Grafikpipeline".

NAja ich kann mir nur nicht vorstellen was man da so alles brauchen könnte ^^..und wo definiert man was man braucht? im Vertexshaderprogramm?


Nö. Ein Vertexshader berechnet nur für einen Vertex Inputs und Outputs. Das Interpolieren kommte danach im Rasterizer.

Ja stellt sich mir die Frage was er da genau berechnet....ok polygone irgendwie skalieren verformen/verzerren praktisch koordinaten jedes vertex transformieren usw. nur wozu braucht man da bis zu 10 outputwerte?


Da is irgendwie vieles durcheinandergewurschtelt :|
Soll das ein Fallbeispiel darstellen?


ja naja stellen wir uns vor wir haben da multitexturing....für eine fläche (ein sack voller vertexes) und noch ein shaderprogramm was jedem vertex zugewiesen ist.


Tja, deshalb sollte man auch die Polygone einer Szene auch nach States sortieren.


ergibt sinn...macht das die API (DX) oder der Treiber?



So wenige Polygone pro Renderstate hat man nun auch nicht. Ein Mesh hat z.B. normalerweise für seine Polygone die gleichen Einstellungen.

mhh ok ergibt auch sinn...z.b. ne kugel hat ja ja nach detaillierung schon einen ganzen sack voller polygone (dreiecke) welche alle eine meist eine einheitliche (z.b. metalltextur) textur haben..und z.b. ein shaderprogramm was eine spezielle oberflächeneigenschaft simmuliert


Nö, wie die Hardware aussieht interessiert ja die API nicht.

NAja das ist schon klar das man sich bei der API nicht drum kümmern braucht...aber der treiber wird doch dann die polygone puffern....und je nachdem 6 oder 7 gleichzeitig durch die Pipeline jagen...bzw. ein neues immer wenn eins fertig ist

Neomi
2006-05-08, 02:31:31
Odal[/POST]']kann man irgendwo nachlesen was die 10 möglichen werte sind?

Das ist ja das tolle, es ist nicht festgeschrieben. Die Werte können alles sein, was man haben will. Eigentlich hat Coda es ziemlich gut beschrieben, aber deine falsche Vorstellung scheint sich ein wenig festgebrannt zu haben. Vergiß besser erstmal das, was du über Shader zu wissen glaubst und schau dir die Beschreibung dann nochmal genau an. Oder diese hier (am Beispiel von D3D9 mit SM3)...

Ein Spiel setzt...
- Vertexbuffer (bis zu 16 Streams)
- Indexbuffer (1x)
- Vertex Declaration (1x)
- Vertexshader (1x)
- VertexShaderkonstanten (256x float4)
- Pixelshader (1x)
- Pixelshaderkonstanten (224x float4)
- Renderstates (exakt 1 Wert pro State)
- Texturen (16 Sampler vorhanden, eine Textur pro Sampler)
- Samplerstates (wie Renderstates, aber 1 Wert für jeden Sampler und State)
- Rendertarget (1x)
- Z-Buffer + Stencil (1x)

Es gibt noch mehr (z.B. Multiple Rendertargets), aber das würde erstmal nur für mehr Verwirrung sorgen, deshalb halte ich es mal "einfach". All diese Werte werden vom Programm gesetzt, die gesetzten Werte bleiben dann bis zur nächsten expliziten Änderung gleich. Man muß also nicht immer alles setzen, sondern nur, was sich verändert.

Das Programm macht einen Drawcall, also einen Zeichenaufruf. Ich behandle mal nur den indizierten Drawcall, es gibt auch andere Arten. Der Drawcall bekommt als Parameter die Art der Primitives (Punktliste, Dreiecksliste, ..., wir nehmen mal die Dreiecksliste), die Startposition im Indexbuffer und die Zahl der Primitives, z.B. 1000 Dreiecke. Das wären dann 3000 Indices (3 pro Dreieck), die ab der Startposition abgearbeitet werden. Jeder Index aus dem Indexbuffer sagt, an welcher Position im Vertexbuffer die angeforderten Daten liegen. Die Vertex Declaration sagt, was diese Daten bedeuten, z.B. Position an Offset 0 in Stream 0 als float3 (3x fp32, also 12 Bytes). Die Daten werden für jeden Eckpunkt zusammengesammelt und an den Vertexshader weitergegeben.

Jetzt läuft also der Vertexshader. Er läuft exakt einmal pro Vertex, dabei hat er keine Kenntnis von anderen Vertices. Die drei Vertices eines Dreiecks werden also völlig unabhängig voneinander berechnet, sie wissen nichtmal, zu welchem Dreieck sie gehören (ein Vertex kann auch von mehreren Dreiecken verwendet werden, also wäre so eine Zuordnung eh nicht möglich). Ein Vertexshader hat jetzt seine Inputdaten und Konstanten, daraus generiert er Outputdaten. Der einzige zwingend nötige Output ist die Position im Screenspace. Wie die generiert wird, bleibt dem Programmierer überlassen. Wo in den Konstanten die Matrizen zur Transformation vorliegen, ist dem Shader egal, er verrechnet nur Werte. Über die vorgeschriebene Position hinaus kann der Vertexshader noch weitere Daten ausgeben, bis zu 10x float4. Was die Werte bedeuten, ist dem Programmierer überlassen. Das können Texturkoordinaten sein, müssen sie aber nicht. Der Einfach heit halber nehmen wir mal an, daß in Slot 0 (Slot 0 als Output vom Vertexshader gelangt als interpolierter Slot 0 später als Input in den Pixelshader) zweidimensionale Texturkoordinaten unverändert weitergereicht werden, also so, wie sie schon im Vertexbuffer vorlagen und als Input zum Vertexshader kamen. Ich nenne das jetzt einfach mal Slot 0, weil ich nicht die Bindesemantik auch noch erklären will. Nachdem der Vertexshader seine Outputdaten generiert hat, ist er fertig.

Dann kommt das Triangle Setup. Es nimmt sich die Ergebnisse von 3 Vertexshaderdurchläufen, die für ein Dreieck benötigt werden. Die Position wird ausgewertet, das Dreieck geclipt (was außerhalb des Bildschirms wäre, kann nicht gezeichnet werden, wird also abgeschnitten) und möglicherweise gecullt. Wenn Culling eingeschaltet ist (ein Renderstate), dann werden die Dreiecke der Einstellung entsprechend verworfen, damit z.B. keine Rückseiten gezeichnet werden. Wenn das Dreieck fertig geclippt wurde und das Culling überstanden hat, geht es weiter an den Rasterizer.

Der Rasterizer durchläuft jetzt alle Pixel, die vom Dreieck (bzw. dem geclippten Rest des Dreiecks) überdeckt werden, die Position in Screenspace (der Zwangsoutput vom Vertexshader) ist hier die Referenz. Die anderen Outputs werden positionsabhängig interpoliert und als Input an den Pixelshader weitergereicht. Was die Zahlen da nun bedeuten, interessiert den Rasterizer nicht. Es sind nur Zahlen, und die interpoliert er.

Der Pixelshader wird für jeden Pixel einmal ausgeführt, dabei hat er keine Kenntnis von anderen Pixeln. Seine Inputdaten sind das, was der Vertexshader ausgespuckt und der Rasterizer interpoliert hat. Was diese Zahlen nun bedeuten, ist Sache des Pixelshaders, wurde also vom Programmierer festgelegt. Da wir von zweidimensionalen Texturkoordinaten in Slot 0 ausgegangen sind, können wir die jetzt nutzen, um eine Textur zu filtern. Der Pixelshader sagt der TMU, daß er doch bitte mal eine Textur sampeln soll.

Die TMU bekommt als Parameter einen Sampler (davon gibt es ja 16, wir nehmen mal Sampler 0) und einen float2, die Texturkoordinaten (für Cubemaps entsprechend float3). Der TMU ist dabei völlig egal, ob die Koordinaten schon im Vertexbuffer waren, im Vertexshader berechnet wurden oder im Pixelshader, es sind einfach nur Zahlen. Dem Sampler 0 ist exakt eine Textur zugeordnet, aus der wird gesampelt. Wie gesampelt wird, wird über die vor dem Drawcall festgelegten Samplerstates bestimmt. So wird z.B. über den Adressierungsmodus festgelegt, ob 1.2 als 1.0 (Clamping) oder 0.2 (Wrapping) weiterverwendet wird. Ob bilinear, trilinear, anisotrop oder per Pointsampling gefiltert wird, wird ebenfalls darüber bestimmt. Die fertigen Koordinaten (nach Wrapping oder anderer Einstellung) gehen von 0 bis 1, unabhängig von der Auflösung der Textur. Jedenfalls wird die TMU sich ein paar Samples aus der dem Sampler zugeordneten Textur holen und verrechnen (filtern), das gefilterte Ergebnis geht dann zurück an den Pixelshader.

Zurück im Pixelshader haben wir den Wert aus der Textur. Ob das nun eine Farbe ist, eine Normale, ein Faktor für Glanzlichter oder was ganz anderes, hängt nur davon ab, was der Pixelshader damit macht. Der Pixelshader hat natürlich auch noch seine Konstanten, in denen drinstehen kann, was auch immer der Programmierer dort drin haben will. Wenn z.B. die frei verwendbaren float4-Inputs u.a. als Position und Normalenvektor beinhalten und sich die Position einer Lichtquelle in den Konstanten befindet, kann man schonmal eine grundlegende Beleuchtung berechnen. Was auch immer der Pixelshader macht, er hat zwingend einen Output, und zwar einen 4-Komponenten-Farbwert (RGBA). Der Pixelshader kann auch einen Z-Wert ausgeben und damit den vom Rasterizer interpolierten überschreiben. Der Pixelshaderoutput geht dann an die ROPs.

Die ROPs (Raster Operation) sind nicht frei programmierbar, sondern werden über Renderstates gesteuert. Es gibt Renderstates für den Vergleich des Z-Wertes mit dem im Z-Buffer vorhandenen, für Stenciloperationen und -vergleiche, Alphablending, Alphatest, Fogging und noch ein paar Dinge mehr. Wenn der (optionale) Z-Test und evtl. Stenciltest bestanden wird, wird der Farbwert in das Rendertarget geschrieben oder mit dessen Inhalt an der jeweiligen Pixelposition verrechnet.

Nachdem all das für alle Dreiecke erledigt wurde, ist der nächste Drawcall an der Reihe. Dabei können neue Buffer, Texturen, Shader und States gesetzt sein, müssen aber nicht.

So, eigentlich wollte ich nicht so viel dazu schreiben. Dabei ist das schon recht stark vereinfacht, entspricht aber in etwa der Funktionsweise der Renderpipeline (bei D3D10 ändert sich da allerdings das ein oder andere Detail, es kommen neue Pipelinestufen hinzu, ...). Falls jemand irgendwelche Fehler findet, schiebe ich das einfach mal darauf, daß es schon spät ist. Obwohl... für Programmierer gibt es nur ein "zu früh", aber kein "zu spät". :D

Neomi
2006-05-08, 02:48:00
Odal[/POST]']Ja stellt sich mir die Frage was er da genau berechnet....ok polygone irgendwie skalieren verformen/verzerren praktisch koordinaten jedes vertex transformieren usw. nur wozu braucht man da bis zu 10 outputwerte?

Wozu man die braucht? Um Effekte berechnen zu können, die diese Parameter brauchen. 10 sind noch viel zu wenig. Mal ein Beispiel, wie man die belegen könnte:

1x Normalenvektor (für Beleuchtung)
2x Texturkoordinaten (für 2 Farbtexturen und 2 Normalmaps)
2x Tangenten (für Normalmapping, Teil des Tangentspace)
2x Bitangenten (orthogonal zu den ersten Tangenten)
1x Eyevektor (für Reflektionen)
1x Position oder weitere Texturkoordinate (z.B. für Lookup in einer Shadowmap)
1x Farbe (zum Modulieren der Objektfarbe)

Aus dem Normalenvektor und dem Eyevektor kann man den Reflektionsvektor und den Refraktionsvektor erzeugen. Die Bitangenten (werden oft Binormalen genannt, sind aber Tangenten) kann man auch aus der Normalen und der Tangente im Pixelshader per Kreuzprodukt erzeugen. Muß man sogar, wenn man die wenigen Interpolatoren für andere Dinge benötigt. Bei D3D10 wird es 16 geben (bzw. 32, wenn man einen Geometryshader nutzt), und auch das ist noch weit von "zu viel" entfernt.

Coda
2006-05-08, 16:01:04
Odal[/POST]']NAja ich kann mir nur nicht vorstellen was man da so alles brauchen könnte ^^..und wo definiert man was man braucht? im Vertexshaderprogramm?
Hat Neomi ja schon beantwortet. Was meinst du mit "was man braucht"? Man hat eben 10 Outputs in den Vertexshadern und dementsprechend 10 Inputs in den Pixelshadern. Kannst damit machen was du willst.

Odal[/POST]']ja naja stellen wir uns vor wir haben da multitexturing....für eine fläche (ein sack voller vertexes) und noch ein shaderprogramm was jedem vertex zugewiesen ist.
Äh, es gibt nur ein Vertexprogramm pro Drawcall.

Odal[/POST]']ergibt sinn...macht das die API (DX) oder der Treiber?
Der Programmierer.

Odal[/POST]']NAja das ist schon klar das man sich bei der API nicht drum kümmern braucht...aber der treiber wird doch dann die polygone puffern....und je nachdem 6 oder 7 gleichzeitig durch die Pipeline jagen...bzw. ein neues immer wenn eins fertig ist
Nö, sowas gibts nicht. Das würde aus vielen Gründen nicht funktionieren.

Gast
2006-05-09, 04:48:02
Könnte der "Shader in simpler Sprache erklärt"-Part wohl in einen eigenen Thread rausgesplittet werden? Der ist nämlich zu interessant, um in diesem hier schnell in Vergessenheit zu geraten.
Getan, ggf. in den Ursprungsthread reinschauen, wenn das eine oder andere Posting fehlt.