Motion Video und PS?

[Ailuros]

aths bitte nicht missverstehen, aber es wird wohl Zeit dass wir beide eine Erklaerung von den Gurus hier kriegen was damit los ist...

Ok wir hatten mit aths eine kleine Debatte ob man wirklich PS als Aushilfe (wie z.B. adaptives de-interlacing) benutzen kann oder ob ATI dass nur als marketing-blurb benutzt hat im Videoshader(tm). Ich hab immer noch keine Ahnung aber wuerde gerne wissen um was es sich handelt.

Hier kommt DeltaChrome und behauptet das Gleiche:

http://www.tech-report.com/etc/2003q3/deltachrome/index.x?pg=4

Also Marketing-Geschwaetz oder tatsaechlicher Einsatz der PS fuer video motion?

[Demirug]

Ja sicher geht das. Die meisten de-interlacing Verfahren bauen ja auf der Verwendung von Filtern auf. Mit einem PS 2.0 lassen sich nun bis zu 32 Farbwerte aus dem Original gewinnen und zu einem neuen Farbwert für das was man dann zu sehen bekommt verrechnen. Damit sind bis zu 5*5 Filter oder eben auch ungewöhnliche Abtastmuster möglich.

Mit dem "adaptive" sieht es nun schon etwas kritischer aus. Von Prinzip her kein Problem nur könnten die PS-Programme dafür etwas lang werden. Mit etwas CPU unterstüzung sollte aber auch das gehen indem man für die unterschiedlichen Filter jeweils einen PS hat und die CPU bestimmt welcher Filter wo benutzt werden soll. Da Filtern ja eine recht stumpfsinnige sich ständig wiederholende Arbeit ist ist der PS genau das richtige Arbeitstier dafür.

[Ailuros]

ATI hat keine whitepapers fuer ihren VIDEOSHADER, aber in der R300 Praesentation stand drin dass unter anderem die PS "enchanced apaptive de-interlacing" anwenden.

Video de-blocking ist auch da bei ATI und die photoshop filter fuer streaming video.

Fuer DC aus dem Link sieht es wohl aehnlich aus:

One benefit is the DeltaChrome's adaptive per-pixel deinterlacing capability, which purportedly eliminates artifacts like bob and weave. S3's pixel shaders also assist in video playback by accelerating iDCT.

Und jetzt bin ich wieder verwirrt durch Deinen Kommentar hier:

Mit etwas CPU unterstüzung sollte aber auch das gehen indem man für die unterschiedlichen Filter jeweils einen PS hat und die CPU bestimmt welcher Filter wo benutzt werden soll.

Wenn die PS die iDCT unit unterstuetzen sollen, wieso braucht doch noch mehr CPU Unterstuetzung (ich bin verdammt muede also klar denken kann ich momentan nicht)?

Weitere Frage:

Von Prinzip her kein Problem nur könnten die PS-Programme dafür etwas lang werden.

Heisst dass das da auch 3.0 Shader besser damit fertig werden koennten, theoretisch zumindest?

[Crushinator]

Original geschrieben von Ailuros
(...)
Ok wir hatten mit aths eine kleine Debatte ob man wirklich PS als Aushilfe (wie z.B. adaptives de-interlacing) benutzen kann oder ob ATI dass nur als marketing-blurb benutzt hat im Videoshader(tm). Ich hab immer noch keine Ahnung aber wuerde gerne wissen um was es sich handelt. (...) ATIs Source codes (http://www.ati.com/developer/indexsc.html) haben ein nice thing: Video Shader Demo (http://www2.ati.com/misc/demos/ATI-9700-VideoShader-Demo-v1.2.exe), vielleicht hilft das ja weiter. =)

[Demirug]

Original geschrieben von Ailuros
Und jetzt bin ich wieder verwirrt durch Deinen Kommentar hier:

Mit etwas CPU unterstüzung sollte aber auch das gehen indem man für die unterschiedlichen Filter jeweils einen PS hat und die CPU bestimmt welcher Filter wo benutzt werden soll.

Wenn die PS die iDCT unit unterstuetzen sollen, wieso braucht doch noch mehr CPU Unterstuetzung (ich bin verdammt muede also klar denken kann ich momentan nicht)?

Es könnte auch sein das die iDCT Unit den Job übernimmt den richtigen Filter zu wählen. Das mit der CPU war nur eine Möglichkeit.

Weitere Frage:

Heisst dass das da auch 3.0 Shader besser damit fertig werden koennten, theoretisch zumindest?

Ja da kann man sicherlich noch mehr Blödsinn machen.

[Ailuros]

Ja da kann man sicherlich noch mehr Blödsinn machen.

Hahahaha :D

Danke fuer die Antworten. :)

