[softhddevice] Konfiguration für intel-vaapi?

Zitat von x_v

Ich hab mit vaapi-demo gespielt: Bei mir flimmert nichts mit 1920x1080, egal wie ich die Parameter kombiniere. Woran erkennt man das den genau bei grünen Bild? Sieht bei bir absolut statisch aus. X-Server gibt kein Fehler mehr aus.

Also dann ist bei dir ein anderer Fehler, es sollen Streifen mit einen Farbverlauf von grün nach magenta durch das Bild Laufen.
Bei >1280 Breite springt die Position ein paar 255 Pixel rechts und links.
Ich vermute das du die falsche Version hast:

http://cgit.freedesktop.org/va…ee/configure.ac?h=staging
Da steht eindeutig 1.0.16.1 als Version drin.
Bei gentoo gabs erst gestern die 1.0.18 als fertiges Packet, die 1.0.17 hatte wieder andere Effekte.
Und ich konnte deshalb nur GIT/Staging und 1.0.17 vergleichen.

Zitat

Ich hab mal getticks bei yadif eingebaut und das Ergebnis war in der Tat überraschend (bei 1440x1080, in Klammern bei 720x576):

Es gibt zwei Möglichkeiten:

1)

Die Zugriffe sind immer so langsam. Dazu hier:
http://lists.freedesktop.org/a…bva/2011-July/000551.html
Im Prinzip ist der GPU Graphikspeicher nicht gecached und man hat nur die normale Speichergeschwindigkeit.
Man könnte es ausrechnen wie schnell es gehen müsste und ob man diese Geschwindigkeit erreicht.
Es könnten Aligned Wort zugriffe am schnellsten sein.

2)

Die Dekodierung ist noch nicht fertig. Da CPU und GPU asynchron arbeiten, könnte die GPU immer noch dekodieren
und der erste Zugriff dauert noch länger.

Bei den Zeiten die fürs kopieren CPU <-> GPU gebraucht werden, kann man fast schon überlegen ob man nicht einen Softwaredekoder verwendet.

Theoretisch könnte man das obige vaapi-demo.c zum testen verwenden, da braucht man nicht immer den kompletten VDR starten.

Johns

Zitat von x_v

Bei mir geht es bis gnaz genau 1536x1080, danach fängt das Flackern an.

Komisch für 1280 habe ich eine Referenz gefunden, Gibt es einen Sender mit 1535x... ?
Und wer fragt nun mal auf der Maillingliste nach der Ursache?

Zitat

Die Lösung war sehr simpel: Nicht vaDeriveImage verwenden. Hab einfach mal auf den code gewechselt der da schon drin ist mit create/getimage: das kopieren dauert jetzt nur noch 0 bis 1ms insgesamt (bei VA-API 1.10 und Intel 1.0.18, mit VA-API staging und Intel staging sind es jetzt 4ms)! Auch wenn Yadif damit unter 40ms pro Frame kommt läuft es noch nicht flüssig, wie kann ich am besten messen wie viel Zeit ich fürs deinterlacen habe? Gab es einen Grund DeriveImage statt create/getimage zu nehmen?

vaDeriveImage sollte die schnellere Lösung sein, da eine Kopie bzw zwei Kopien gesparrt werden. Das Intel Treiber auch PutSurface unterstützt ist neu.
Es kann von der Intel Chip Generation abhängig sein, welche PutSurface unterstützen.
Man könnte es umbauen das PutSurface Vorrang hat und nur als Notlösung vaDeriveImage funktioniert.

Zitat

? Wenn die GPU sich keine resourcen mit der CPU teilt reicht es doch aus wenn sie in echtzeit dekodieren kann. es sollte ja nicht so sein H.264 bild kommt -> GPU dekodiert / CPU wartet -> GPU wartet / CPU deinterlaced -> Bild wird angezeigt, sondern während die CPU deinterlaced kann die GPU schon das nächste Bild fertig machen.

Im Prinzip richtig, aber im Moment werden die Funktionen direkt nach dem Starten der Dekodierung aufgerufen.
Also GPU gerade gestartet und schon wird auf fertig gewartet. Wenn man hier puffert dann klappt es wie von dir Beschrieben.

Insgesamt hat man 40ms Zeit um 2 Frames vorzubereiten:
1 * von GPU runterladen, 2 * yadif, 2 * auf GPU hochladen.

