nuts Posted March 31, 2015 Share Posted March 31, 2015 Auf jeden Fall mal danke für das schnelle Umsetzen der API Erweiterung. Tests schaffe ich heute leider nicht mehr. Quote Link to comment
Tüftler Posted March 31, 2015 Share Posted March 31, 2015 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 Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Na, das schaut doch gut aus! 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. Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 (edited) @Tüftler: Vollbild oder Fenstermodus? Edited March 31, 2015 by nuts Quote Link to comment
Tüftler Posted March 31, 2015 Share Posted March 31, 2015 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. Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 Wow dann halbiert die neue Einstellung quasi die GPU Last? Quote Link to comment
Tüftler Posted March 31, 2015 Share Posted March 31, 2015 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? Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 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. Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 Naja dann muss madVR auch nur 25 Frames und der EVR Custom 50 frames verarbeiten. Deinterlacer muss für einen Vergleich schon gleich arbeiten. Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Mußte leider eine v0.87.17 auflegen, hatte in der v0.87.16 einen dummen Bug drin (der aber nichts an der DXVA-Performance geändert hat): http://madshi.net/madVR.zip Quote Link to comment
Tüftler Posted April 1, 2015 Share Posted April 1, 2015 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) Wann ich heute zum Testen komme kann ich noch nicht sagen, ich muss heute mal das schöne Wetter nutzen Quote Link to comment
madshi Posted April 1, 2015 Share Posted April 1, 2015 Haha, alles klar, kein Problem. Laß Dir ruhig Zeit, hat ja keine Eile. Quote Link to comment
Griga Posted April 2, 2015 Share Posted April 2, 2015 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??? Quote Link to comment
madshi Posted April 2, 2015 Share Posted April 2, 2015 Nein, das soll so definitiv nicht sein, sorry. Werde mir das nochmal angucken, und hoffentlich für die nächste Build dann fixen. Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 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? Quote Link to comment
madshi Posted April 4, 2015 Share Posted April 4, 2015 (edited) 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 April 4, 2015 by madshi Quote Link to comment
Griga Posted April 4, 2015 Share Posted April 4, 2015 Was ist FSE? Hier scheint mir nichts wirklich passend. Oder ist in madVR eine Freisprecheinrichtung implementiert? Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
madshi Posted April 4, 2015 Share Posted April 4, 2015 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? Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
nuts Posted April 4, 2015 Share Posted April 4, 2015 (edited) 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 April 4, 2015 by nuts Quote Link to comment
madshi Posted April 4, 2015 Share Posted April 4, 2015 Ok, muß ich vielleicht nochmal versuchen genauer zu analysieren, wo der Performance-Unterschied her kommt. Muß ja einen Grund haben... Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
nuts Posted April 4, 2015 Share Posted April 4, 2015 Kommt darauf an wann die gemacht wird. Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 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) Quote Link to comment
madshi Posted April 4, 2015 Share Posted April 4, 2015 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). Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
madshi Posted April 4, 2015 Share Posted April 4, 2015 Komisch, dann sollte FSE eigentlich aktiv bleiben. Wenn Du ein Debug-Log hochlädst, kann ich mal reingucken, ob ich was sehen kann... Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 Hier mal ein Debug-Log. Vorgehensweise: - DVBViewer im Vollbild gestartet - Umschaltung - DVBViewer in Fenstermodus und beendet madVR - log.rar Quote Link to comment
nuts Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
Tüftler Posted April 4, 2015 Share Posted April 4, 2015 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 Quote Link to comment
madshi Posted April 4, 2015 Share Posted April 4, 2015 Hier mal ein Debug-Log. Vorgehensweise: - DVBViewer im Vollbild gestartet - Umschaltung - DVBViewer in Fenstermodus und beendet madVR - 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. Deinterlacing_fail_.jpg Deinterlacing_io.jpg oder es passiert gar sowas Farbe.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. Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
Tüftler Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
CiNcH Posted April 4, 2015 Share Posted April 4, 2015 Ah, jetzt verstehe ich das mit dem Debug OSD. Nochmal ein Log im Anhang, selbe Vorgehensweise, diesmal ohne Zappi, aber mit Debug OSD. Problem besteht weiterhin. madVR - log.rar Quote Link to comment
nuts Posted April 4, 2015 Share Posted April 4, 2015 (edited) 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 April 4, 2015 by nuts Quote Link to comment
madshi Posted April 4, 2015 Share Posted April 4, 2015 (edited) 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 April 4, 2015 by madshi Quote Link to comment
nuts Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
Tüftler Posted April 4, 2015 Share Posted April 4, 2015 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 Quote Link to comment
Tüftler Posted April 4, 2015 Share Posted April 4, 2015 Ein Fall für Griga. Schaltet doch für einen Test mal das OSD per Tweaker ab, evtl. ist es das. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.