MPx-Encoden über DX9 Grafikchip?

[Gast]

Hallo,

wollte mal fragen, ob es möglich ist oder Ansätze dafür gibt, MP2- oder MP4-Video-Encoden über den DX9-Grafikchip zu beschleunigen? Oder ist DX9 mit den Shadern 3.0 noch nicht so weit?
Dann könnte man wenigstens die CPU/System entlasten.

Tschüss

[Xmas]

Du solltest die NV40/R420-Reviews lesen ;)

Sowohl ATI als auch NVidia werben mit diesem Feature. ATI mit einer "Teil-Beschleunigung" von Video-Encoding über die Shader, NVidia hat dafür eine eigene Video-Processing-Unit in den Chip integriert.

[Endorphine]

Das macht außerdem erst mit (nativer) PCI-Express Anbindung Sinn. Mit AGP und Bridges dürfte die Performance dank elendiglich großer Latenz und schmaler Rückkanalbandbreite (>=15 ns Latenz, 266 MiB Bandbreite ... PCI32/66 Speed) unterirdisch sein. Selbst load-balancing lohnt sich bei der I/O-Leistung von AGP imo nicht wirklich.

[Demirug]

Endorphine, wer hat dir den den Floh ins Ohr gesetzt das man bei AGP nur einen 266 MiB Rückkanal hat?

[Endorphine]

Stimmt, es sind ja in der Realität noch viel weniger :D

[Demirug]

Original geschrieben von Endorphine
Stimmt, es sind ja in der Realität noch viel weniger :D

Ich werde mal messen gehen. Die Speed ist nähmlich in den letzten beiden Jahren ständig besser geworden.

[ow]

.

[mrdigital]

Original geschrieben von ow
Ich frage mich, wieso der AGP Rueckkanal zu langsam sein sollte? Welche Massen an kodierten Daten braucht ihr denn?

Nehemn wir zB. mal eine komplette Video-DVD, MPEG2, etwa 2 Std. fuer einen Film, etwa 8GB.

Ist bei 200MB/s Rueckkanal in etwa 40s geschrieben. Zu langsam??

Da wird weit vorher jede Festplatte limitieren, auf die die Daten geschrieben werden sollen.
Ack, ich sehe das genau so, für Videoecoding habe ich die Rohdaten mit ca 720*540*50*3 Byte (50 PAL Auflösungs-Vollbilder in einer Sekunde) oder ca. 55MiB/s. Die müssen zum Encoder hingeschafft werden, was bei 2GiB/s nun kein ernstes Problem werden sollte. Zurück kommt mein codiertes Video, MPEG2 hat auf ner DVD ca 8MBit/s also 1MiB/s, das dürfte bei rund 200MiB/s Rückkanal wohl zu realisieren sein, auch mit einer ordentlichen Performace. Selbst wenn man auf der Videohardware nur die DFT (oder einer ihrer Verwandten) durchführt, also noch keine Datenreduktion stattfindet, hat man einen Rückstrom vom 55MiB/s was bei über 200MiB/s Kanalbandbreite auch kein Thema wird, dass man dabei Latenzzeiten hat ist vollkommen wurscht, da man die Daten in recht grossen Blöcken bearbeitet und nicht Byteweise zugreiffen muss.

[PhoenixFG]

Diese Argumentation hinkt doch auf allen vieren, oder? Wenn das so zutreffen würde, dann frag ich mich, warum CPUs Bandbreiten im GB-Bereich benötigen.


MfG

[mrdigital]

Original geschrieben von PhoenixFG
Diese Argumentation hinkt doch auf allen vieren, oder? Wenn das so zutreffen würde, dann frag ich mich, warum CPUs Bandbreiten im GB-Bereich benötigen.


MfG
wo hinkt das?
CPUs müssen mit den Daten arbeiten, produzieren Zwischenergebnisse etc pp. Das muss alles druch das Ram geschoben werden. In der Graka wird das genauso geschehen, doch hat die ja ihren eigenen Speicher, der nun wirklich schnell genug ist mit Grössenordnungen um 30GiB/s