[aths]

Original geschrieben von Demirug
Mit dem "adaptive" sieht es nun schon etwas kritischer aus. Von Prinzip her kein Problem nur könnten die PS-Programme dafür etwas lang werden. Mit etwas CPU unterstüzung sollte aber auch das gehen indem man für die unterschiedlichen Filter jeweils einen PS hat und die CPU bestimmt welcher Filter wo benutzt werden soll. Da Filtern ja eine recht stumpfsinnige sich ständig wiederholende Arbeit ist ist der PS genau das richtige Arbeitstier dafür. Ich bleibe vorerst bei meiner Behauptung http://www.aths.net/files/smilies/devil.gif, dass es für adaptives Deinterlacing extra Logik auf dem Chip gibt, räumlich ganz in der Nähe des iDCT, und nicht die Pixelshader dafür bemüht werden. Imo werden PS höchstens für Postfilter-Effekte verwendet ("Videoshader").

Begründung: Adaptives Deinterlacing heißt ja nur, für jeweils sehr kleine Bereiche zu entscheiden, ob Bob oder Weave zum Einsatz kommt. Das konnte soweit ich weiß bereits R100.

[Ailuros]

Verdreh mir jetzt bitte das Ganze nicht. Meine "Wunschliste" gab lediglich "DVD playback durch Pixel Shader" an, wobei jeglicher Beitrag von PS bezweifelt wurde.

Apaptive De-Interlacing wird als Teil des VIDEOSHADER aufgefuehrt, wie und was ATI da macht hab ich immer noch keine Ahnung.

Auf jeden Fall machte der PS Teil Sinn in meinem originalen Post, immer noch mehr wenn es sich um eine Wunschliste fuer einen PS3.0 faehigen chip handelt :bäh:

[aths]

Original geschrieben von Ailuros
Verdreh mir jetzt bitte das Ganze nicht. Meine "Wunschliste" gab lediglich "DVD playback durch Pixel Shader" an, wobei jeglicher Beitrag von PS bezweifelt wurde. Wenn mein Account und meine Beiträge sich im Mitrax-Forum wieder angefunden haben, lese ich da noch mal nach.

[Gast]

Liesse sich das nicht recht einfach empirisch herausfinden?

Fall 1: iDCT und adapt. De-Interlacing als dedizierte Hardware

-> Nur wenige Transistoren werden benötigt und bei Benutzung 'aktiviert' -> rel. geringer Anstieg der Leistungsaufnahme (analog zu Notebooks, wo diese Funktion Mandat ist!)


Fall 2: iDCT und adapt. De-Interlacing via PS

-> Bei einem vollwertigen R300 z.B. müssten zwei 4xSIMD Pixelprozessoren bemüht werden (u.U. auch nur einer, aber daran glaube ich nicht). Der Stromverbrauch müsste beinahe wie unter voller 3D-Last ansteigen.

q@w

[micki]

Original geschrieben von aths
Ich bleibe vorerst bei meiner Behauptung http://www.aths.net/files/smilies/devil.gif, dass es für adaptives Deinterlacing extra Logik auf dem Chip gibt,

sofern die logic mathematisch formulierbar ist (und ich würde dabei gerne ein beispiel bekommen wo das nicht der fall sein sollte), sollte das ohne extra hardware im pixelshader programmierbar sein

MfG
micki

[zeckensack]

Original geschrieben von Ailuros
Apaptive De-Interlacing wird als Teil des VIDEOSHADER aufgefuehrt, wie und was ATI da macht hab ich immer noch keine Ahnung.

