Keresés: - [Re:] Az AMD elérhetővé tette az OpenVideo Decode API-t

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

Új hozzászólás Aktív témák

#76 Abu85 HÁZIGAZDA dezz #75

Új Válasz 2011-04-12 15:57:39 #76
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz dezz #75 üzenetére

Lehet rajta skálázni. Nekem is egyéni konfig van a saját ízlésemhez szabva.
Sajna ez a max, amit találtam. A Brazos tesztben vannak saját képek.
#74 Abu85 HÁZIGAZDA Bici #72

Új Válasz 2011-04-12 15:09:56 #74
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Bici #72 üzenetére

ArcSoft SimHD:
CyberLink TT HD:
De töltsd le a progik próbaverzióit. Azokban asszem megnézhetők ezek a fícsőrök.
Igen. Ez az API pont erre jó, csak még senki sem használja. Nyilván ha használják, akkor mehet az egész Linuxon is.
#71 Abu85 HÁZIGAZDA dabadab #70

Új Válasz 2011-04-12 11:13:35 #71
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz dabadab #70 üzenetére

Például én nem mondanék le a Cyberlink és az ArcSoft szoftverek képminőség felskálázásáról, túl szép lesz a videó minősége. Ezek csak Winen érhetőek el.
XBMC meg van winre is. Linuxon választani kell, míg winen bármit megkaphatsz. Ez önmagában borzalmas előny. Nem véletlenül van lemaradva a Linux. Utóbbi rendszernek is vannak számottevő előnyei, de otthonra, multimédiára nem kérdés, hogy melyikkel jársz jobban, vagy melyik rendszer kínál több szolgáltatást/lehetőséget ... akár programot.
#69 Abu85 HÁZIGAZDA dabadab #68

Új Válasz 2011-04-12 10:24:42 #69
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz dabadab #68 üzenetére

Médiaboxoknál lehetséges, de a HTPC-knél már valós előny a Win7. A GPGPU az MS rendszerén gyorsabban fejlődik. Ez nem a Linuxnak kedvez.
A HPC-ben teljesen esélytelenek. A Fermi ellen még kereshetnek valamit, de a Kepler és a Knights Corner ellen már semmi esélye sem lesz az SI generációnak. Az AMD-nek implementálni kellene a virtuális memória támogatást, a szálakat meg kellene különböztetni prioritás szerint. Ezek a funkciók viszik a tranyót és abszolút nem illenek bele egy gémer rendszerbe, márpedig az AMD eldöntötte, hogy ők a gémer közösséget szeretnék kiszolgálni. Éppen ezért a Tesla ellen nem sok esély van. Persze a Radeonok esetében egyre nagyobb lesz az előny, hiszen az NV is döntött és inkább a HPC-t választják. Konkrétan sikeresen felosztották maguk között a piacot, mindenki happy, csak majd a userek nem lesznek azok (illetve már most sem azok, mivel a HD 4000-GF 200 esetében komoly árverseny volt, de a két cég eltérő irányba tart, így mostanában az AMD szabja az árakat, az NV pedig igyekszik ezt követni az óriáslapkákkal).
Az AMD-nek alapvetően nem érdekes a Linux. Túl kevés embert lehet nyerni. Odaadják az open driver lehetőségét, ami a heavyuser közösség számára fontos, és az NV nem adja meg, és ennyi szerintük elég egyelőre. Majd a közösség csinál a termékekhez drivert.
Persze nyilván jó lenne az AMD-nek a HPC piac is, de jelenleg teljesen más hardver kell oda, mint ami jó PC-s VGA-nak. Mindenki megpróbálja a lehető legtöbb területet lefedni, de a hardvert akkor is priorizálni kell, és el kell döntened, hogy melyik terület fontosabb számodra. Ez akkor lett volna érdekes, hogy ha az AMD is a HPC-t választja, így lényegében az NV-vel egy irányba tartanának, tehát a PC-s GPU esetében mindkét cégnek meg kell küzdeni azokkal a hátrányokkal, amelyeket egy HPC-be fejlesztett architektúra okoz. Pl.: nagy lapkaméret illetve nagyon gyenge skálázhatóság vagy úgymond butíthatóság. Ezekből az AMD nem kért, míg az NV igen. A Fermin lathatóak ezek a jegyek. A legnagyobb chip például óriási. Ráadásul az NV azt a shader szervezést nem is alkalmazza az olcsóbb termékeken, mert nagyon nem hatékony egy játékra. A GF1x4/1x6/1x8 már más multiprocesszorokat használ. Persze a skálázhatóság általános probléma. Ezt látható a GF1x6 és 1x8 esetében. Egyszerűen ezek a lapkák a saját kategóriájukban nagyméretűek, így versenyképtelenek. Az új GeForce GTX 550 Ti egy elég jelentős példa erre, nem is kapott szép értékeléséket. Persze lehet mondani, hogy nem 150 dollárért, hanem 120-ért jó lenne, na de itt jön képbe az előállítási költség, ami a nagy lapkaméretből, és a széles buszból jön, vagyis rosszul lehet a rendszert skálázni.
A Tegra az egy olyan terület, ahova az Androidhoz illő rendszerrel kell nevezni. Az Android fejlesztése nem acélos x86-ra. Megoldható, de állandó késésben van. A Windows 7 meg elég fos érintőképernyős kütyübe. A másik gond, hogy a Brazos platform is túl sokat fogyaszt (5 watt a tabletverzió TDP-je), ez eleve kizáró tényező. Senkit sem érdekel, hogy a Fusion IGP tízszer gyorsabb bármilyen mobil megoldásnál, ha nem fogyaszt a lapka 3 watt alatt, akkor nem kell a holmi. Majd a Wichita lesz oda jó jövőre, ami többnyire egy Ontario 28 nm-en (nem túl jelentős változásokkal). De az Android ott is gond. A Win8 persze megoldás.
#66 Abu85 HÁZIGAZDA devast #65