[Gast]

In wie weit reicht die Performance, um z.B. in HDTV(1920x1080) in Echtzeit zu encodieren?
(Bei Digital-Sat sind die Daten schon "fertig".)

[Ikon]

Original geschrieben von Gast
In wie weit reicht die Performance, um z.B. in HDTV(1920x1080) in Echtzeit zu encodieren?
(Bei Digital-Sat sind die Daten schon "fertig".)

Wie wäre es mit gar nicht? :) Um HDTV (z.B. 1920x1080 MPEG4) in Echtzeit nur zu dekodieren sind etwa 2GHz das Minimum (um eine Zahl ins Spiel zu werfen). HDTV-Echtzeitkodierung werden wir Konsumenten nicht so schnell sehen sofern die neuen Grafikchips nicht ein Wunder vollbringen (was ich immer noch bezweifle).

[robbitop]

soweit ich weiss, ist hin und rückkanal beim AGP dynamisch.
Was die Latenzen angeht habe ich kA.
Aber bei AGP 8x hat man 2GiB/sek das sollte erstmal reichen.

AFAIR kann man MPEG erst mit SM3 ENcoden. Decoden kann man mittels SM2 schon _beschleunigen_.
Aber da der Chip dann beim Encoden zu heiss würde, hat NV den VP implementiert (offizielle Aussage).

Abwarten bis es im Treiber auch unterstützt wird...

[Quasar]

Original geschrieben von Ikon
Wie wäre es mit gar nicht? :) Um HDTV (z.B. 1920x1080 MPEG4) in Echtzeit nur zu dekodieren sind etwa 2GHz das Minimum (um eine Zahl ins Spiel zu werfen).
Allerdings schafft es ein mit 300MHz getakteter, visueller Co-Prozessor, mit aktuellen Grafikchips nicht ansatzweise mithalten kann, schafft es, die CPU-Last von 100% auf ~35% zu senken. :naughty:

Bitte also nicht immer von CPUs auf parallele Vektorrechner schließen.

[Ikon]

Original geschrieben von Quasar
Allerdings schafft es ein mit 300MHz getakteter, visueller Co-Prozessor, mit aktuellen Grafikchips nicht ansatzweise mithalten kann, schafft es, die CPU-Last von 100% auf ~35% zu senken. :naughty:

Bitte also nicht immer von CPUs auf parallele Vektorrechner schließen.

Oh, ich zweifle gar nicht an den Möglichkeiten der Hardware sondern eher an der Software-Implementation. Aber das ist ein anderes Thema.

[Wishnu]

ALso so entscheidend kann die Bandbreite alleine nicht sein, denn ich habe grade festgestellt, dass mein XP@2Ghz auch nur etwas mehr als doppelt so schnell encoded (gleiche Einstellungen und jeweiliger verzicht auf SSE/3Dnow!), wie mein Tualatin@-Celli@1.4Ghz, obwohl erstgenannter laut AIDA eine 5x höherer Performance beim Schreiben ins RAM aufweisen kann.
Im Prinzip kann man ja auch einfach mal den FSB runter drehen (dafür natürlich den Multi raufsetzen) und schauen, wie das Ganze skaliert...

[robbitop]

beim Encoden laufen ja viele Dinge zusammen. Cache, RAMbandbreite (was ja beim K7 sonst kaum eine Rolle spielt), die Integerleistung und FPU Leistung.
Und von all dem weisst ein K7 natürlich mehr auf als ein P6. (ausser die Cachebandbreite)

[Gast]

Original geschrieben von mrdigital
Ack, ich sehe das genau so, für Videoecoding habe ich die Rohdaten mit ca 720*540*50*3 Byte (50 PAL Auflösungs-Vollbilder in einer Sekunde) oder ca. 55MiB/s.
AFAIK hat PAL 24 bit farben, bei 3 bit wären das gerademal 8 verscheiden farben die ein pixel haben kann ;)
außerdem ist die PAL-auflösung 720x576 und nicht 720x540. damit hätten wir dann 720x576x24x50 = 474MiB/s

