Shader verketten

[erwin]

Wie ist eigentlich der momentane Stand? Ist da was in Entwicklung? Kann man das Verketten auf Quelltextebene als gelöst betrachten? Meine letzen Infos diesbezüglich sind

 

http://www.DVBViewer.tv/forum/topic/37690-video-postprocessing-und-shader/page__view__findpost__p__323203

 

und

 

Shader auf diese Weise zu vereinen führt meist nicht zum gewünschten Ergebnis. Ein Shader wird pro Pixel aufgerufen. Verwendet ein Shader aber Nachbarpixel zur Berechnung des aktuellen Pixels ist das Ergebnis anders, je nachdem wie die Funktionen gestackt werden. Packt man 2 Funktionen in einen Shader, verwendet die 2. Funktion noch unbearbeitete Nachbarpixel. Packt man die 2 Funktionen in 2 unterschiedliche Shader, wird das komplette Bild erst von Shader 1, anschließend von Shader 2 bearbeitet. Shader 2 verwendet also nur noch Pixel, die bereits von Shader 1 bearbeitet wurden.

Verwenden beide Funktionen keine Nachbarpixel ist das natürlich kein Problem.

 

Ich hab mir ein par Gedanken dazu gemacht und würde falls gewüscht diese dann zum Besten geben

[erwin]

Also, ich lass mal was ab. Nur ein par Gedanken und Ideen.

 

Wie verkettet man Shader auf Quelltextniveau?

 

1. Gedanke: Hintereinanderschreiben -> Wird nichts!

 

2. Gedanke: Jeder Shader als eingene Funktion und dann

 

return Shader1( Shader2() );

 

Wird auch nichts! Hintergrund ist das, was im CiNcH-Zitat zu finden ist.

 

Die Verkettungsspunkte sind die calls tex2D(). Alle Aufrufe auf tex2D sind durch den Aufruf des verkoppelten Shaders zu ersetzen. Siehe hier ein Qick-and Dirty Beispiel:

 

http://www.DVBViewer.tv/forum/topic/46321-3d-broadcast-format/page__view__findpost__p__341124

 

und die Verkettung mit dem Anaglyph-Shader:

 

http://www.DVBViewer.tv/forum/topic/44350-real-3d-tv-broadcast/page__view__findpost__p__341299

 

Der geübte Programmierer kann dies aber besser. Ich möchte dies an der Verkettung von Grayscale- und Water-Shader zeigen.

 

Die Shader schreibt man besser in einer anderen Form:

 

<?xml version="1.0" encoding="iso-8859-1"?>
  <Shader>
    <Profile>ps_2_0</Profile>
    <Description>Grayscale Effect</Description>
    <Code>sampler s0 : register(s0);
float4 p0 : register(c0);
float4 p1 : register(c1);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
	float c0 = dot(tex2D(s0, tex), float4(0.299, 0.587, 0.114, 0));

	return c0;
}

</Code>
  </Shader>

[/codeBOX]

 

wird zu

 

[codeBOX]
<?xml version="1.0" encoding="iso-8859-1"?>
<Shader>
<Profile>ps_2_0</Profile>
<Description>water</Description>
<Code>sampler s0 : register(s0);
float4 p0 : register(c0);

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

inline float4 myGrayscale_tex2D( sampler s, float2 tex : TEXCOORD0 ) : COLOR
{
return tex2D( s, tex );
}

inline float4 myGrayscale( sampler s, float2 tex : TEXCOORD0 ) : COLOR
{
float c0 = dot(myGrayscale_tex2D(s0, tex), float4(0.299, 0.587, 0.114, 0));

return c0;
}

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return myGrayscale( s0, tex );
}
</Code>
</Shader>

[/codeBOX]

 

Also 3 Teile: die main-Funktion die den eingentlichen Shader aufruft. Dieser ist in einer eigenen Funktion

verpackt. In dieser Funktion kommen keine [i]direkten[/i] Aufrufe von tex2D mehr vor. Stattdessen sind diese

