Texturen

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.

Texturen

Beitragvon RedGuy » 29.12.2016, 12:06

Hallo !

Im Rahmen meines Projektes http://zfx.info/viewtopic.php?f=10&t=4123 eigener Computer bin ich gerade dabei
den Grafikchip zu designen :geek: !!!

Grundsätzlich bin ich dabei, mich bei den Polygonen für Dreiecke zu entscheiden.

Bei der Entwicklung des Protokolles für die Kommunikation zwischen Hauptprozessor > Betriebsystem und dem Grafikchip (GENIAL ODER ;) ?!?!) ist mir eine
grundsätzliche Frage bezüglich der Texturierung gekommen.

Diese ist für euch Profis garantiert sehr trivial:

Also, wann kommen bei heutigen 3d-Systemen (also ich meine den Gesamtkonstrukt 3d-engine - DirectX/OpenGL - Graka) die Texturen auf die Polygone ?
Ich stelle mir das so vor, dass die Polygone (Vertice) projeziert werden, und dann die Textur an die projezierte Bildschirmkoordinaten gemapt wird.

Wird das so in etwa gemacht ?


Wenn ja:
Kennt jemand die mapping Funktion für die Koordinaten Rohtextur auf das projezierte Polygon (Dreieck, Bildschrimkoordinaten) ?
Ich weiß, dass man da wieder mit baryzentrischen oder trilinearen Koordinaten arbeiten könnte- aber vielleicht weiß jemand ja schon was Genaueres...
Ich weiß auch, dass bei dem Thema ggf. noch die Rasterung eine Rolle spielt und das Ganze daher noch etwas komplizierter wird.

Ich suche allerdings wie gesagt nur eine einfache Formel: ganz linear und trivial von Rohtextur nach s.x/s.y der Textur.

Die Frage ist im Moment auch noch Folgende: Wie weiße ich eine Rohtextur einem Dreieck zu (wobei doch eine solche Rohtextur auch noch quadratisch ist)...
Ich würde für mich einfach die Vertice des Dreiecks auf die Rohtextur "legen" ;) .

Gruss
RedGuy
RedGuy
Manuel Hofmann
Establishment
 
Beiträge: 111
Registriert: 17.09.2002, 17:27
Wohnort: Rottweil

Re: Texturen

Beitragvon antisteo » 29.12.2016, 16:03

Ein Tipp: Baue keine Fixed Function Pipeline mehr.

Eine leistungsfähige Architektur, die auch AMD und NVIDIA in ihren aktuellen GPUs verbauen und extrem leicht zu bauen ist, stelle ich dir hier vor:
- Betrachte deine GPU als einen riesigen Multicore-Prozessor mit hunderten und tausenden von Kernen (wenn du FPGAs bestückst, dürfte die Grenze bei 4-12 liegen)
- RISC-Architektur aufs minimalste - Hauptsache die Arithmetik ist dabei (Floating Point, sin, cos, sqrt)
- Jeder Kern hat einen eigenen kleinen Speicher (1K dürfte reichen) für seine aktuelle Aufgabe, der gleichzeitig als Cache dient
- Ein gemeinsamer Hauptspeicher, der den Videobuffer, die Texturen, VBOs usw. enthält
- Die Kerne dürfen nur auf ihren 1K großen Speicher zugreifen. Wollen sie vom Hauptspeicher lesen, müssen sie relativ große Blöcke zum Lesen anfordern (z.B. 256 byte groß)
- Es gibt noch einen Management-Kern, der Zugriff auf den Hauptspeicher hat. Dieser liest die ankommenden Aufgaben-Pakete, die ihm die CPU zuschickt und verteilt Aufgaben auf die einzelnen RISCs bzw. sammelt Ergebnisse ein
- Baue Hardware-Support für Ringpuffer ein. Das ist die schnellste Form, Aufgaben an viele kleine Rechenkerne zu verteilen bzw, wieder einzusammeln

