Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Kurztest madVR 0.87.16 mit meinen zuvor genannten Einstellungen + "trust DXVA color & levels conversion", wieder auf Intel:

 

Mpeg2 576i -> 16% GPU bei DXVA-Native und 34% GPU bei Intel QuickSync

Memory Dedicated -> 49MB bei DXVA-Native und 38MB bei Intel QuickSync

Memory Dynamic -> 162MB bei DXVA-Native und 166MB bei Intel QuickSync

 

H264 1080i -> 17% GPU bei DXVA-Native und 30% GPU bei Intel QuickSync

Memory Dedicated -> 64MB bei DXVA-Native und 64MB bei Intel QuickSync

Memory Dynamic -> 224MB bei DXVA-Native und 208MB bei Intel QuickSync

Link to comment

Na, das schaut doch gut aus! :D Gleiche Performance wie EVR-Custom, wenn ich die Zahlen richtig deute. Zumindest bei DXVA-Native. Bei Intel QuickSync war wahrscheinlich kein DXVA-Scaling aktiv, richtig? Die Performance-Verbesserungen sind ja nur für DXVA, also nur wenn entweder DXVA-Decoding (native), DXVA-Deinterlacing oder DXVA-Scaling aktiv sind.

Link to comment

Vollbild natürlich, Fenstermodus ist mir egal.

 

Wenn ich auf den QuickSync wechsel mach ich das nur im LAV, im madVR steht up-/downscaling immer auf DXVA und im Chroma kann ich den nicht wählen.

Link to comment

Naja vorsicht, im Gegensatz zum C_EVR habe ich auch im processing bei madVR kein deinterlacer aktiv. Mach ich den rein bin ich wieder bei ca. 30% GPU.

Die neue Option macht da nicht viel, ist die evtl immer an?

Link to comment

Hmmm... Aber im letzten Test hattest Du doch 30% bei DXVA Native, und im v0.87.16 Test nur 18%? Hattest Du im letzten Test Deinterlacing an und beim v0.87.16 Test aus? Dann sind die Tests natürlich nicht vergleichbar. Also eigentlich sollte die neue Option eine deutliche Verbesserung bringen - aber richtig deutlich halt nur unter bestimmten Bedingungen: Es darf kein Dithering an sein, auch kein Smooth Motion FRC, kein Gamma- oder Gamut-Processing, keine Custom-Output-Levels, keine Saturation/Hue/Contrast/Brightness-Changes usw usw.

Link to comment

Naja dann muss madVR auch nur 25 Frames und der EVR Custom 50 frames verarbeiten.

Deinterlacer muss für einen Vergleich schon gleich arbeiten.

Link to comment

Jo das ist wenn man mal auf die schnelle was testet. Deinterlacer war beim 1. Test an, anders macht das auch keinen Sinn (Äpfel/Birnen) :innocent:

Wann ich heute zum Testen komme kann ich noch nicht sagen, ich muss heute mal das schöne Wetter nutzen :horror:

Link to comment

Jau, sieht gut aus so.. v0.87.15 sollte für "DebugOsd" FALSE zurückgeben, mit der heute noch kommenden v0.87.16 dann hoffentlich TRUE.

 

Mit der .17 muss man den Filtergraph neu aufbauen, damit die Einstellung via Interface wirksam wird. Sie wird zwar irgendwie registriert, aber ein sichtbarer Effekt bleibt erst mal aus, und SettingsGetBoolean gibt dann z.B. bei aktivem Debug OSD als CurrentState false an. Soll das so sein???

Link to comment

Presentation Glitches

 

 

Das ist natürlich nicht so schön. Sind die Glitches auch visuell sichtbar? Und im FSE-Mode sind die wieder weg, richtig?

 