tex2D-Aufrufe in einer eigenen Funktion myGrayscale_tex2D gekappselt. Vorteil: im obigen SisvelAnanmorph Beispiel müsste ich jetzt nur noch an einer zentralen Stelle ändern.

 

Weiter gehts. Die ersten beiden Funktionen

 

[codeBOX]
inline float4 myGrayscale_tex2D( sampler s, float2 tex : TEXCOORD0 ) : COLOR
{
return tex2D( s, tex );
}

inline float4 myGrayscale( sampler s, float2 tex : TEXCOORD0 ) : COLOR
{
float c0 = dot(tex2D(s0, tex), float4(0.299, 0.587, 0.114, 0));

return c0;
}
[/codeBOX]

packen wir in eine eigene Datei: [i]myGrayscale.psh[/i]. Alle Vorkommen von "<" oder ">" XML Encodings (lt und gt) werden entsprechend durch "<" oder ">" ersetzt. [i]Grayscale.xml[/i] wird damit zu

 

[codeBOX]
<?xml version="1.0" encoding="iso-8859-1"?>
<Shader>
<Profile>ps_2_0</Profile>
<Description>Grayscale Effect</Description>
<Code>
sampler s0 : register(s0);
float4 p0 : register(c0);
float4 p1 : register(c1);

#include ".\Shaders\myGrayscale.psh"

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return myGrayscale( s0, tex );
}
</Code>
</Shader>

[/codeBOX]

 

Obwohl semantisch völlig äquivalent, können wir diesen Shader ([i]myGrayscale.psh[/i]) nun auch in Drittsoftware (z.B. MPC-HC) ohne Änderung verwenden denn es enthält keine (DVBV-spezifischen) XML-Erweiterungen mehr.

 

Angenommen auch Water.xml wäre entsprechend aufbereitet worden. Wie sähe eine Verkettung jetzt aus.

 

Wie nehmen die "myWater.xml"

 

[codeBOX]
<?xml version="1.0" encoding="iso-8859-1"?>
<Shader>
<Profile>ps_2_0</Profile>
<Description>water</Description>
<Code>sampler s0 : register(s0);
float4 p0 : register(c0);

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

#include ".\Shaders\myWater.psh"

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return myWater( s0, tex );
}</Code>
</Shader>
[/codeBOX]

 

Und erstellen eine Kopie mit Namen [i]myGrayscaleWater.xml[/i] z.B., indem wir nur die #Include-Direktive modifizieren

[codeBOX]
<?xml version="1.0" encoding="iso-8859-1"?>
<Shader>
<Profile>ps_2_0</Profile>
<Description>water</Description>
<Code>sampler s0 : register(s0);
float4 p0 : register(c0);

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

#include ".\Shaders\myGrayscaleWater.psh"

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return myWater( s0, tex );
}</Code>
</Shader>
[/codeBOX]

Das ist so generisch, das dies völlig automatisch ein Script übernehmen kann. Diese Verkettungs-[i]myGrayscaleWater.psh[/i] muss als nächstes erstellt werden

 

[codeBOX]
#include ".\Shaders\myGrayscale.psh"

#define tex2D myGrayscale

#include ".\Shaders\myWater.psh"
[/codeBOX]

auch völlig generisch und mit einem Script machbar.

 

Et voilá unsere Verkettung.

 

myGrayscaleWater.zip

 

PS: Der Shader-Editor verhält sich bezüglich der Include-Direktive etwas anders als der DVBV, d.h er meldet Fehler wo der DVBV tadellos läuft. Dies liegt im zugrundeliegenden Ausgangsverzeichnis. Am Besten man legt die Testtextur im DVBV-Verzeichnis ab und lädt es von dort.

Edited July 19, 2011 by erwin

[erwin]

Kann mir jemand sagen welche Shader Register der DVBV mit welcher Bedeutung beim Shader-Aufruf setzt?

 

Danke!

[CiNcH]

Zumal der DVBViewer die MPC-HC Shader verwendet dürften es dieselben wie da sein. Ich kann zuhause mal nachsehen. Ich muss auch bei Gelegenheit mal schauen, warum Shader, welche als ps_3_0 kompiliert werden, nicht funktionieren.

 