Auf jeden Fall machte der PS Teil Sinn in meinem originalen Post, immer noch mehr wenn es sich um eine Wunschliste fuer einen PS3.0 faehigen chip handelt :bäh: Erstmal vorweg: Ich habe keine Ahnung, ob das nun tatsächlich macht. Reine Spekulation ;)

Man kann Quell-Frames (Halbbilder, höchstwahrscheinlich) als Texturen behandeln. ATI-HW ab R100 unterstützt Texturen die non-power-of-two sind, allerdings muß man dabei auf Mipmaps verzichten (ist für Video auch ziemlich egal).
Man kann jetzt tatsächlich zwei solche Halbbilder durch die 'normale' Pixelpipeline jagen und auf ein Quad legen.

Für "Bob" muß man dafür dann noch ein wenig an den Texturkoordinaten spielen, "Weave" ist auch machbar, wobei mir das für diesen Beitrag jetzt zu kompliziert ist :)

Erkenntnis 1:
Man kann die Texturfilter benutzten, um Vergrößerungen auszuführen (Verkleinerung geht nicht, und sollte daher schon im Decoder erledigt werden).

Erkenntnis 2:
Man kann im Shader Bob und Weave berechnen, und mittels LRP zwischen beiden Methoden 'umschalten'. Dafür bräuchte man natürlich eine dritte Textur, die die Information enthält, wo welche Technik 'gewinnen' muß.
Das schicke an dieser Idee: die 'Umschalt'-Textur kann kleiner sein als die Halbframes, wenn wir die Methode blockweise auswählen. Noch besser: wenn man den Zahlenraum des Texturformats für mehr als 0 und 1 benutzt, kann man mehr oder weniger stufenlos zwischen Bob und Weave interpolieren.

[zeckensack]

Original geschrieben von Gast
Liesse sich das nicht recht einfach empirisch herausfinden?

Fall 1: iDCT und adapt. De-Interlacing als dedizierte Hardware

-> Nur wenige Transistoren werden benötigt und bei Benutzung 'aktiviert' -> rel. geringer Anstieg der Leistungsaufnahme (analog zu Notebooks, wo diese Funktion Mandat ist!)


Fall 2: iDCT und adapt. De-Interlacing via PS

-> Bei einem vollwertigen R300 z.B. müssten zwei 4xSIMD Pixelprozessoren bemüht werden (u.U. auch nur einer, aber daran glaube ich nicht). Der Stromverbrauch müsste beinahe wie unter voller 3D-Last ansteigen.

q@w Mal rech0rn:
Video im Vollbild, 30fps @ großzügigen 1600x1200. ~60Mio Pixel/s. Wenn ich jetzt mal grob zehn PS-Takte pro Pixel veranschlage (???), und durch die Anzahl der Pipes dividiere, multipliziert mit meinem Daumen, dann dreht RV350@300MHz auf 50% Last im Pixelbereich, während seine VS-Hardware tief und fest schläft.
Ich denke, das wäre noch im akzeptablen Rahmen, gerade angesichts der exorbitanten Auflösung :)

[AlfredENeumann]

Original geschrieben von aths
Ich bleibe vorerst bei meiner Behauptung http://www.aths.net/files/smilies/devil.gif, dass es für adaptives Deinterlacing extra Logik auf dem Chip gibt, räumlich ganz in der Nähe des iDCT, und nicht die Pixelshader dafür bemüht werden. Imo werden PS höchstens für Postfilter-Effekte verwendet ("Videoshader").

Begründung: Adaptives Deinterlacing heißt ja nur, für jeweils sehr kleine Bereiche zu entscheiden, ob Bob oder Weave zum Einsatz kommt. Das konnte soweit ich weiß bereits R100.


Diese Features sind AFAIK dem bis <R300 verbauten RageTheater zuzuschreiben. Ab R300 ist es im Chip intigriert, bzw über die Pixelshader realisiert.

[Gast]

@zecki:

Von Vollauslastung war auch nicht die Rede =) Und für die Filter brauchst du doch jeweils zwei Halbbilder, dazu etwas iDCT (Demi sagte, Sin/Cos im R300-PS würde bis zu 8 Takten verschlingen) und Motion Compensation.

Naja, wie dem auch sei dürften selbst die nur halb ausgelasteten Pixelshader aus deinem Rechenbeispiel mehr Saft ziehen, als dedizierte DVD-Hardware in Chip.


@AEN:
Nein, dem ist ziemlich sicher nicht so, denn auf den allerwenigsten RV250 ist der Rage Theater drauf und die werden trotzdem mit den genannten Feature beworben.

q@w

[zeckensack]

Original geschrieben von Gast
@zecki:

Von Vollauslastung war auch nicht die Rede =) Und für die Filter brauchst du doch jeweils zwei Halbbilder, dazu etwas iDCT (Demi sagte, Sin/Cos im R300-PS würde bis zu 8 Takten verschlingen) und Motion Compensation.Japp, eine Decoder-Vorstufe wäre zwingend erforderlich, um die Halbbilder im (Textur-)speicher zu parken, ebenso wie die Information "Bob oder Weave".

edit: ad "zwei Halbbilder", ja, ist klar. Multitexturing. Das ist ja der Witz an der Geschichte :)
Naja, wie dem auch sei dürften selbst die nur halb ausgelasteten Pixelshader aus deinem Rechenbeispiel mehr Saft ziehen, als dedizierte DVD-Hardware in Chip.Mein Gedankengang konzentriert sich auf Skalierung, Deinterlacing und die Einsparung des Overlays.
Außerdem habe ich eher pessimistisch geschätzt, zehn Takte sind der pure Wahnsinn. Bob/Weave sind quasi 'for free' (reines Textursampling), die ALUs müßte man nur bemühen, wenn man irgendwelche speziellen Filterkernel haben will, die nicht direkt vom Textursampler beherrscht werden.

Ich komme dann im günstigsten Fall auf drei Samples & LRP. Weit entfernt von zehn Takten :)

Dazu wollte ich noch gesagt haben, daß die Pipes nach getaner Arbeit (ein Frame) auch pennen gehen können. Es ist ja nicht so wie in Spielen, daß freie Leistung sinnvoll in mehr fps umgesetzt werden kann. Die restlichen 50% (oder mehr, je nach Shader-Länge und Auflösung) wären dann echte idle-Zyklen.

[AlfredENeumann]

Original geschrieben von Gast
@AEN:
Nein, dem ist ziemlich sicher nicht so, denn auf den allerwenigsten RV250 ist der Rage Theater drauf und die werden trotzdem mit den genannten Feature beworben.

q@w

Hab nachgeschlagen. Ab >=RV250 hatte schon intigrierten RageTheater.

[Gast]

Original geschrieben von zeckensack
Ich komme dann im günstigsten Fall auf drei Samples & LRP. Weit entfernt von zehn Takten :)

OK, für De-Interlacing mag das sein, was ist mit iDCT. Da sagt der Name ja schon, daß es was mit Sin/Cos zu tun hat, oder?


Nun ja, ich werd's morgen mal messen, ob es da wirklich große Unterschiede gibt zwischen 2D/Video/DVD und 3D-Games.

[Quasar]

Ups, wo war mein Cookie?

Naja, egal. Was ich noch reineditieren wollte:
Multitexturing mit einer TMU pro Pipe würde bei deiner obigen Rechnung (also der ganz oben) schon wieder Vollauslastung bedeuten, da du ja nur noch mit entweder halber Taktzahl multiplizieren oder durch die halbe Anzahl der Pipes teilen darfst.


Wir werden's sehen, ob die empirische Forschung zumindest einen groben Hinweis darauf geben kann.

Bei der GeForceFX z.B., die lt. Demir ja Sin/Cos in Hardware kann, würde ich angesichts des in einigen Treiberversionen losröhrenden FX-Flow beim DVD-gucken auf eine Nutzung der Pixelpipelines tippen.

[Crushinator]