FSE hat es bis jetzt immer gefixt. Allerdings hat es sich für den Moment auch im Windowed Modus erledigt. Ich fahre den Rechner immer in den S3. Nach einem Neustart läuft es nun ohne Prsentation Glitches (sogar im Dual-Display-Betrieb). Ich denke, da hat wohl im Hintergrund etwas zu viel Ressourcen gefressen. Die höhere Anfälligkeit, wenn "mehr DXVA" zum Einsatz kommt, ist trotzdem interessant. Ich vermute, dass es einer Timing-Änderung geschuldet ist.

 

Performance-Vergleich: 1080i @ 1080p

 

Die wesentlichen Arbeitsschritte sind hier also Chroma Upsampling und Deinterlacing. Als Dekoder kommt LAV Video im dxva2n Modus zum Einsatz.

 

Standard EVR

 

GPU: 35% @ 350MHz (57°C / 2.9W)

 

madVR 0.87.13

 

Custom Settings:

- Windowed mode

- 10bit Chroma/Luma

 

GPU: 70% @ 850MHz (61°C / 8.2W)

 

madVR 0.87.17

 

Custom Settings:

- Windowed mode

- DXVA Chroma Upscaling + DXVA vertrauen

- 10bit Chroma/Luma

 

GPU: 74% @ 750MHz (60°C / 7.3W)

 

Fazit:

EVR ist immer noch deutlich sparsamer.

Was mir außerdem aufgefallen ist, dass mit 0.87.13 die horizontalen Kanten bei Senderlogos flimmern. Sieht irgendwie aus wie BOB Deinterlacer.

 

 

Windowed / FSE Umschaltung

 

FSE Umschaltung scheint nun auf den ersten Blick stabil zu funktionieren. Hast du da was gefixt? Oder liegt es am neuen DXVA Handling? Da gab es ja mal Problem, wenn "copyback" verwendet wurde.

Ich frage mich, ob man beim Umschalten einen kurzzeitigen Rückfall in den Windowed Modus vermeiden kann? Wahrscheinlich wird dafür auch das Rendering im Stop-Zustand benötigt?

Link to comment

Danke für die Tests! Kannst Du testhalber auch mal Dithering ausschalten? Das "DXVA vertrauen" hat einen wesentlich größeren Performance-Effekt, wenn Dithering dazu auch noch ausgeschaltet ist. Ok, gibt noch ein paar andere Umstände, die zutreffen müssen, damit der größte Performance-Gewinn erreicht werden kann: Keine XySubFilter-Subtitles, kein Gamut- oder Gamut-Processing, kein Smooth Motion FRC, kein Debanding usw usw...

 

Ich mache inzwischen überhaupt kein Copyback mehr bei DXVA, das hat wahrscheinlich für die FSE Umschaltung einen Fortschritt gebracht. Meine Überlegung dabei war, daß für das Decodieren LAV Video Decoder eine sehr gute/effektive Copyback-Implementierung hat. Besser als das, was ältere madVR Versionen gemacht haben. Also wer für das Decoding Copyback haben will, sollte es am besten im LAV aktivieren. Für Deinterlacing hab ich allerdings Copyback auch deaktiviert. Das hat vielleicht einen gaaaaanz kleinen Nachteil bei der Bildqualität, aber hat halt viele Vorteil, bei Performance, Stabilität, und auch Einfachheit meines Codes...

 

Flimmern die Kanten bei 0.87.17 auch, oder nur bei 0.87.13?

 

Rückfall in den Windowed Mode sollte es eigentlich nur geben, wenn die madVR-Instanz zerstört und neu erzeugt wird. Gab's da nicht im DVBViewer eine Option für?

 

P.S: Verwendet der "Standard EVR" DXVA-Scaling? Der Vergleich zu Deinem Custom-EVR mit DXVA-Scaling wäre wahrscheinlich passender? Weiß aber nicht, ob's zwischen Standard-EVR und Deinem EVR Performance-Unterschiede gibt...

Edited by madshi
Link to comment

Keine XySubFilter-Subtitles, kein Gamut- oder Gamut-Processing, kein Smooth Motion FRC, kein Debanding usw usw...

 