Momentan bin ich aber noch mit Themen wie bessere Analyse-Möglichkeiten und Timing/Synchronisation für den Custom Presenter beschäftigt.

[erwin]

Ich muss auch bei Gelegenheit mal schauen, warum Shader, welche als ps_3_0 kompiliert werden, nicht funktionieren.

Schätze die brauchen

1. eine bestimmte d3dx9_**.dll

2. DVBV muss diese auch laden

[dbraner]

Ist das Erstellen von Shadern eigentlich irgendwo dokumentiert oder gibt es ein Tutorial?

[CiNcH]

Schätze die brauchen

1. eine bestimmte d3dx9_**.dll

2. DVBV muss diese auch laden

Das wird auch mein erster Ansatz sein... neuere DLL laden.

[CiNcH]

Ich habe jetzt mal nachgesehen. Der DVBViewer setzt dieselben Werte wie MPC-HC. Macht ja Sinn, sonst würden schließlich die Shader nicht funktionieren...

 

c0[0] ... Texturbreite

c0[1] ... Texturhöhe

c0[2] ... Zykluszähler

c0[3] ... Sekundenzähler

 

c1[0] ... 1/Texturbreite

c1[1] ... 1/Texturhöhe

 

Die Textur hat die Dimensionen des Quellmaterials. Nicht zu verwechseln mit dem Back Buffer welcher dann die Ausgabeauflösung hat.

[erwin]

Dank Dir.

 

Was ist

 

c0[2] ... Zykluszähler

 

 

sowas wie die frame number?

Edited July 19, 2011 by erwin

[erwin]

Macht ja Sinn, sonst würden schließlich die Shader nicht funktionieren...

d.h. da gibts ein agreement zwischen DVBV und MPC-HC - meine shader zu deinen shadern?

[CiNcH]

d.h. da gibts ein agreement zwischen DVBV und MPC-HC - meine shader zu deinen shadern?

Wieso Agreement? Shader sind ja zum einen eigenständige Programme und stehen zum anderen unter keiner Lizenz (zumindest die aktuell verfügbar nicht).

 

sowas wie die frame number?

Genau. Der zählt die Framezyklen.

[erwin]

Wieso Agreement? Shader sind ja zum einen eigenständige Programme und stehen zum anderen unter keiner Lizenz (zumindest die aktuell verfügbar nicht).

naja wenn ein prog shader einsetzt kann es doch selbst bestimmen welche register es einsetzt. und wenn du sagst die _muessen_ mit den von mpc-hc übereinstimmen....

[CiNcH]

Es sind ja noch ein paar Register frei. Brauchst du was bestimmtes?

[erwin]

Ich muss auch bei Gelegenheit mal schauen, warum Shader, welche als ps_3_0 kompiliert werden, nicht funktionieren.

Alle? Also ich hab einen (probier grat mal ein wenig herum was so geht) der compilert unter SM2 nicht