Original geschrieben von Ailuros
(...)
Apaptive De-Interlacing wird als Teil des VIDEOSHADER aufgefuehrt, wie und was ATI da macht hab ich immer noch keine Ahnung. (...) Es handelt sich dabei genau genommen NICHT um einen Teil innehalb der VEDEOSHADER und wird extra unter eigenem Punkt geführt (http://www.ati.com/products/radeon9700/radeon9700pro/specs.html). Ergo, hat aths recht. Nur Deblocking und so'n Zeugs aka FULLSTREAM wird bei Bedarf (App-abhängig) auf den Pixel-Shadern ausgeführt. Ich dachte das ginge aus dem VIDEOSHADER-Demo bereits verständlich hervor, daß der Quatsch nur als Postfilter verstanden werden darf.

[Ailuros]

Original geschrieben von crushinator
Es handelt sich dabei genau genommen NICHT um einen Teil innehalb der VEDEOSHADER und wird extra unter eigenem Punkt geführt (http://www.ati.com/products/radeon9700/radeon9700pro/specs.html). Ergo, hat aths recht. Nur Deblocking und so'n Zeugs aka FULLSTREAM wird bei Bedarf (App-abhängig) auf den Pixel-Shadern ausgeführt. Ich dachte das ginge aus dem VIDEOSHADER-Demo bereits verständlich hervor, daß der Quatsch nur als Postfilter verstanden werden darf.

Es gibt keine klaren whitepapers dazu und das ist auch der Grund warum ich es eher als Frage gestellt habe und nicht als Fakte.

Die doofe Haarspalterei stammt aus dem mitrax.de forum wo ich auf einer Wunschliste "DVD playback durch Pixel Shader" fuer einen zukuenftigen chip erwaehnte. Leider sind die beiden Seiten momentan nicht zugaenglich, aber es ging davon aus dass ATI nur Marketing Schmarren erzaehlt und PS gar nichts damit zu tun haben. Die Radeon9700PRO flash Praesentation ist dabei auch nicht gerade klar darueber (VIDEOSHADER Section). Das Demo hab ich mir bis jetzt noch nicht angeschaut.

[Crushinator]

^^ OK....aber reines "DVD playback durch Pixel Shader" macht außer Verbraten von unnötigem Takt gar keinen Sinn. Denn die Algorythmen für iDCT und De-Intelacing sind in Hardwareverdrahtung aka DSP soweit perfektioniert, daß man in absehbarer Zeit keine programmierbare Logik für diese Verfahren benötigt. Aus diesem Grund wurde die vorhandene Technik geshrinked (einfach ausgedrückt die Decode-Hälfte eines RageTheater) und einfach mit aufs DIE gepackt. Für andere und aufwendigere Verfahren eignen sich wiederum die VIDEOSHADER. Dafür muß man allerdings selbst Shader schreiben, siehe dazu auch die DiVX-Beschleunigung (http://www.divx.com/divx/player/optimizations/) durch Postprocessing.

[Quasar]

Original geschrieben von crushinator
^^ OK....aber reines "DVD playback durch Pixel Shader" macht außer Verbraten von unnötigem Takt gar keinen Sinn.

Jeder Transistor zählt, insofern macht es IMO schon Sinn, wenn man seine eh notwendigen Einheiten auch für andere Aufgaben nutzen kann.

[Crushinator]

Original geschrieben von Quasar
Jeder Transistor zählt, insofern macht es IMO schon Sinn, wenn man seine eh notwendigen Einheiten auch für andere Aufgaben nutzen kann. Ja, aber nur dann wenn man nicht gleichzeitig eine technisch gute Lösung der mathematischen Problemstellung sucht, mit der man sich auch noch qualitativ und PR-freudig von der Konkurrenz absetzen möchte. ;)

[Quasar]

Original geschrieben von crushinator
Ja, aber nur dann wenn man nicht gleichzeitig eine technisch gute Lösung der mathematischen Problemstellung sucht, mit der man sich auch noch qualitativ und PR-freudig von der Konkurrenz absetzen möchte. ;)

=)
Tut man aber seit der GF4MX gar nicht mehr....