Ich verwende keine Sub-Filter. Bis auf die von mir angegebenen Einstellungen sind alle Default.

 

madVR 0.87.17

 

Custom Settings:

- Windowed mode

- DXVA Chroma Upscaling + DXVA vertrauen

- 10bit Chroma/Luma

- Dithering aus

 

GPU: 73% @ 700MHz (59°C / 6.8W)

 

Hat also nochmal ein bisschen etwas gebracht, aber immer noch weit vom EVR.

 

Was ist FSE?

 

Dein Lieblingsthema... Fullscreen Exclusive ;) .

 

Flimmern die Kanten bei 0.87.17 auch, oder nur bei 0.87.13?

 

Habe ich nur in .13 beobachtet. Bin mehrmals zwischen .17 und .13 hin und her gewechselt.

 

P.S: Verwendet der "Standard EVR" DXVA-Scaling?

 

Standard EVR verwendet natürlich den DXVA-Scaler über den Standard EVR Mixer. Der EVR Custom Presenter macht DXVA-Scaling auch nur über den Standard EVR Mixer.

Link to comment

Komisch. Ist mir nicht ganz klar, wo da jetzt noch so viel mehr Leistung verbraten wird. Vielleicht mache ich ein StretchRect mehr, aber das erklärt den Unterschied nicht. Als letzten Test (for now) könntest Du vielleicht mal das "Prepresent several frame in advance" in den Windowed-Mode-Settings deaktivieren? Hilft das noch etwas? Und der EVR macht auch Deinterlacing auf 50p, nicht auf 25p, korrekt?

Link to comment

 

Als letzten Test (for now) könntest Du vielleicht mal das "Prepresent several frame in advance" in den Windowed-Mode-Settings deaktivieren? Hilft das noch etwas?

 

Macht keinen Unterschied (mit defaultmäßigen 3 Back-Buffern).

 

 

Und der EVR macht auch Deinterlacing auf 50p, nicht auf 25p, korrekt?

 

EVR verwendet eine vollwertige DXVA-Pipeline, auch VA Deinterlacing mit Frame-Doubling, also 50fps.

Link to comment

Also meine Werte sind recht ähnlich.

 

Der Unterschied ist vorallem im Vollbild ziemlich groß, d.h. irgendeine Berechnung wird auf die FullHD Auflösungen angewendet und kostet GPU Power.

Was ist mit der RGB Konvertierung? Wer macht die wann wenn der DXVA Scaler aktiv ist?

Edited by nuts
Link to comment

Ich sehe, dass madVR bei jeder Fenstergröße ca. doppelt so viel GPU beansprucht (ziemlich linear). Bei der RGB-Konvertierung würde es IMHO eine Konstante sein.

Link to comment

Sollte die Last bei der RGB-Konvertierung nicht konstant sein? Sprich nicht von der Ausgabefenstergröße abhängen?

 

 

Ich habe hier noch einen Vergleich mit 720p50 (bei 1080p50 Ausgabe) gemacht, um so die "Interlacing Variable" zu eliminieren...

 

Standard EVR

 

GPU: 30% @ 350MHz (59°C / 2.7W)

 

madVR 0.87.17

 

Custom Settings:

- Windowed mode

- DXVA Chroma Upscaling + DXVA vertrauen

- 10bit Chroma/Luma

 

GPU: 72% @ 700MHz (61°C / 7.0W)

Link to comment

Die RGB-Konvertierung muß leider als letztes gemacht werden, weil bei manchen GPUs der beste DXVA-Scaling-Algorithmus nur dann verwendet wird, wenn man von NV12 -> NV12 scaled. Das heißt, ich muß erst von NV12 -> NV12 scalen und dann anschließend die RGB-Konvertierung machen. Weiß nicht, ob der EVR da vielleicht irgendwas anders macht. Aber wenn ich direkt in einem Schritt per DXVA NV12 -> RGB mache inklusive Scaling, dann wird bei AMD GPUs ein ganz schlechter Scaler verwendet. Das ist auch ein wichtiger Unterschied zwischen v0.87.13 und v0.87.17: Die 13 hat alles in einem Schritt gemacht, die v0.87.17 macht's getrennt. Deshalb ist die Bildqualität bei DXVA-Scaling mit der v0.87.17 wesentlich besser (zumindest bei AMD GPUs).

