• 19.04.2024, 12:18
  • Registrieren
  • Anmelden
  • Sie sind nicht angemeldet.

 

Re: Divx Hardware auch in R350?

Sonntag, 1. Juni 2003, 19:31

Ich habe den software encoder ned als neuerung angepriesen sonder ledeglich geschrieben das von einem neuartigen Software encoder die rede war... (unter anderen)

Und was ist mit meinem ersten Post?
A sinking ship is still a ship!

Re: Divx Hardware auch in R350?

Sonntag, 1. Juni 2003, 19:45

Zitat von »Man«

Ich habe den software encoder ned als neuerung angepriesen sonder ledeglich geschrieben das von einem neuartigen Software encoder die rede war... (unter anderen)

Und was ist mit meinem ersten Post?

du weißt ja offensichtlich nicht mal was du selbst schreibst...

Re: Divx Hardware auch in R350?

Montag, 2. Juni 2003, 21:32

also ich glaube auch nicht, dass da ein vollständiger divx encoder drin ist. ich habe das so verstanden, dass sich cpu und vpu das teilen. was genau die vpu dabei macht weiß ich auch nicht. cebalis! sag doch mal was!

Re: Divx Hardware auch in R350?

Montag, 2. Juni 2003, 21:43

also, ich hab gerade mit ihm getelt: er hat mal im doom9.org forum gelesen, dass seine karte "das kann". da hat er sich irgendein tool runtergeladen. jetzt sollen die neueren divx versionen das schon von sich aus unterstützen.

Hab was gefunden: http://forum.doom9.org/showthread.php?s=…ght=radeon+9700

Re: Divx Hardware auch in R350?

Montag, 2. Juni 2003, 22:23

da ging es aber nicht um encoding, sondern um die filterung und um mpeg2-decoding, dagegen hab ich ja nix gesagt

LiquidAcid

unregistriert

Re: Divx Hardware auch in R350?

Montag, 2. Juni 2003, 22:31

Zitat von »Man«

FullStremaing ist was föllig anders. ::)

Fullstreming soll die VideoQuallität steigen (änlich wie ein deblocker)... aber das weißt su wahrscheinlich selber...

Ich habe auch nicht behauptet, dass FULLSTREAM für Video Encoding benutzt wird.
Und diese dummen rolleyes sind auch wieder fehl am Platze, da du meinen Post anscheinend nicht richtig gelesen hast.

Zitat von »Man«

Mit dme R300 hat ATi die Video Shader eingefürt... wenn ichd as richtig verstanden habe kann die VPU so gewisse Video berechnungen übernemen...

Was Quatsch ist, da das einfache post-processing Filter sind, die auf die Bildaten angewendet werden. Ein einfacher fragment shader reicht dazu.
Das hat nichts mit MC und iDCT zu tun für die extra Logiken exisitieren.

cya
liquid

Re: Divx Hardware auch in R350?

Montag, 2. Juni 2003, 22:32

das ist der einzige beitrag, den ich finden konnte, der so ungefähr in die richtung geht. die überlegen da aber auch, wie man die karten weiterhin nutzen könnte. mpeg2 wird nur als etwas momentan realisierbares genannt. ist ja aber auch egal.

da hat sich cebalis wohl wirklich getäuscht...

naja schade, ich war mir schon sehr sicher, dass meine neue karte eine r350 karte wird. jetzt kommt nvidia doch wieder mit in die entscheidung...

Re: Divx Hardware auch in R350?

Montag, 2. Juni 2003, 22:37

auch MPEG2 Encoding ist nicht möglich, es sind nur einfache Filter möglich, da is überhaupt nix mit encoding

LiquidAcid

unregistriert

Re: Divx Hardware auch in R350?

Montag, 2. Juni 2003, 22:38