Aber im Moment läuft alles über VideoDisplayHandlerThread, da inbesonderen VA-API größte Probleme mit Threads hat.
Dadurch das im Moment nur ein Thread auf VA-API zugreift müssen nicht jede VA-API Funktion gelockt werden.
Da VA-API genug Probleme produziert, habe ich nicht versucht, hier zu optimieren.

Also man hat effektiv nur ca. 20ms in der jetzigen Funktion Zeit, ansonsten kommt es bei der Ausgabe zu Rucklern.

Johns

Zitat von x_v

Nicht das ich wüsste, hab einfach mal so typische vielfache von 2-er potenzen probiert, und genau da war die Grenze bei mir. Reagiert die Mailing-Liste den inzwischen?

1280 ist 0x500 und 1534 0x5fe das sind nicht viel Gemeinsamkeiten. Man muß sich halt auf der Maillingliste anmelden und posten und hoffen.

Zitat

Ich hab danach mal PutImage ausprobiert, das geht auch (nicht PutSurface), aber beides nicht perfekt: Bei SD-Sendern ist kommt bei getImage totaler Murks raus, weiß nicht warum, PutImage hat Probleme mit der Reinfolge der Bilder, ab und zu kommt das zweite vor dem ersten Bild. Beides bringt enorme Geschwindigkeitsvorteile, das laden/speichern dauert zusammen dann noch etwa 1ms (mit 1.10.0/1.0.18), aber immer noch nicht schnell genug für HD-Yadif (23ms), dazu wird noch Multithreading benötigt. Da gibt es aber noch Probleme mit der Synchronisation (aus irgendeinem Grund wartet der nicht bis die threads fertig sind), aber die Threads sind außerhalb der VA-API, die sollte da keine Probleme machen.
Ich hab den code im aktuellen Zustand mal hochgeladen.

VA-API hat verschiedene Image Formate je nachdem es sich um mpeg oder h264 handelt.
Ansonsten könnte es sein, daß sich in der Surface noch das vorherige Bild befindet.
vaSyncSurface(decoder->VaDisplay, surface) machen.
Dann wäre ein Ringbuffer wie SurfacesRb für die Anzeige nicht schlecht, der Vorteil ist man kann ohne Locks in den Ringbuffer schreiben und lesen.
Der Thread kann dann ebenfalls ohne Locks die fertigen Deinterlace-ten nach SurfaceRb packen.
Das macht VaapiQueueSurface.

Johns

Also eine Gemeinsamkeit habe ich gefunden: 1280 (0x500), 1536 (0x600), 1792 (0x700) gehen.

Bei libva 1.1.0 und intel-1.0.18 geht die Version die vor dem Anzeigen die Flächen füllt.
Die Version die vor der Schleife das gleiche macht, zeigt nur ein grünes Bild.

Johns

So ich habe noch einen Bug im Demo/Test Programm gefunden.
Wenn man den Speicher nicht einfach füllt, sondern richtig arbeitet, dann gehts.

Edit:
Ich habe noch etwas getestet. Der V-Sync scheint bei H264 Interlaced Programmen nicht zufunktionieren.
Auch Dr. Dish Tv welcher seit neusten in H264 sendet, scheint auch nicht ohne Ruckler zulaufen.

Edit:
Neue Version die Fläche ist nun sinnvoller gefüllt. Man erkennt das der aktuelle vaapi nur noch bob macht.

Johns

Da ich es nicht genau erkenne, gucke ich auf die Meldungen.
Wenn

video: slow down video, duping frame

jede Minute mit der Sync Information kommt, heißt es das der Videotreiber nicht auf V-Sync gewartet hat.

Musst mal genau gucken, ob das lesen immer solange dauert oder nur nach dem in den Puffer dekodiert wurde.

Dann kannst ja wieder vaDeriveImage nehmen und parallel an mehreren Frames arbeiten. Ich hoffe der Zugriff wird dann nicht noch langsamer.
Du kannst auch noch den Software Decoder nehmen, Beim Plugin "-w no-hw-decoder" dann wird VA-API nur noch für die Ausgabe verwendet.
Damit fällt dann das runterlader von der GPU weg.

Ich versuche gerade den anderen Weg, vaapi wieder bessere Deinterlacer beizubringen.
Leider ist definitiv in dem aktuellen Inteltreiber nur der Bob Deinterlacer über die API (auch die neue) zu erreichen.