Link to comment

 

Rückfall in den Windowed Mode sollte es eigentlich nur geben, wenn die madVR-Instanz zerstört und neu erzeugt wird. Gab's da nicht im DVBViewer eine Option für?

 

Ja, es gibt die Option, dass der Graph beim Umschalten nicht neu gebaut werden soll. Die ist bei mir "an", also kein Graph-Neubau. Hatte nur gedacht, weil beim Umschalten immer wieder das "exclusive" OSD erscheint.

Link to comment

Könnte die RGB Konvertierung, zumindest bei Intel, nicht auch im CO-Prozessor funktionieren?

Das könnte den Unterschied zwischen EVR und madVR erklären.

Nehme an das kostet nach Luma und Chroma Scaling einige Rechentakte?

 

Wir müssen auch nicht den Standard EVR nachbauen, aber interessant ist's es ja wo der Last-Unterschied her kommt.

Link to comment

Test zur Option "trust DXVA color & levels conversion"

Performance im Vollbild windowed mode ist eher zu vernachlässigen, dafür schlägt mit dieser Option im Fenstermodus das Deinterlacing fehl.

 

 

oder es passiert gar sowas

 

Link to comment

Hier mal ein Debug-Log.

 

Vorgehensweise:

- DVBViewer im Vollbild gestartet

- Umschaltung

- DVBViewer in Fenstermodus und beendet

 

attachicon.gifmadVR - log.rar

 

Mist, hab vergessen zu sagen, daß das Debug-OSD an sein sollte. Dann hätte ich noch mehr hilfreiche Infos gehabt. Aber hab auch so was gefunden. Bin mir nicht sicher, ob es die Ursache ist, könnte aber gut sein:

 

00004966 Reset process Zappi.exe has created a topmost window
Was macht Zappi.exe genau? Geht das mit dem "Exclusive"-Switch weg, wenn Du Zappi.exe mal testhalber deaktivierst?

 

 

Könnte die RGB Konvertierung, zumindest bei Intel, nicht auch im CO-Prozessor funktionieren?

Das könnte den Unterschied zwischen EVR und madVR erklären.

Nehme an das kostet nach Luma und Chroma Scaling einige Rechentakte?

 

Wir müssen auch nicht den Standard EVR nachbauen, aber interessant ist's es ja wo der Last-Unterschied her kommt.

 

CO-Prozessor? Was meinst Du damit?

 

 

Test zur Option "trust DXVA color & levels conversion"

Performance im Vollbild windowed mode ist eher zu vernachlässigen, dafür schlägt mit dieser Option im Fenstermodus das Deinterlacing fehl.

attachicon.gifDeinterlacing_fail_.jpg

attachicon.gifDeinterlacing_io.jpg

oder es passiert gar sowas

attachicon.gifFarbe.jpg

 

Also bei mir funktioniert das Deinterlacing. Das mit den kaputten Farben passiert dann, wenn Du "trust" aktivierst, aber die andere(n) DXVA Option(en) deaktivierst. Das ist ein Bug meinerseits, aber diese Konfiguration macht eh wenig Sinn.

Link to comment

 

Was macht Zappi.exe genau? Geht das mit dem "Exclusive"-Switch weg, wenn Du Zappi.exe mal testhalber deaktivierst?
Ich habe Zappi jetzt mal geschlossen. Aber nach wie vor sehe ich das "exclusive" OSD beim Umschalten. Aber scheinbar nicht immer.

 

Mist, hab vergessen zu sagen, daß das Debug-OSD an sein sollte.

 

Wie mache ich das? [hat sich erledigt, siehe hier]

 

 

 