[robbitop]

hat PAL nicht nur 25 Bilder/sek?
Ausserdem wird der VP sicher nicht alles allein machen. Ich denke mal die CPU wird die kompliziertesten Dinge zum VP schicken. Denn bis eine Aufgabe von der CPU über den AGP überhaupt erstmal da ist, dauert es viele Takte. Somit ist weniger Datenmenge auf dem Bus notwendig.

alles imo

[Ikon]

Original geschrieben von robbitop
hat PAL nicht nur 25 Bilder/sek?

Es sind 50 Halbbilder, aber trotzdem stimmt die Rechnung nicht da ein Halbbild eben nur die halbe Zeilenanzahl aufweist (also 288 statt 576).

[robbitop]

Halbbild im Sinne von Interlacing?
Dann sind wir doch ca bei 233MiB/sek?

[Gast]

Wenn man es genau haben will:
720*(576/2)*50*3 Bytes/s = 720*576*25*3 Bytes/s = 720*288*50*3 Bytes/s = 31104000 Bytes/s = 31 MiB/s = 29,66 MB/s

sucht euch je eins davon raus.... ;)

[mrdigital]

Original geschrieben von Gast
AFAIK hat PAL 24 bit farben, bei 3 bit wären das gerademal 8 verscheiden farben die ein pixel haben kann ;)
außerdem ist die PAL-auflösung 720x576 und nicht 720x540. damit hätten wir dann 720x576x24x50 = 474MiB/s
1 Byte = 8 bit --> 24 bit = 3 Byte und was habe ich geschrieben? 720*540*50*3 Byte! Das mit der Pal Auflösung ist so nicht ganz korrekt von mir gewesen, aber das ist nun echt nebensächlich, es ging hier darum die Grössenodrnung klarzustellen, und ob nun 50MiB/s oder 55MiB/s, es ist die selbe Grössenordnung... Ich habe in Vollbildern gerechnet, ich weiss, dass TV in Halbbildern überträgt, aber auf DVDs wird nicht immer in Interlaced sondern oft in Progressive(=Vollbildern) gespeichert.
edit: ok wenn Progressive, dann auch nur 25 Bilder... d.h. ca 30 MiB/s

[tb]

Hiermit könnt ihr die Geschwindigkeit Eures Rückkanals messen:
http://www.seriousmagic.com/3D-DloadBenchmark.zip

Thomas

[robbitop]

~144 MB/sek
mit AGP8x nForce2 MCP-T (Abit NF7-S)
FX5900 @5950 2D Takt 500/900 3D Takt 500/900
AthlonXP 2400MHz
Einstellung: default also HAL und im Fenster
Treiber: NoAA/NoAF Vsync Off

ist das Ergebnis im Rahmen? Ich hab mal gehört, dass der AGP vom NF2 nicht so doll sein soll. 144MB/sek ist ziemlich wenig für AGP8x theoretisch max 2GiB/sek

[tb]

probiers mal in 1600x1200x32, da komm ich auf 196 MB/s mit meiner Radeon 9800 Pro (AGP4x + SiS735), im default Window sind es 154 MB/s

Thomas

[robbitop]

max beim TFT sind leider 1280x1024x32
hab da aber nur 148MB/sek. Ich denke mehr ist wohl nicht drin. Kann sein, dass es der NF2 ist.

der 56.72 gibt mir AGP 8x an.

[BlackArchon]

198,4 MB/s bei Radeon 9600XT mit AGP 8x, VIA K8T800-Chipsatz mit AGP 8x. 1280x1024x32 wurde verwendet.

[robbitop]

ich denk mal mein NForce2 Interface ist für die "Tonne".
Ich kann gern den ganz neuen AGP Treiber noch installieren...aber die Frage ist, ob es was bringt. Im NForce stecken einige Fehler drin, die nicht so erfreulich sind...vermutlich einer davon.
Interessant wäre mal ein Bench von jmd der auch nen NF2 besitzt mit ATi/NV Karte und/oder jmd mit einer NV Karte und VIA Chipset.