Das einzige was heutige GPUs können sind iDCT, MC und post-processed filtering. Das gehört alles in den Decoding Schritt und hat nichts mit Encoding zu tun.
Encoding ist sehr komplex und wird wenn dann NUR TEILWEISE auf GPU Hardware laufen. Dabei muss aber auf Synchronizität der Verarbeitung geachtet werden, sonst ist das processing langsamer als ohne GPU Einsatz. Und der ständige Transfer von und zur GPU ist ein so großer Blocker, dass sich das einfach nicht lohnt.
Der vollständigen Vorgang auf der GPU ablaufen zu lassen ist definitiv NICHT möglich, da die entsprechenden Logiken auf dem Chip fehlen (bestimmte mathematische und logische Operationen lassen sich einfach nicht durchführen).

cya
liquid

EDIT: Das ist genauso ein Problem wie das mit der Emulation der Tesselationeinheiten über den Vertex Shader. Geht nicht, da die GPU zu speziell aufgebaut ist.
NV hat mit dem NV35 einen Schritt hin zu mehr CPU-Ähnlichkeit getan, das Layout der Logiken zeigt mehr Verwandtschaft zu einer richtigen CPU. Das bringt natürlich Probleme mit sich (Standard vertex program Code ist mit dieser Architektur langsamer -> VS3.0 Code wäre optimal für die Architektur nur leider gibts keinen HL compiler dafür)
Das macht die NV30/NV35 Architektur natürlich zukunftssicherer. ATi wird spätestens mit dem R500 auch einen solchen Sprung wagen.
Möglich wäre es dann, dass die nächsten Architekturen so etwas wie Video Encoding in Hardware voll unterstüzten. Aber das ist Zukunftsmusik.

Re: Divx Hardware auch in R350?

Sonntag, 8. Juni 2003, 02:55

hey leute, ich hab da noch was gefunden. Da steht zwar auch nichts direkt vom encoding, aber immerhin vom "teile des divx codecs in den pixel shader laden". und vom videobearbeitung beschleunugen:

http://www.chip.de/news/c_news_9524990.html

LiquidAcid

unregistriert

Re: Divx Hardware auch in R350?

Sonntag, 8. Juni 2003, 03:21

Undefiniertes Geblubber.

Das einzige was hervorsticht...

Zitat

Laut ATI und DivXNetworks soll die Video-Performance um bis zu 50 Prozent steigern. Die CPU, die bisher den aufwändigen MPEG4-Codec alleine decodieren musste, wird entsprechend der Angaben weniger ausgelastet.


cya
liquid

Re: Divx Hardware auch in R350?

Sonntag, 8. Juni 2003, 03:32

ja, das steht da nicht direkt. aber immerhin ist von "divc codec teile in den pixel shader laden" die rede. sowas komplexes kann sich ain unwissender doch nicht ausdenken?

LiquidAcid

unregistriert

Re: Divx Hardware auch in R350?

Sonntag, 8. Juni 2003, 03:47

Sag ich doch: undefiniertes Geblubber...

"DivX Codec Teile"...
1. was sind Teile? 1% 5% 10% 50% ???
2. Codec = Coder/Decoder -> Was von beidem? Coder? Decoder? Oder etwa beides zusammen?

Ich bleibe dabei, das einzige was eine heutige GPU kann liegt im Decoding Schritt und das sind MC, iDCT und Filtering, mehr nicht.

Re: Divx Hardware auch in R350?

Sonntag, 8. Juni 2003, 09:17

Ist schon schwer zu akzeptieren...

LiquidAcid

unregistriert

Re: Divx Hardware auch in R350?

Sonntag, 8. Juni 2003, 16:13

Zumal das gesagte Verfahren mit Pixelshadern weitaus langsamer wird als ohne. Ein paar Berechnung im Pixelshader durchführen, dann den Framebuffer auslesen, wieder Daten in den GPU-Speicher hochschieben.
Framebuffer auslesen ist eine saulangsame Angelegenheit, das kann man schlicht vergessen.
Das einzige wofür das gebraucht werden kann ist, wenn die Daten nicht mehr zurücktransferiert werden müssen, wenn sie nämlich angezeigt werden sollen. Dann kann man sie mit fragment shaders bearbeiten (deblocking, box filtering, etc.) und dann in den Framebuffer schreiben, wo sie dann zur Anzeige bereitstehen. Das ist einigermaßen effektiv. Alles andere ist Zukunftsmusik.

cya
liquid