CO-Prozessor? Was meinst Du damit?

 

RGB-Konvertierung über DXVA. Bei Intel ist das ein dedizierter Co-Prozessor/ASIC.

Link to comment

Also bei mir funktioniert das Deinterlacing. Das mit den kaputten Farben passiert dann, wenn Du "trust" aktivierst, aber die andere(n) DXVA Option(en) deaktivierst. Das ist ein Bug meinerseits, aber diese Konfiguration macht eh wenig Sinn.

Sorry mein Fehler, ich hatte zum Test das Up-/Down-Scaling auf Bilinear gestellt.

Link to comment

Hier noch ein paar Zahlen von mir.

 

MadVR 0.87.17 (Alle Trade Optionen an, dithering aus, Deband aus und gamma Processing aus)

 

1080i50 h.264 Quelle, LAV DXVA2

Fenster Modus 25% @350mhz

Volldbild: 55% @350/650mhz (schwankt)

 

720p50 H.264 Quelle, LAV DXVA2

Fenster Modus 17% @350mhz

Vollbild 49% @350mhz

 

 

EVR Custom:

 

1080i50 H.264, LAV DXVA2

Fenster Modus (gleiche Größe wie bei madVR ;) ): 16% @350mhz

Vollbild: 28-29% @350mhz

 

720p50 H.264, LAV DXVA2

Fenster Modus: 7% @350mhz

Vollbild: 22% @350mhz

 

 

Bei mir sind wir im Fenster-Modus also recht nah dran, aber im Vollbild ein gutes Stück weiter auseinander.

Edited by nuts
Link to comment

Performance muß ich mir nochmal angucken.

 

Ich habe Zappi jetzt mal geschlossen. Aber nach wie vor sehe ich das "exclusive" OSD beim Umschalten. Aber scheinbar nicht immer.

 

Das Log sagt:

 

> 00006035 Render fullscreen windowed mode, covered by some windows
> 00006035 Render madVR window [madVR] {0,0,1920,1080}
> 00006035 Render covered by window [TTranspPanel] {0,0,1920,1080}
Da scheint jemand ein "TTranspPanel" zu malen, und zwar über das madVR-Rendering-Window. madVR erkennt das, denkt daß das madVR-Window zumindest zum Teil überdeckt ist, und verläßt deshalb kurzzeitig den FSE-Mode. Wenn ich mir die Namensgebung angucke, klingt das "TTranspPanel" nach einem Delphi-Form, was vermuten lassen würde, das es vom DVBViewer stammt. Da wäre dann die Frage, warum der DVBViewer beim Wechsel von einem File zum nächsten kurzzeitig ein TTranspPanel über das madVR-Window legt? Könnte sein, daß das für GUI/OSD-Zwecke ist, aber dafür verwendet DVBViewer ja eigentlich die madVR-OSD-Interfaces, von daher denke ich, daß das mit dem TTranspPanel etwas sein müßte, was man vermeiden könnte.
(Edit: Komisch, das "[ code ]" scheint hier im Forum nicht ordentlich zu klappen.)
Edited by madshi
Link to comment

Ja die Forum Software ist etwas seltsam. :(

 

Ich kann den von cinch beschriebenen Effekt mit dem FSE auch reproduzieren.

Plugins sind bei mir keine im Spiel und daher wird es schon mit dem DVBViewer direkt zusammenhängen.

Ein Fall für Griga. :)

Link to comment

Ich hätte da noch ein paar Fragen zum Chroma Upscaling,

Wenn im OSD "Chroma > DXVA" steht nehme ich an es wird per DXVA erledigt. Könnte man das für einen Test abschaltbar machen, macht sowas Sinn?

Kann man dafür ein Testvideo "bauen" um die Funktionalität zu sehen (zum Bsp. auch in die andere Richtung "Chroma < DXVA")?

Wir sprechen doch hierbei über die Farbunterabtastung, richtig? -> http://de.wikipedia.org/wiki/Farbunterabtastung

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...