((1,1): error X5608: Compiled shader code uses too many arithmetic instruction slots (102). Max. allowed by the target (ps_2_0) is 64.
(1,1): error X5609: Compiled shader code uses too many instruction slots (110). Max. allowed by the target (ps_2_0) is 96.
[/codeBOX]

 

unter SM3 aber schon. Und läuft.

 

EDIT: seh gerade Shader-Editor != DVBV

Edited July 22, 2011 by erwin

[goldfield]

Hallo allerseits !

 

Leider hab ich jetzt immer noch nicht ganz begriffen, ob das verketten von Shadern unter DVBV-Pro nun wirklich funktioniert, oder nicht.

 

Wenn ja, könnte mir (Anfänger, mit eher geringen Computerkenntnissen) hier mal jemand Schritt für Schritt erklären,

ob und wie ich die Shader "Chroma" und "complex2a" miteinander verketten kann?

 

Zur Situation:

Auf meinem TV kann ich ehrlich gesagt keinen Unterschied erkennen, ob ich "Chroma" aktiviert habe , oder nicht.

Auf meiner 2,40m Leinwand hingegen bilde ich mir zumindest ein, eine leichte Verbesserung erkennen zu können.

Besonders deutlich meine ich dieses an den TV-Sendersymbolen zu erkennen.

Da der Shader "complex2a" aber hier eine deutlichere Verbesserung bringt, nutze ich den z. Zt.

Durch diesen Thread hier bin ich jetzt auf die Idee gekommen, beide miteinander zu verketten, sofern dies möglich ist.

 

Würde mich über eure Hilfe sehr freuen!

 

Gruß: goldfield

Edited September 8, 2011 by goldfield

[erwin]

Auf meinem TV kann ich ehrlich gesagt keinen Unterschied erkennen, ob ich "Chroma" aktiviert habe , oder nicht.

 

Hier ein Verkettungsshader der das Bild vertikal teilt. Links das Unveränderte, rechts mit wirksamen Chromashader (genauer: myChroma-Shader, ist aber äquivalent zum Original). Einfach ins Shader-Verzeichnis entpacken. Dann myChromaDivider auswählen.

 

myChromaDivider.zip

 

Die Chroma-Sharpener-Verkettung evt. Montag (Sorry bin im Urlaub)

 

erwin

[guenti51]

Sorry, aber ich sehe bei keinen deiner 3 Shader eine Veränderung. Keine Teilung, nichts.

XP Pro / GTX275 - Treiber 266.58

[erwin]

danke für deine antwort. ich hab ne amd graka. offenbar reagieren die nvideas auf den gleichen shader quelltext nicht genauso. ergibt mehrere möglichkeiten:

 

- ich hab was nicht standartkonformes vorgelegt (bin auch nur shader-anfänger)

- deine graka spielt nicht bei allen von mir eingesetzten syntaxelementen mit. (insbesondere #include, oder dateiergänzung *.psh)

- ???

 

was sagt denn der shader-editor. der gibt auch fehlermeldungen aus.

 

erwin

[goldfield]

Bei mir funktionirt die Teilung (ATI HD5450).

 

Wie ich erwartet hab, kann ich am TV keinen großen Unterschied entdecken.

Werd heute Abend mal am Großbild testen.

 

Besten Dank schonmal, für die schnelle Hilfe.

 

 

Gruß: goldfield

[guenti51]

Jetzt habe ich die *.psh Dateien mit ins Shaderverzeichnis kopiert und sehe zumindest den Teilerstrich.

Mit den Shader Editor habe ich mich nicht befassst, da zu wenig Ahnung von der Materie.

Eine Verknüpfung von Deinterlacing und Sharpen könnte ich mir für manche schlechte *.mpg gut vorstellen.

[goldfield]

Hallo!

 

Sorry, aber durch die Renovierung meiner Wohnung war das Thema bei mir etwas in Vergessenheit geraten.

Aber jetzt soll's weiter gehen.

 

 

Wie ich erwartet hab, kann ich am TV keinen großen Unterschied entdecken.

Werd heute Abend mal am Großbild testen

Anfangs war ich mir ziemlich sicher, das (zumindest bei 2,40m Bildbreite) der Chroma-Shader eine sichtbare Verbesserung bringt.

Jetzt bin ich mir da allerdings nicht mehr so sicher.

Mit dem Divider von erwin sehe ich links und rechts keinen großen Unterschied.

Das kann jetzt einerseits daran liegen, das die Verkettung (zumindest bei mir) nicht richtig funktioniert,

oder das der inzwischen installierte Catalyst 11.8 da mittlerweile schon von sich aus recht gute Arbeit macht.

 

Wenn die Verkettung aber bei erwin funktioniert, sehe ich auch keinen Grund daran zu zweifeln, das es bei mir ebenso funktioniert.

Ich vermute daher eher, das ATI das mit dem CCC-11.8 inzwischen besser im Griff hat.

 

 

Eine Verknüpfung von Deinterlacing und Sharpen könnte ich mir für manche schlechte *.mpg gut vorstellen

Auch, wenn das VA-Deinterlacing bei ATI schon recht gut arbeitet, hab ich bei einigen Filmen auch schon gemerkt,

das der deinterlace-Shader da auch recht hilfreich ist.

Daher wäre günti's Idee mit der deinterlace/sharpen-Verkettung sicher auch nicht verkehrt.

 

 

@ erwin:

Ich hab leider keine Ahnung davon, wieviel Arbeit das ist.

Wäre das für dich machbar, beide Verkettungen (Chroma/Complex2a und deinterlace/complex2a) zu erstellen ?

Oder evt. sogar eine Verkettung chroma/deinterlace/Complex2a ?

 

Evt. wäre es allerdings in dem Fall (ähnlich wie bei ffdShow) noch eine Überlegung wert,

in welcher Reihenfolge die Shader gechaltet werden sollten.

 

 

Gruß: goldfield

Edited October 16, 2011 by goldfield

[erwin]

@ erwin:

Ich hab leider keine Ahnung davon, wieviel Arbeit das ist.

Wäre das für dich machbar, beide Verkettungen (Chroma/Complex2a und deinterlace/complex2a) zu erstellen ?

Oder evt. sogar eine Verkettung chroma/deinterlace/Complex2a ?

 

Evt. wäre es allerdings in dem Fall (ähnlich wie bei ffdShow) noch eine Überlegung wert,

in welcher Reihenfolge die Shader gechaltet werden sollten.

 

Mit dem Media Player Classic HC kannst du solche Verkettungen testen. Wenns was bringt, kannst du ja nochmal nachfragen ob ichs dann für den DVBV mache.

 

 

erwin

[goldfield]

Hallo!

 

Den Mediaplayer Classic hab ich jetzt mal installiert, und den Chroma-Shader damit getestet.

Wie ich vorher schon geschrieben hab, sehe ich persönlich damit inzwischen keinen wirklichen Unterschied mehr,

obwohl ich mir zumindest einbilde, vor einiger Zeit noch eine Verbesserung mit dem Shader gesehen zu haben.

 

War das vorher tatsächlich nur Einbildung?

Oder kann es wirklich sein, das sich da mit den neueren ATI-Treibern (inzwischen CCC11.9) das Chroma-Upsampling verbessert hat?

 

Mit dem Deinterlace-Shader bin ich mir aber absolut sicher.

Bei TV-Show's (wie z.B. TV-Total o.ä.), aber auch bei einigen Filmen bringt selbst das VA-Deinterlacing meiner ATI HD5450 teilweise kein 100%iges Ergebniß.

Da bewirkt das deinterlacen per Shader nochmal eine etwas glattere Wiedergabe.

 

Da wäre ich dir also für eine Verkettung aus "Deinterlace/Complex2a" auf jeden Fall sehr dankbar.

(Ob man jetzt evt. den Chroma-Shader noch mit ins Boot nimmt, wäre eine Frege des Aufwandes, und ob andere User da evt. noch Bedarf haben)

 

Wie sieht das bei der Verkettung eigendlich mit der Reihenfolge aus?

Bei meinen früheren Experimenten mit ffdShow wurde das Deinterlacing immer zuerst durchgeführt, was ja sicher auch Sinn macht.

Oder sieht das jemand anders?

Gibt es bei den Shadern überhaupt eine Möglichkeit, auf die Reihenfolge Einfluß zu nehmen?

 

Gruß: goldfield

Edited October 22, 2011 by goldfield

[Ede_123]

Hi zusammen, da ich diese Kombination im MPC-HC schon seit Ewigkeiten nutze, wollte ich die Shader "chroma" und "sharpen_complex" miteinander verknüpfen. Irgendwas mache ich aber falsch. Die einzelnen Shader funktionieren, der Shader welcher die beiden verknüpfen soll jedoch nicht.

 

Ich hab meinen Versuch angehängt, der Shader "test" ist der, welcher "chroma_b" und "sharpen_complex_b" miteinander verknüpfen soll. Vielleicht kann sich einer mit mehr Ahnung vom Shader programmieren mal anschauen was da schief läuft?

 

Danke und Gruß

Ede

Shaders.zip

[erwin]

Da wäre ich dir also für eine Verkettung aus "Deinterlace/Complex2a" auf jeden Fall sehr dankbar.

OK, mach ich. Hab aber ein wenig Geduld.

 

Gibt es bei den Shadern überhaupt eine Möglichkeit, auf die Reihenfolge Einfluß zu nehmen?

Bei MPC-HC kann man es explizit vorgeben. Und mit der in diesem Thread beschriebenen Methode auch. Ergibt dann halt einen anderen Quelltext.

 

erwin

[erwin]

... mal anschauen was da schief läuft?

Deine hinsichtlich der includierten *.psh globalen #defines in test.xml

#define dx (p1[0])
#define dy (p1[1])

wirken sich auch in chroma_b.psh (negativ) aus.

float4 getPixel(float2 tex, float dx, float dy)
{
tex.x+=dx;
tex.y+=dy;

return chroma_b_tex2D(s0, tex);
}

Also hier Umbennung der Parameter dx, dy oder die #defines an eine andere Stelle.

 

erwin

[Ede_123]

Danke erwin, da wäre ich nie drauf gekommen. Ich habe diese Stelle jetzt geändert, sodass sie meiner Meinung nach jetzt keine Probleme mehr machen sollte, allerdings funktioniert es immer noch nicht

 

Wäre toll wenn Du nochmal einen Blick drauf werfen könntest, scheinst das ja echt gut zu können...

Shaders.zip

[erwin]

Dein Code scheint mir nun syntaktisch OK.

 

Allerdings deuten die Compiler Errors darauf hin das das verwendete Shader Model 2.0 am Ende seiner Möglichkeiten ist. D.h. das Shader-Programm test.xml ist einfach zu komplex. Im Speziellen reichen die vorhandenen temporären Register nicht mehr aus. Man kann sich die Shaderengines als processing units vorstellen, allerdings mit sehr, sehr geringen Fähigkeiten. Hier gibts massig Einschränkungen: Anzahl der nutzbaren Register (wenn wie hier in HLSL programmiert wird, benutzt der Compiler diese im Quelltext nicht sichtbaren Register), max. Anzahl der Instruction slots, etc.

 

Es gibt nun mehrere Möglichkeiten:

 

1. Das Problem ist wirklich zu komplex -> keine Chance ohne ein anderes (mit DVBV kompatibles) Shader-Model zu verwenden.

 

2. Die Komplexität ist nur scheinbar, ist durch eine ungünstige Programmierung so geraten. Dies kann z.B. durch die hier im Thread vorgeschlagene generische Methode durchaus passieren. Hier könnte es helfen den Code zu optimieren, d.h. die beiden Shader wirklich zu vereinen und nicht nur zu verketten.

 

erwin

[goldfield]

OK, mach ich. Hab aber ein wenig Geduld.

Kein Problem, nur keine Eile !

Bin schon dankbar, das sich überhaupt jemand damit auseinandersetzt.

Ich selbst verstehe bei eurer Fachsimpelei nämlich nur "Bahnhof".

 

Ihr seit ja jetzt erstnmal dabei, die Verkettung von Chroma und Complex2a zu erstellen.

Auch wenn ich selbst da keinen (oder nur marginalen) Unterschied sehe,

würde ich den dann auf jeden Fall (an Stelle des einfachen Complex2a) auch gerne nutzen.

(Schon wegen dem beruhigendem Bauchgefühl, alles an Bildqualität auszuschöpfen. )

 

Vieleicht kannst du mir ja dann im Anschluß (falls so ein "Dreierpack" überhaupt machbar ist),

noch den Deinterlacer davor schalten.

 

 

Gruß: goldfield

Edited October 26, 2011 by goldfield

[Ede_123]

@erwin:

Schade, das hatte ich fast schon befürchtet. Um den Shader komplett umzuschreiben fehlt mir jedoch das Wissen, denn von HLSL und Pixel Shadern habe ich keine Ahnung und auch die übrige Programmiererei betreibe ich nur nebenher ein wenig als Hobby. Bis ich mich in alles eingelesen und das gewünschte Resultat erzielt hätte würde es zum einen ewig dauern und wäre zum anderen wahrscheinlich immer noch Flickwerk, dass jemand der sich damit auskennt in viel kürzerer Zeit viel besser hinbekommen hätte.

 

Außerdem befürchte ich, dass ich mit dem fertigen Shader sowieso nichts anfangen könnte (siehe hier), da die Implementierung der Shader im DVBViewer scheinbar nicht optimal ist und meine GraKa somit ohnehin überfordert wäre.

 

@devs:

Wie steht ihr denn dazu? Sind derzeit Änderungen geplant bezüglich der Implementierung der Shader? Vielleicht sogar eine Möglichkeit beliebige Shader direkt im Programm zu verketten wie sie im MPC-HC besteht?

Wie erklärt ihr euch die deutlich schlechtere Performance im Vergleich zum MPC-HC (siehe Link) wenn doch eigentlich die selben Shader verwendet werden?

[goldfield]

Hier

http://www.DVBViewer.tv/forum/topic/47317-DVBViewer-zukunft/page__view__findpost__p__348815

geht's um die Zukunft des DVBViewer's im allgemeinen.

Mal abwarten, was meine Frage zum Thema "Scalierung/Shader" da zu Tage bringt.

[Tüftler]

-> http://www.DVBViewer...post__p__347604

[goldfield]

Hi Tüftler!

Da kann ich zwar erkennen, das es wohl um "Scalierung" geht, aber für mehr reicht mein Englisch nicht.

 

Wärst du evt. so nett ...

[Tüftler]

Es wird die Quell- und Zielauflösung ausgewertet und im Idealfall eine andere Anzeigemethode ohne Interpolation genutzt (Bildschärfegewinn).

Auch arbeitet er an einer Shader3.0 Einbindung, aber mehr sollte dann zu gegebenem Zeitpunkt CiNcH selbst vermitteln.

[erwin]

Mal 2 Fragen an die Insider:

 

1. welche Shader version wird derzeit unterstützt? maximal ps_2_0?

 

2. Fehler im Shader werden durch den DVBV ignoriert. Werden die Fehler irgendwo mitgeloggt (im DVBV, Shader Editor ist klar)?

 

erwin

[nuts]

Bis PS 2.0 wird derzeit unterstützt.

 

Wie die Fehler behandelt werden ist mir auch nicht 100% klar.

[erwin]

OK, mach ich. Hab aber ein wenig Geduld.

Leider schlechte Nachricht. Ich habs über Wochenende zusammengesetzt. Leider gilt auch hier das in

 

http://www.DVBViewer.tv/forum/topic/46386-shader-verketten/page__view__findpost__p__348805

 

berichtete. Es wird für das Shader Model ps_2_0 zu komplex. Die Anzahl der möglichen Instruction Slots sind der begrenzende Faktor.

 

Also weiter warten. Es kommen bestimmmt irgendwann seitens DVBV Anpassungen an ps_2_a, ps_2_b oder gar ps_3_0. Mit denen habs ichs positiv getestet.

 

Bis dahin erwin

[CiNcH]

ps_2_a müsste bereits jetzt funktionieren. ps_2_b habe ich noch nicht getestet. Müsste aber auch gehen. ps_3_0 setzt die Vertex-Verarbeitung mittels vs_3_0 voraus. Die D3D Render Engine im DVBViewer verwendet da die "Fixed Function Pipeline". Meine Version der D3D Render Engine verwendet vortransformierte Vertizes für Video. Damit läuft ps_3_0 auch.

[erwin]

Wenn das so ist.

 

@goldfield

 

Hier eine ps_2_a Version. Läuft zumindest im PixelShader-Editor. ps_2_0 bringt Fehler.

 

myDeinterlaceComplex2a.zip

 

 

 

 

@Ede_123

Deins läuft mit ps_3_0 - im PixelShader-Editor.

 

erwin