So weit zur Hardware. Jetzt die Software (der Treiber):
Will jetzt jemand mit dem Grafikchip zeichnen, brauchst du eine Firmware für den Management-Kern. Du schickst dem Grafikchip kodiert Nachrichten a la:
- Zeichne eine rote Box an (4,5) mit der Größe (300,200)
- Drucke Text "asdf" mit dem Font-Set "Arial" an (4,5) mit der Schriftgröße 12
- Zeichne das Frame 1234 des H.264-Videos an Speicheradresse XYZ in die Textur an Adresse YZX

Die Firmware im Management-Kern zerteilt die Aufgabe anschließend in kleine Mini-Aufgaben (bestehend aus einem Mini-Programm und ein paar Parametern) und schiebt sie in den Ringpuffer. Die einzelnen Kerne nehmen sich jeder eine Aufgabe und schicken die berechneten Ergebnisse auf einem anderen Ringpuffer zurück. Du könntest beim H.264-Dekodieren zum Beispiel jedem Kern einen 8x8-Bereich auf dem Bildschirm auszurechnen. Sie schicken dir dann 192 Bytes auf dem Ringpuffer zurück, die du in den Videospeicher schreiben kannst (und evtl. Z-Informationen auswerten)
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
antisteo
Establishment
 
Beiträge: 789
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Texturen

Beitragvon Krishty » 29.12.2016, 16:32

Die Texturen kommen auf den Bildschirm, indem das Programm, das die GPU ausführt (der Shader) sagt, dass nun eine Textur mit Koordinaten UV gesamplet werden soll.

Der Treiber zerlegt diesen Befehl in kleinere Befehle:
1. die UV-Koordinaten wurden im Programm einem Register zugewiesen
2. in drei Instanzen dieses Registers haben die drei transformierten Vertices ihre UV-Koordinaten geschrieben (durch den Vertex oder Geometry Shader)
3. der Treiber hat Code erzeugt, damit beim Start des Pixel Shaders aus diesen drei UV-Registern ein Wert für den Pixel interpoliert wird (perspektivisch korrekt! Für beliebig viele Dimensionen, nicht bloß auf 2D beschränkt!)
4. die Texturausmaße, die Anzahl der Mip Levels, und deren Basisadressen liegen in bestimmten Registern, sobald die Textur gebunden ist
5. Pixel werden immer in Gruppen von 2x2 verarbeitet
6. aus den unterschiedlichen Werten der Register, denen UV zugewiesen ist, lässt sich ein Gradient berechnen
7. der Treiber hat Code erzeugt, der den Gradienten aus 6. mit Hilfe von 4. zu einem Mip Level umrechnet
8. der Treiber hat Code erzeugt, der das Mip Level aus 7. mit Hilfe von 4. zu einer Speicheradresse umrechnet9. der Treiber hat Code erzeugt, der diese Speicheradresse und die der vier umliegenden Texel lädt
10. der Treiber hat Code erzeugt, der diese vier Werte aus dem Eingangsformat (z.B. 8-Bit sRGB) in vier floats konvertiert
11. der Treiber hat Code erzeugt, der diese vier Werte interpoliert und das Ergebnis in das Register schreibt, das der Variable zugewiesen wurde, in der der Shader seine Textur erwartet

Früher war fast alles hard-wired, aber heute ist das fast komplett ALU. Außer sRGB-zu-linear-Konvertierung, könnte ich mir denken.

Blending ist heute ebenfalls ALU.

Und mit weniger wirst du nichts reißen können. Fixed Function Pipeline wünscht sich niemand zurück.

RedGuy hat geschrieben:Kennt jemand die mapping Funktion für die Koordinaten Rohtextur auf das projezierte Polygon (Dreieck, Bildschrimkoordinaten) ?
StackOverflow hat Code (perspektivisch nicht korrekt): http://stackoverflow.com/questions/8697 ... a-triangle
Wikipedia hat die perspektivische Korrektur: https://en.wikipedia.org/wiki/Texture_m ... orrectness
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6679
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Texturen