[BlackArchon]

124,7 MB/s bei Radeon 9600XT mit AGP 8x, Nvidia Nforce2-Chipsatz (Shuttle AN35N Ultra) mit AGP 8x. 1280x1024x32 wurde verwendet.

Das ist ja noch schlechter als dein Ergebnis...

[Aqualon]

Damit ihr euch über eure Werte trotzdem freuen könnt, SIS 630 onboard in 800*600*32 (mehr macht er ohne Reboot und Grafikram-Erhöhung nicht mit): ~36MB/s

Aqua

[BlackArchon]

Ha! Das unterbiete ich doch glatt!

Intel 865G Onboardgrafik, 1280x1024x32, 20 MB/s! Ach ja, und ein paar Grafikfehler. :freak:

[robbitop]

verdammt..jetz muss ich zu radikalen Maßnahmen greifen, um euch zu unterbieten =)
ich setze PCI Karten ein S3 Virge und ATi Rage pro =)

Also der nForce2 scheint nicht soo doll zu sein.
Entweder hast du keine AGP Treiber drauf, oder es ist nur AGP4x drin, oder du hast VSync an oder AA/AF (wirkt sich negativ aus) oder die R9600 ist tatsächlich etwas zu schwach, um den AGP auszulasten..

[BlackArchon]

Soll ich jetzt wirklich erst einen Pentium 133 mit ISA-Grafikkarte ausbuddeln?

Bei dem Nforce 2-System ist der aktuelle 4.24 Nforce-Treiber drauf, AGP 8x läuft, ebenso FW und SBA. AA und AF ist aus, ebenso VSync.

[robbitop]

ha! da kontere ich mit nem AMD 486DX2 66MHz und ner TSENG ET4000 ISA. :D

hm dann wirds wohl deine 9600 sein, die bremst ^^

[BlackArchon]

Original geschrieben von robbitop
ha! da kontere ich mit nem AMD 486DX2 66MHz und ner TSENG ET4000 ISA. :D
...http://130.89.160.183/jig/fora/ownedkick.jpg

Schon möglich, dass die 9600XT da bremst. Aber zum Glück hat dieser Benchmark ja keine Auswirkungen im Spiele-Alltag.

[BlackArchon]

Mit dem Deltachrome hab ich nur 78,8 MB/s. :(

[robbitop]

bei dem brauchst du auch nicht mehr. MPEG Encoden ist mit dem nicht drin, aber Decoden helfen, das sollte damit kein Problem sein.

Einfach zukünftige Treiber abwarten.

[BlackArchon]

Kann ich eigentlich von einer niedrigen Übertragungsgeschwindigkeit auf ein allgemein schlechtes AGP-Interface des Grafikchips schließen?

[robbitop]

nicht unbedingt.
aber möglich ist es. Das müsste man untersuchen.

[ow]

Original geschrieben von BlackArchon
Kann ich eigentlich von einer niedrigen Übertragungsgeschwindigkeit auf ein allgemein schlechtes AGP-Interface des Grafikchips schließen?

IMO nein. Das dürfte eigentlich eher eine Treiberfrage sein.

[Quasar]

PCI-e Karte mit HSI-Chip: ~290MB/s im default Window mit einem uralten BETA-Treiber auf einem BETA-Mainboard.

900MB/s sollten mit AGP8X allerdings drin sein, glaube ich.

PCI-e kann auch noch mehr, scheint momentan alles eine Treibersache der Grafikchiphersteller zu sein.

[robbitop]

ja theoretisch. Praktisch aber gleichen die Raten sich einigermaßen. Und keiner von denen kommt auch nur in die Nähe vom theoretischen Peak

[Mackg]

173 mb/s mit kt333 agp4x und 71 mhz AGP @r300

[The_Invisible]

137MB/s auf nforce2 :-(

scheint ja wirklich nicht der bringer zu sein der nforce 2 da

mfg