High level shading language

nuts

Hey,

kennt sich hier jemand mit HLSL (high level shading language ) aus?
Damit kann man Pixelshader der GPU programmieren (ähnlich wie assembler für die CPU) um verschiedene Effekte (Processing) für die Bild / Videobearbeitung zu erreichen.
Im Vergleich zu den CPU gestützen Methoden (ffdshow, avisynth) ist das aber wesentlich effizienter!
Die Möglichkeiten sind riesig, nur leider ist die Sprache imho sehr schwierig zu verstehen

Einsetzen kann man die Shader dann über entsprechende Videoplayer wie z.B. http://mpc-hc.sourceforge.net/
Dort gibt es auch gleich einen entsprechenden Editor.
Verwenden kann man diese Grundbefehle: http://msdn.microsoft.com/en-us/library/…6(v=VS.85).aspx

Mal ein Beispiel:

Code

sampler s0 : register(s0);
float4 p0 : register(c0);


#define width (p0[0])
#define height (p0[1])
#define clock (p0[3])


float4 main(float2 tex : TEXCOORD0) : COLOR
{
	float4 c0 = 0;

	tex.x += sin(tex.x+clock/0.3)/20;
	tex.y += sin(tex.x+clock/0.3)/20;

	if(tex.x >= 0 && tex.x <= 1 && tex.y >= 0 && tex.y <= 1)
	{
		c0 = tex2D(s0, tex);
	}

	return c0;
}

Alles anzeigen

Vielleicht kann jemand diese einfachen Zeilen mal auskommentieren?
Oder kennt jemand ein verständliches Tutorial für Anfänger?

Gruß nuts

**Andy**

Hi, ich hatte mich auch schon mit diesem Thema auseinandergesetzt, allerdings wurde mir das aufgrund fehlender "ernsthafter" Problemstellung zu aufwendig!
"Just for fun", da stehen bei mir andere Sachen vorne auf der Prioritätenliste!

Zunächst unterscheidet man Vertex- und Pixelshader. Um mit Vertexshadern zu arbeiten braucht man zunächst ein 3D(Gitter) Modell. Vertexshader werden eingesetzt um diese Gitter-Modelle zu bewegen wie z.B.drehen, verformen, Wellen im Wasser zu generieren o.a. Ein/mehrere 3D-Modeller und das dementsprechende Know-How sind also Pflicht. Transformationen von BewegungsPfaden/Vektorrechnung sollte man beherrschen!

Die Pixelshader sind dafür da, die Gittermodelle mit Texturen zu versehen und diese mit Filtern (Beleuchtung, Nebel, Spiegelungen) zu bearbeiten. Filterfunktionen, Transformationen usw sind hier Vorraussetzung!
Der große Vorteil der Shader ist, dass die Graka selbstständig je nach aktueller Auslastung diese Berechnungen beliebig parallelisieren kann!

Was bei der Programmierung von Shadern vorausgesetzt werden muss ist HÖHERE Mathematik. Wer meint, bissl Sinus und Cosinus reicht, kommt nicht weit! Ob es sinnvoll ist, sich ein 3/4 Jahr den Ar*** aufzureissen, damit sich einige "schwebende Würfel" über einer spiegelnden Ebene drehen können, lasse ich mal dahingestellt! Aber im Endeffekt sieht es genau so aus.....

Eine meiner Lieblingsseiten zu diesem Thema ist übrigens schon seit langem http://www.iquilezles.org/www/

Hard stuff is our daily Job! In diesem Sinne. HAUT REIN! Und lasst euch nicht entmutigen...

nuts

Das macht ja Mut.

Der praktische Einsatz ist für mich das Bearbeiten von Mediaquellen in Echtzeit.
Dafür ist der Shadereinsatz nahezu ideal, da die Mediawiedergabe zeitkritisch ist.

Für viele Processingfilter (Schärfe, Denoise, Chromaupsamling uvm.) gibt es schon eine mathematische Basis (mpc-hc basis shader, ffdshow ist z.B. auch open source), aber erstmal muss man mit einfachen Beispielen anfangen um zu verstehen was dabei genau passiert.
Als HTPC-Freak interessierts mich aber total, da die Shader ein riesen Potential haben.
Dieser hier wandelt z.B. side by side Material um 3D auch ohne 3D Fernseher schauen zu können:

Code

float4 p0 : register(c0);   -> um width & height zu bekommen


#define width (p0[0])   ->wird in dem Fall von der Playersoftware übergeben 
#define height (p0[1]) ->wird in dem Fall von der Playersoftware übergeben


float4 main(float2 tex : TEXCOORD0) : COLOR   #-> Die Funktion "main"
{	
   tex.x = tex.x / 2;


   float4 l = tex2D(s0, tex);    #  -> float4 ist ein Datentyp ähnlich dem Array und beinhaltet 4 Fliesskommazahlen 


   tex.x = tex.x + 0.5;  # -> etwas Mathe, leider gibts kein consolewrite :( 
 
   float4 r = tex2D(s0, tex); 


   float red = l.g * 0.7 + l.b * 0.3;   # ->  l.g ???     l.b  ???? 
   float green = r.g;
   float blue = r.b; 

   return float4(red, green, blue, 1)  # Rückgabe wie bei return in autoit

Alles anzeigen

Sieht einfach aus, nur was passiert da genau?

edit\ en bissle versteh ichs schon

**Andy**

http://msdn.microsoft.com/en-us/library/bb509677(VS.85).aspx
beschreibt die tex2D()-Funktion (mehr schlecht als recht)
Wenn ich das richtig verstanden habe (bin kein C-fuzzi), dann werden die x-Koordinaten der Vektoren(Pixel) mit tex bezeichnet
In dem Fall ist mit r das rechte Pixel und l das linke Pixel (tex.x/2) gemeint (side by side)
Die resultierenden Farbanteile werden aus diesen beiden Pixeln berechnet:
red = links.gruen * 0.7 + links.blau * 0.3
green = rechts.gruen
blue = rechts.blue

so seh ich das^^ aus 2 Bildern wird eins gemacht, pixel für pixel

/EDIT/
tex2D ignoriert den z-Anteil (Buffer)
s0 ist ein sog. Sampler, der sowohl eine Textur, als auch eine Mischung aus diversen Filtern sein kann. Der Sampler wird dann auf das Pixel angewendet.

Marthog

Also wandelt der Shader die Pixel für Rot-Blau-3d-Brillen um.

1. Kommentare werden wie in C++ mit // bzw. /* ... */ markiert
2. #define scheint genauso zu funktionieren, wie in C. Allerdings werden diese beiden nicht gebraucht.
3. s0 wurde nicht definiert.

**Andy**

war zu langsam mit dem Edit im vorigen Post^^
lt MSDN können die Sampler wohl auch während der Laufzeit bestimmt werden und sind, falls nicht "definiert", einfach "leer", d.h. ohne Filter/Textur

nuts

Aha danke.
So langsam kommen wir der Sache doch näher.