Beitragvon dot » 29.12.2016, 16:51

Für Hardware evtl. eher interessant: http://www.cs.unc.edu/~olano/papers/2dh-tri/2dh-tri.pdf

Krishty hat geschrieben:Früher war fast alles hard-wired, aber heute ist das fast komplett ALU. Außer sRGB-zu-linear-Konvertierung, könnte ich mir denken.

Dachte ich auch immer dass heute fast alles ALU sein wird. Turns out: it's not. Dinge wie Interpolation und stinknormaler Texturelookup inkl. Gradient sind heute genauso noch praktisch komplett hardwired wie damals. Ist auch ganz einfach erklärt: Im Vergleich zu einem programmierbaren Core kostet solcher Kram praktisch nix, das kann man einfach so wie ein bisschen Zucker drüberstreuen. Du kannst davon ausgehen, dass selbst auf einem aktuellen Pascal Chip praktisch jeder Aspekt von OpenGL nativ in Hardware umgesetzt ist... ;)

Krishty hat geschrieben:Blending ist heute ebenfalls ALU.

Nope; hardwired; machen die ROPs... ;)
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: Texturen

Beitragvon Krishty » 29.12.2016, 18:36

Stimmt; Texture Fetching geht meistens nicht durch ALU (Compute Shader-Kram außen vor). Ab Seite 5/7 steht aber so einiges über die Verschiebung. http://www.humus.name/Articles/Persson_ ... zation.pdf
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6679
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Texturen

Beitragvon dot » 29.12.2016, 18:50

Krishty hat geschrieben:Stimmt; Texture Fetching geht meistens nicht durch ALU (Compute Shader-Kram außen vor). Ab Seite 5/7 steht aber so einiges über die Verschiebung. http://www.humus.name/Articles/Persson_ ... zation.pdf

Naja, projective Texturemapping wird natürlich nicht mehr in hardware supported, aber Dinge wie Format Conversion und Address Modes und Gradients selbstverständlich immer noch. Die Attribute Interpolation wird nur insofern vom Shader gemacht als dass es eine hardware Instruction dafür gibt, die der Shader aufruf. Zumindest die baryzentrischen Koordinaten bekommt der Shader aber ziemlich sicher vom Rasterizer, der damit die eigentliche Arbeit macht...
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: Texturen

Beitragvon Krishty » 30.12.2016, 13:30

dot hat geschrieben:Naja, projective Texturemapping wird natürlich nicht mehr in hardware supported, aber Dinge wie Format Conversion und Address Modes und Gradients selbstverständlich immer noch.
Ganz sicher?
ALU.png
Zu Address Modes habe ich auch nichts gefunden, aber seit es Tiled Resources gibt und man das Paging-Ergebnis im Shader abfragen kann, kann ich mir gut vorstellen, dass man das lieber den Rechenkern machen lässt anstatt eigene Transistoren.
dot hat geschrieben:Die Attribute Interpolation wird nur insofern vom Shader gemacht als dass es eine hardware Instruction dafür gibt, die der Shader aufruf. Zumindest die baryzentrischen Koordinaten bekommt der Shader aber ziemlich sicher vom Rasterizer, der damit die eigentliche Arbeit macht...
Diese Anweisungsfolge sieht mir aber nicht danach aus:
interpolation.png
(Die Formatkonvertierung am Ende kann man auch gut erkennen.) Und die Folien sagen ja
Interpolators became ALU instructions with DX11 hardware.
Das ist natürlich nur ein spezifischer Talk, der sich vor allem auf einen spezifischen AMD-Chip bezieht, aber … Quellen wären schon was Gutes ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6679
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Texturen

Beitragvon dot » 30.12.2016, 13:36

Krishty hat geschrieben:Quellen wären schon was Gutes ;)

Nun, ich kann nur von NVIDIA Hardware sprechen und meine Quellen sind leider nichts, was ich einfach hier verlinken könnte. Ich belass es einfach mal dabei dass ich mir, was NVIDIA betrifft, ziemlich sicher bin... ;)
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: Texturen