Új Válasz 2011-04-12 08:48:02 #66
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz devast #65 üzenetére

Nem hiszem, hogy a gyári meghajtókban érdemes reménykedni. Amíg a Linux elterjedtsége ennyire alacsony, addig nem opció pár keményjúzernek drivert készíteni.
#56 Abu85 HÁZIGAZDA GerykO #55

Új Válasz 2011-04-11 23:22:08 #56
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz GerykO #55 üzenetére

Ezt biztos nem Neumann mondta. Nem tudom, hogy ki, de nem Neumann János. Ez valamilyen reinkarnációs szabály, vagy mi. Régen olvastam róla, most meg fáradt vagyok utánakeresni.
A memóriavezérlő nem jó példa. Az FPU annál inkább.
#51 Abu85 HÁZIGAZDA Meteorhead #50

Új Válasz 2011-04-11 20:33:07 #51
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Meteorhead #50 üzenetére

Azért a kevés OpenCL alkalmazásban az AMD is vastagon benne van. Számukra a nagyobbik Fusion számít, és a programokat is nyári megjelenésre tervezik, hogy az APU nagyobbat üssön. Ha nem számítana a Llano rajtja, akkor több OpenCL program lenne. ... Ez az üzlet.
#48 Abu85 HÁZIGAZDA Meteorhead #47

Új Válasz 2011-04-11 19:11:43 #48
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Meteorhead #47 üzenetére

32 magos volt az a Larrabee, amit már elkészítettek, de elkaszáltak (ez volt elvileg a tervezés szerinti második generáció, és az első, amiből tényleges hardver lett). Van is kártya, csak nem adják ki. Andrew Richards volt, az aki a leírta a fejlesztéssel kapcsolatos érzéseit. [link] Ebből csináltam anno egy hírt. Sajnos az eredeti írást az Intel levetette, de a lényeget kiemeltem.
Már készül az új verzió, ami majd jövőre jelenik meg. Ebből is csak HPC-be lesz termék. Persze sok esélyt nem jósolok neki a Kepler ellen.
Az amin az Intel dolgozik koncepció, az a Larrabee-vel lett volna alkalmazható. Amíg opció volt a projekt, addig ez volt a terv. [link] Azt nem tudom, hogy mostanra mi változott.
#40 Abu85 HÁZIGAZDA Pikari #32

Új Válasz 2011-04-11 17:48:45 #40
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Pikari #32 üzenetére

Ha gyorsabb memóriát akarsz, akkor azt jelenleg a csatornák növelésével érheted el. Ezt meg kell fizetni a lábak számában. Nyilván a több lábat pedig mi fizetjük majd a kasszánál.
Mindenki elkezdte a GPU-t és a CPU-t egybepakolni. Lassan minden versenyző vállalat realizálja, hogy a heterogén éra elkerülhetetlen, ugyanis a CPU-magok számát nem tudod növelni a végtelenségig. Meg lesz az a határ, ami az egymagos rendszerek karrierjének véget vetett. Nagyon közel járunk a kritikus fogyasztási határ, vagyis olyan útra kell lépni, amivel a vég elnapolható. Ezért pakolják a cégek a CPU-t és a GPU-t össze. A késleltetésre érzékeny szálak a CPU-n lesznek futtatva, míg a párhuzamos végrehajtás esetében ki lehet használni a GPU masszív számítási teljesítményét.
Nyilván a következő lépcsőfok a még szorosabb integráció, de egyelőre erre nincs lehetőség. Majd 2013 környékén. Akkor lehet gondolkodni a memória-sávszélesség problémáján is.
A jelenlegi technikák mellett egy Cellhez hasonló megoldást tudsz kihozni. Ez persze nem olyan rossz, de vannak gyengéi, ami a PC-n alkalmatlanná tenné a rendszert.
#31 Abu85 HÁZIGAZDA Pikari #30

Új Válasz 2011-04-11 16:47:21 #31
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Pikari #30 üzenetére