Naja, ich mess' jetzt mal.

[Crushinator]

Original geschrieben von Quasar
=) Tut man aber seit der GF4MX gar nicht mehr.... Kein Kommentar :D
Naja, ich mess' jetzt mal. Es wäre unheimlich nett, wenn Du auch sagen könntest, was genau Du messen möchtest und vor allem wie. :|

[Quasar]

Wieso kein Kommentar? :)


Naja, ich habe einfach vor, zu messen, ob sich beim DVD schauen ein signifikant höherer Stromverbrauch im Gegensatz zum normalen Video-gucken oder 2D Betrieb einstellt und wenn ja, wie dieser sich im Verhältnis zu einer PS2.0-Demo darstellt.

Kein hochwissenschaftlicher Ansatz, aber er könnte einen Anhaltspunkt liefern.

[Demirug]

Original geschrieben von Quasar
Wieso kein Kommentar? :)


Naja, ich habe einfach vor, zu messen, ob sich beim DVD schauen ein signifikant höherer Stromverbrauch im Gegensatz zum normalen Video-gucken oder 2D Betrieb einstellt und wenn ja, wie dieser sich im Verhältnis zu einer PS2.0-Demo darstellt.

Kein hochwissenschaftlicher Ansatz, aber er könnte einen Anhaltspunkt liefern.

Man könnte auch eine Pixelshader anwendung neben dem Video laufen lassen.

[Crushinator]

Original geschrieben von Quasar
Wieso kein Kommentar? :) Heißt: Ich habe nicht vor, diese Diskussion mit Details oder Argumenten zu führen, die nicht hierher gehören. =)
Naja, ich habe einfach vor, zu messen, ob sich beim DVD schauen ein signifikant höherer Stromverbrauch im Gegensatz zum normalen Video-gucken oder 2D Betrieb einstellt und wenn ja, wie dieser sich im Verhältnis zu einer PS2.0-Demo darstellt. Das ist gut, aber das Ergebnis kann ich Dir schon vorher sagen: Nein. =)

[Quasar]

Schade, das Stromdinges hat nicht viel gebracht. Zwischen bewegtem DVD-Bild und unbewegten besteht ein Unterschied von ca. 10W (insgesamt eine Leistungsaufnahme von ~130W).

Ein MPG-Video erbrachte eine Aufnahme von 115W. Die Quicktime-Version des Matrix-Reloaded Trailers erzeugte auch 130W Leistungsaufnahme.

Insofern also nichts wirklich greifbares


Demis Idee war besser:
Das RTHDRIBL-Demo fiel bei statischer Anzeige (ohne AA) des Schädel-Modells von ~42fps auf nur noch 30fps und zusätzlich begann die Animusic-DVD zu ruckeln....

[Demirug]

Original geschrieben von Quasar
Schade, das Stromdinges hat nicht viel gebracht. Zwischen bewegtem DVD-Bild und unbewegten besteht ein Unterschied von ca. 10W (insgesamt eine Leistungsaufnahme von ~130W).

Ein MPG-Video erbrachte eine Aufnahme von 115W. Die Quicktime-Version des Matrix-Reloaded Trailers erzeugte auch 130W Leistungsaufnahme.

Insofern also nichts wirklich greifbares


Demis Idee war besser:
Das RTHDRIBL-Demo fiel bei statischer Anzeige (ohne AA) des Schädel-Modells von ~42fps auf nur noch 30fps und zusätzlich begann die Animusic-DVD zu ruckeln....

Du müsstest wohl noch ein bischen mit der Fenstergrösse spielen um eine CPU-limitierung auszuschliessen.

[Quasar]

Ich glaube, die CPU hatte damit nicht so viel zu tun.

Was ich oben noch vergessen hatte: Wenn ich die HW-Beschleuigung in PowerDVD abgeschaltet hatte, fiel die Framerate im RTHDRIL-Demo von ~42 auf ~41fps, mit HW-Beschleunigung dagegen von ~42 auf ~33fps.

edit:
Obiges mit default-Fenstergröße sowohl der Demo als auch von PowerDVD.