Beitragvon Krishty » 30.12.2016, 13:47

Schade! Wenn’s mal einen offiziellen Vortrag zu sowas gibt, verlink ihn ruhig – sowas interessiert mich immer :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6679
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Texturen

Beitragvon dot » 30.12.2016, 13:50

Krishty hat geschrieben:Schade! Wenn’s mal einen offiziellen Vortrag zu sowas gibt, verlink ihn ruhig – sowas interessiert mich immer :)

Leider nicht (wenn ich da was kennen würde, hätt ich das längst schon mal im Artikel Thread verlinked, das hier kennst du vermutlich schon ;)). Aber was die Attribute Interpolation angeht muss ich mich wohl korrigieren, vermutlich kommt die nötige Info (Attribute Plane Equations) da auch bei NVIDIA aus dem Triangle Setup und wird im Shader dann verwendet um die interpolierten Werte zu bestimmen. Wundert mich gerade doch etwas, erscheint mir auf den ersten Blick nach ziemlicher Verschwendung von Speicherbandbreite; in unserer Software Pipeline machen wir das jedenfalls anders... xD
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: Texturen

Beitragvon Krishty » 30.12.2016, 13:57

In meinen Shadern auf AMD-Karten war Interpolation sehr oft der Flaschenhals, deshalb kann ich das ebenfalls schlecht verstehen. Ich sage mir dann einfach immer, dass Call of Dutys Über-Shader bestimmt so riesig sind, dass es dort einfach nicht von Bedeutung ist.

dot hat geschrieben:das hier kennst du vermutlich schon ;)
Nein, aber das ist fett; danke!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6679
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Texturen

Beitragvon NytroX » 30.12.2016, 17:41

Hammer, danke, den kannte ich auch noch nicht.
Da gibt es auch einen weiterführenden Link auf der Seite, der auch hier zum Thema sehr hilfreich ist (damit er in der Informationsflut nicht untergeht):
https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index
NytroX
Establishment
 
Beiträge: 151
Registriert: 03.10.2003, 12:47

Re: Texturen

Beitragvon RedGuy » 08.01.2017, 19:30

Hi !!

Um nochmals zu meiner Frage zurückzukommen, wie man aus den Texturkoordinaten die Bildschirmkoordinaten bekommt:

Also baryzentrische und trilineare Koordinaten haben beide nicht funktioniert :( .
Hab alles ausprobiert- hab aber immer einen falschen Punkt bekommen...

JETZT ERLEDIGE ICH DAS WIE FOLGT:

1. Das zu texturierende Rechteck (später auch Dreieck) wird auf die Rohtextur gelegt (->Texturkoordinaten).
2. Es werden horizontale Strecken von der linken Rechteckskante zur rechten Rechteckskante berechnet.
Und zwar so, dass diese Linien alle Texturpixel abbekommen.
3. Den Linien werden entlanggefahren und alle Texturpixel werden in entsprechenden arrays pro Linie gespeichert.

4. Die Bildschirmkoordinaten des Rechtecks (=Zielrechteck) werden berechnet (projeziert).
5. Die horizontalen Linien werden auf das Zielrechteck skaliert (dies geschieht über einfache Geradengleichungen bzw. Vektorrechnung).
6. Die in den Linienarrays gespeicherten Texturpixel werden auf die Ziellinien skaliert und ggf. bei gleichen screen coords gemischt.


Das Ganze ist gewöhnliche Vektorrechnung der einfachen Art (kann man sich auf jeden Fall alles selbst herleiten) bzw. mit einfachen Geradengleichungen (Normalform) erledigbar :) ;) !!!
Bin dabei das in JAVA testweiße zu implementieren.


Gruss
Red
RedGuy
Manuel Hofmann
Establishment
 
Beiträge: 111
Registriert: 17.09.2002, 17:27
Wohnort: Rottweil


Zurück zu Grafikprogrammierung

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste

cron