Ha a jövőben megjelenő Atom nem gyúr rá a multimédiára, akkor az óriási fail az Intelnek, mert a Brazos fényévekkel az aktuális platformjuk előtt jár. Nem azt mondom, hogy verjék meg az AMD-t itt, de illene egy minimális szintet hozni.
Jó. Azt úgy lehet kivitelezni, hogy négycsatornás memóriavezérlőt építesz a CPU-ba. Ez kb. 1500+ láb. Belevéve a routing bonyolultságát cirka hatszorosára nőne a belépőszintű, és háromszorosára a középkategóriás termékek előállítási költsége.
Amit mondasz az mind kivitelezhető, ha a termékek fogyasztói árát megtöbbszörözik. Ja és el lehet felejteni a mobil forradalmat is.
#29 Abu85 HÁZIGAZDA Pikari #28

Új Válasz 2011-04-11 16:27:38 #29
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Pikari #28 üzenetére

Érdemes megnézni a gyakorlati példákért a Brazos tesztet. [link] Ott a videólejátszás táblázata, ahol le van vezetve, hogy négy videó lejátszása milyen minőségű. A két legmegterhelőbb videó akad az Atomon, míg a Brazos mindkettőt zsírul viszi. Az Atom + Ion páros gyomrát egyedül a Killa sample fogja meg.
Na most a gyakorlat világosan mutatja, hogy GPU-s gyorsítás nélkül egy Atom mellett meg vagy lőve. Alapvetően a Brazos processzormagjai mellett is meg lennél, ha nem lenne mellette egy UVD 3.0-s motorral szerelt IGP. Ez önmagában megalapozza a GPU-s gyorsítás létjogosultságát. Az AMD csak annyit szeretne, ha ez az élmény egy korszerű API mellett még jobb lenne. A többiek ehhez csatlakozhatnak.
Amúgy a shaderekkel nem videokódolást gyorsítasz, hanem post process szűrést. A dekódolásra ott az UVD motor.
A post process szűrést ellenőriztük a TMT5 szoftverrel, ahol OpenCL-ből alkalmaztunk HD felskálázást. Az OVD-vel ezt a fejlesztő a lejátszóba integrálhatja magába a futószalagba. Ez egyértelműen win számodra, mert javul a videó minősége. Ráadásul Open az egész, vagyis bárki támogathatja.
#27 Abu85 HÁZIGAZDA devast #25

Új Válasz 2011-04-11 16:08:23 #27
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz devast #25 üzenetére

Ez is univerzális, ráadásul nyílt. Pont azért lett meghúzva a képesség ilyen alacsony szinten, hogy a lehető legtöbb hardver támogassa, és a Khronos mielőbb fel tudja venni szabványba.
Ha meg nem támogatják a konkurensek, akkor az Intel és az NV magával szúr ki, mert ezzel az API-val teljesen hardveres futószalag építhető, mindenféle CPU-s bottleneck nélkül. Nyilván program is készül rá a Fusion Fund keretein belül. Az NV és az Intel vagy kínál hozzá drivert, vagy nézi, ahogy az AMD rendszerei több funkciót és jobb feldolgozást kínálnak az adott programok alatt. Igazából az AMD-nek rövidtávon mindkét opció jó. Hosszútávon a legjobb, ha felvetetik az OVD-t szabványba a Khronosszal.
Sejtettük, hogy Linuxra nem a DXVA lett megnyitva.
#24 Abu85 HÁZIGAZDA Pikari #23

Új Válasz 2011-04-11 15:49:58 #24
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Pikari #23 üzenetére

Nem éppen. Például a DirectCompute alatt eleve a shader modell 5 az ami értékelhető teljesítményt tesz lehetővé. A DXVA viszont nem támogatja a DirectCompute felületet. A legjobb shader modellből ezzel helyből kizártad magad. Persze a DXVA-t tovább lehet fejleszteni, hiszen az MS bármikor megteheti, csak addig amíg ez nem történik meg lenyeled a korlátokat, vagy váltasz egy másik API-ra, ami rugalmasabb. Pl.: a hírben szereplő.
#22 Abu85 HÁZIGAZDA devast #19

Új Válasz 2011-04-11 15:42:52 #22
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz devast #19 üzenetére

Ezen nem kell csodálkozni. DXVA-hoz az NV és az AMD a CL to D3D10 interop kiterjesztést használhatja. De azon belül is eléggé szenvedés a program megírása. Addig nehéz programot kérni, amíg egy értékelhető felület nem kerül le az asztalra.
A D3D és az OpenGL nem a legjobb felület post processingre. Az OpenCL és a DirectCompute képességei messze meghaladják a korlátozott shader modellek képességeit.
#17 Abu85 HÁZIGAZDA

Új Válasz 2011-04-11 15:31:46 #17
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

Ez a OpenVideo Decode API olyan, mint a DXVA (Windows), vagy a VDPAU (Linux).
Az AMD megoldásának annyi az előnye, hogy az OpenCL-re könnyen megoszthatók a pufferek. A DXVA esetében ez a rész borzalmasan nehézkes, és alapvetően korlátozott is.
Lényegében aki GPGPU-s szűrőket akar futtatni a lejátszójában, annak jelenleg az OpenVideo Decode API a legkényelmesebb megoldás. Emellett még nincs konkretizálva, de az AMD már mondta, hogy tárgyalnak az OVD Khronos specifikációba való felvételéről. Innen eredhet az első verzió úgymond korlátozása is, hogy a lehető legtöbb hardver támogassa.