Dazu noch:
Im 320x240-Fester war der Unterschied zwischen DVD und nicht DVD 130 zu 99fps.
Mit 4xAA halbierte sich der absolute Unterschied auf 16fps (66 vs 50fps)

[AlfredENeumann]

Original geschrieben von Quasar
Wieso kein Kommentar? :)


Naja, ich habe einfach vor, zu messen, ob sich beim DVD schauen ein signifikant höherer Stromverbrauch im Gegensatz zum normalen Video-gucken oder 2D Betrieb einstellt und wenn ja, wie dieser sich im Verhältnis zu einer PS2.0-Demo darstellt.

Kein hochwissenschaftlicher Ansatz, aber er könnte einen Anhaltspunkt liefern.


Macht das der borsti nicht schon immer bei seinen Mobilechip-Tests ?

[Quasar]

Original geschrieben von AlfredENeumann
Macht das der borsti nicht schon immer bei seinen Mobilechip-Tests ?

Keine Ahnung, ich hab' Artikel von Borsti schon lange nicht mehr gelesen.

[AlfredENeumann]

Original geschrieben von Quasar
Keine Ahnung, ich hab' Artikel von Borsti schon lange nicht mehr gelesen.

Hab nochmal was nachgeschaut. Er mist nur die Batterielaufzeit. Aber deine Testmethode war recht interessant.

[Quasar]

...hat aber leider nix gebracht. Erst der Tip von Demi brachte einen vagen Hinweis.

[Crushinator]

Original geschrieben von Quasar
Ich glaube, die CPU hatte damit nicht so viel zu tun.

Was ich oben noch vergessen hatte: Wenn ich die HW-Beschleuigung in PowerDVD abgeschaltet hatte, fiel die Framerate im RTHDRIL-Demo von ~42 auf ~41fps, mit HW-Beschleunigung dagegen von ~42 auf ~33fps. (...) Ich hab's nachgemacht :)

HW-Accel on
------------
a) RTHDRIL-Demo im Vordergrund: DVD ruckelt einwenig, Demo zeigt am Anfang ~32 fps an.

b) PowerDVD im Vordergrund: Nix ruckelt, Demo zeigt ~26 fps an.

HW-Accel off
------------
a) RTHDRIL-Demo im Vordergrund: DVD ruckelt wie Sau, Demo zeigt am Anfang ~32 fps an.

b) PowerDVD im Vordergrund: DVD ruckelt einwenig, Demo zeigt ~32 fps an.

In beiden Fällen zeigt der im Tray mitlaufende Taskmanager eine beinahe 100%ige CPU-Auslastung an, davon ~95% Kernel-Auslastung.

CPU-Auslastung, nur PowerDVD
-----------------------------
HW-Accel an: meist 0-2%, peak bei 14% (beinahe 0% Kernel)
HW-Accel an: meist 0-4%, peak bei 28% (beinahe 0% Kernel)

CPU-Auslastung, nur RTHDRIL
-----------------------------
permanent bei 100%, 95% davon Kernel.

Getestet wurde auf XP2000, 1 GB DDR266, R9700p, Win2K, alles @default. RTHDRIL auf 640x480, PowerDVD 4.0 in DVD-Norm (720x576)

[Crushinator]

Original geschrieben von Quasar
...hat aber leider nix gebracht. Erst der Tip von Demi brachte einen vagen Hinweis. Darf man bitte auch erfahren, was dieser Hinweis in etwa aussagen soll? :D

[AlfredENeumann]

Original geschrieben von crushinator
Ich hab's nachgemacht :)

HW-Accel on
------------
a) RTHDRIL-Demo im Vordergrund: DVD ruckelt einwenig, Demo zeigt am Anfang ~32 fps an.

b) PowerDVD im Vordergrund: Nix ruckelt, Demo zeigt ~26 fps an.

HW-Accel off
------------
a) RTHDRIL-Demo im Vordergrund: DVD ruckelt wie Sau, Demo zeigt am Anfang ~32 fps an.

b) PowerDVD im Vordergrund: DVD ruckelt einwenig, Demo zeigt ~32 fps an.