Meiner Meinung nach müsste es dieser Commit sein: http://cgit.freedesktop.org/vaapi/intel-driver/commit/?h=staging&id=ae0aff6dfaa0446e6ba0636868576f7f596aa7fd

Johns

Das meinte ich ja software decoder -> deinterlacer -> vaapi. Meine Erfahrung war das mit ca. 2.6Ghz Single Thread die Leistung für Software Decoder reicht.

Für LibVa brauchst kein Mutex wenn du Derive und Map im Decoder Thread machst und dann in den Threads nur auf die Puffer zugreifst.
Ansonsten denke ich brauchst du Locks und dann bringen dir die Threads nicht mehr viel.

"video: slow down video, duping frame" ist im syslog, wenn das Plugin läuft, wir mischen hier zu häufig demo und plugin.

Docs zum Deinterlacer: http://www.x.org/docs/intel/HD/ http://www.x.org/docs/intel/HD/IHD_OS_Vol_4_Part1_BJS.pdf

Es geht nur mit dem Staging Branch, weil nur dort sind die Advanced Deinterlacer als Shader dabei.

gegen branch staging:

diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
index 80a788f..6daa3e5 100755
--- a/src/i965_drv_video.c
+++ b/src/i965_drv_video.c
@@ -3197,9 +3197,10 @@ i965_PutSurface(VADriverContextP ctx,
         pp_flag |= I965_PP_FLAG_AVS;
 
     if (flags & VA_TOP_FIELD)
-        pp_flag |= I965_PP_FLAG_TOP_FIELD;
+        pp_flag |= I965_PP_FLAG_TOP_FIELD | I965_PP_FLAG_MCDI;
     else if (flags & VA_BOTTOM_FIELD)
-        pp_flag |= I965_PP_FLAG_BOTTOM_FIELD;
+        pp_flag |= I965_PP_FLAG_BOTTOM_FIELD | I965_PP_FLAG_MCDI;
+
 
     src_rect.x      = srcx;
     src_rect.y      = srcy;

Müsste die wieder einschalten, Aber besonders gefallen tun die mir nicht.
Und nun hängt sich die GPU wieder regelmässig auf, am Besten mit 1080i Kanal starten.

Johns

Es kann sein das "video: slow down video, duping frame" nur wenn mit -DDEBUG gebaut erscheinen.
Die Meldungen sollten alle 500 Bilder erscheinen und der +xx Wert konstant sein.
Somit sieht mah hier schon, daß was nicht stimmt.

Zitat

Ist der Deinterlacer (teilweise) durch Shader implementiert oder "fest verdrahtet"?

Soweit ich es verstehe sind die Deinterlacer fest verdrahtete Einheiten, die mit einem Shaderprogramm gefüttert werden.
Ich habe noch etwas gelesen: MCDI ist nur in den Ivy Bridge GPU's (HD2500 + HD4000) eingebaut, wobei es im aktuellen Treiber auch nicht aktiviert wird.
In den Iron Lage und Sandy Bridge GPU's ist nur MADI vorhanden.

Ansonsten wird scheinbar nur die aktuelle Frame verwendet und diese immer als erste im Stream angesehen.

Edit: So wie es aussieht ist bei Intel ja Documentation, Beispiel und auch notwendige Programme vorhanden.

Das müstte der ShaderAssembler sein: http://cgit.freedesktop.org/xorg/app/intel-gen4asm

Johns

Im Moment geht nur spatial (mit dem Patch). Sollte aber besser als Bob sein.
Man könnte mal einen Test generieren. Meine aktuelle Demo legt es ja mehr auf temporal an, als auf spatial.

Man kann es nicht so leicht auf temporal umbauen, da muß man die vorherige Frame und die Statisiken übergeben.

http://cgit.freedesktop.org/va…st_processing.c?h=staging
Funktion pp_nv12_dndi_initialize da kannst an der "256 bit deinterlace message" rumspielen.

Und hier ist das Deinterlace Shader Programm: http://cgit.freedesktop.org/va…UVCopy_NV12.asm?h=staging

Und die meinte ich mit Beispielen.

Johns

P.S.: genau genommen handelt es sich um die Eclipse Public License (EPL)

Naja, bei Anderen kannst auch nicht an den Einstellungen herumspielen.
Ansonsten wollen sie noch die verschieden Deinterlacer über die API wählbar machen.

Viel machen die Shader ja nicht. Der Source ist absolut unlesbar und recht gering kommentiert.

Mein Problem ist, ich erkenne nicht wie die Daten an den Deinterlacer übergeben werden.

In pp_nv12_dndi_initialize wird die Source Surface in nach BINDING_TABLE_OFFSET geschrieben.
Tabellen Index 2 und 4 sind die Source.
Im Assember "gen5_6/Common/common.inc" sind die Tabellen Index für den Assember definiert.

Die Frage ist warum brauchen die Jahrzehnte um vernünftigen Treiber zuschreiben.
Vielleicht kann ja die Hardware gar nicht, was in der Dokumentation steht.

Johns

Bin auch einmal wieder auf staging gehüpft. Könnt Ihr mir gerade einmal
auf die Sprünge helfen, was ich wo patchen (s.o. Bob nach spatial) muss,
damit es wieder aussieht? Irgendwie versteckt sich der zugehörige
Beitrag vor mir.

Ok, vergesst es, Beitrag 31, hatte ich überlesen.

Zitat von x_v

Also, so habe ich das nun verstanden:
Es gibt eine Funktion i965_proc_picture die sich die surfaces aus einer pipeline holt. Danach werden die Filter in einer Schleife abgearbeitet. Der Filter hat dabei noch ein void argument filter_param, welches für dndi komplett nicht genutzt wird (bei dn wird es für ein parameter genutzt, wie stark denoise sein soll). Hier denke ich sollten die ganzen flags (möglichst so das sie für alle Generationen gehen) untergebracht werden.

Sehe ich genauso.
Ist nur was für Profis, die meisten sind hier überfordert. Und die aktuellen Werte werden so gewählt sein, das bei den Testprogrammen der geringste Fehler herauskommt.

Zitat

Die Daten wandern wie es scheint mit "i965_pp_set_surface_state" nach BINDING_TABLE_OFFSET und so an den deinterlacer, da scheint es einen speziellen index für die Zuordnung zu geben. 20 ist das surface welches die history enthält (beschrieben in kapitel 4.7.6.1.1 (seite 68) des pdfs). Denke mal irgendwie so muss auch das zweite input-surface hinterlegt werden und so wird man auch an das zweite output-surface kommen.

Die Frage ist warum 20? Man muß vielleicht doch die gesamte Buchserie lesen.
Aktuell werden die aktuelle Surface zweimal übergeben.
Das Ergebnis zweimal. Bei beiden gibt es ja zwei Planes.
Und 1x der obige beschriebene STMM und History Puffer zum schreiben.

Da nun gesagt wird, dies ist die erste Frame, wird die vorherige Surface und STMM nicht gelesen
Und nur eine Deinterlace Fläche geschrieben.

Um temporal zubekommen braucht man diese.

sampler_dndi[index].dw6.dndi_first_frame = 0;

Und schon hängt die GPU, es scheinen nur die Referencen zufehlen.

Nun ist die Frage wohin kommt die vorherige Frame und der STMM Puffer zum lesen
und die zweite Ausgabefläche.

Im GEN7 (Ivy Bridge) Code scheint es vorhanden zu sein, aber ob es sich so einfach übertragen lässt?

Zitat

Das problem ist nun das der ganze Postprocessingkram wie mir scheint auf ein 1-bild-rein-1-bild-raus angelegt ist. Die Frage ist erstmal wie geht das im Moment beim spatial deinterlace? Werden aus 50 fields pro Sekunde 25 oder 50 frames pro sekunde? Das erkenne ich im Moment noch nicht. Danach kommt dann die Frage wie man den Treiber passend erweitert. Wie es mir scheint geht es zumindest nicht einfach und sauber.

Im Moment wird ja nur 1 Bild aus 1 Bild produziert. Siehe Handbuch Seite 69 "4.7.6.2 First Frame Special Case".
Ich rufe mit 50 Hz die Funktion auf.
Beim erstenmal mit TOP, beim nächsten mal mit BOT.

Die neue libva API siehe va_vpp.h unterstützt die Übergabe von Referenzframes,
aber nicht die Ausgabe von gleich 2 Frames.

Also muß man auf jeden Fall im Treiber tricksen. Alle 2 Frames den Deinterlacer aufrufen-

Johns