In beiden Fällen zeigt der im Tray mitlaufende Taskmanager eine beinahe 100%ige CPU-Auslastung an, davon ~95% Kernel-Auslastung.

CPU-Auslastung, nur PowerDVD
-----------------------------
HW-Accel an: meist 0-2%, peak bei 14% (beinahe 0% Kernel)
HW-Accel an: meist 0-4%, peak bei 28% (beinahe 0% Kernel)

CPU-Auslastung, nur RTHDRIL
-----------------------------
permanent bei 100%, 95% davon Kernel.

Getestet wurde auf XP2000, 1 GB DDR266, R9700p, Win2K, alles @default. RTHDRIL auf 640x480, PowerDVD 4.0 in DVD-Norm (720x576)

Vielleicht mal mit nem anderen DX9-Demo benchen?

[Quasar]

Original geschrieben von crushinator
Darf man bitte auch erfahren, was dieser Hinweis in etwa aussagen soll? :D

In etwa folgendes:
Original geschrieben von Quasar
Ich glaube, die CPU hatte damit nicht so viel zu tun.

Was ich oben noch vergessen hatte: Wenn ich die HW-Beschleuigung in PowerDVD abgeschaltet hatte, fiel die Framerate im RTHDRIL-Demo von ~42 auf ~41fps, mit HW-Beschleunigung dagegen von ~42 auf ~33fps.

edit:
Obiges mit default-Fenstergröße sowohl der Demo als auch von PowerDVD.

Dazu noch:
Im 320x240-Fester war der Unterschied zwischen DVD und nicht DVD 130 zu 99fps.
Mit 4xAA halbierte sich der absolute Unterschied auf 16fps (66 vs 50fps)

Ergo Conclusio:
- Der DX9-Demo-FPS-Unterschied zwischen HW-Beschleunigung "an" zu HW-Beschleunigung "aus" steigt an. Da HW-Beschleunigung die CPU entlastet, sollte die CPU Belastung als limitierender Faktor augeschlossen werden können.

- Der DX9-Demo-FPS-Unterschied zwischen HW-Beschleunigung "an" zu HW-Beschleunigung "aus" steigt an, aus obigem Punkt schliesse ich CPU-Last aus, d.h. es muss woanders 'haken'.

- Mit FSAA wurde der Unterschied nicht größer, also schließt sich die verfügbare Speicherbandbreite als limitierendes Element auch aus.


Bleiben zwei Möglichkeiten:
- Der Chip kann das Kontextswitching zwischen DVD und "DX9" nicht schnell genug hinbekommen

- Der Chip benötigt einige interne Einheiten für beide Aufgaben.

[Crushinator]

Original geschrieben von AlfredENeumann
Vielleicht mal mit nem anderen DX9-Demo benchen? Viel sinnvoller wäre IMHO eine R2x00 mit der selben Aufgabe zu beschäftigen, wobei die Shader-Anwendung entsprechend ausgewählt werden sollte.

[Crushinator]

Original geschrieben von Quasar
(...)
Bleiben zwei Möglichkeiten:
- Der Chip kann das Kontextswitching zwischen DVD und "DX9" nicht schnell genug hinbekommen

- Der Chip benötigt einige interne Einheiten für beide Aufgaben.
- Der Treiber kann das Kontextswitching zwischen Video und 3D nicht schnell genug hinbekommen.

[Quasar]

Stimmt, das wäre auch noch eine Möglichkeit.

[Gast]

Hallo;

hier ist IMHO einmal eine Bestätigung für MPEG durch PS :

http://www.s3graphics.com/pressrel/2003_09_23.html


The Chromotion Programmable Video Engine concept was developed to provide a wide variety of video processing functions in an advanced compact architecture. The powerful DeltaChrome DX9 core is the first to feature the Chromotion architecture that adds exciting new processing capabilities to applications such as WinDVD 5, as well as handling all of the functions previously assigned to fixed function blocks such as iDCT and motion compensation for MPEG decompression. This integration of video processing in one compact programmable block results in exotic capabilities as well as reducing cost and power consumption.