[_Geri_]

Telcontar: ez egy nagyon rossz példa volt a véleményem szerint, ugyanis a codekek oroszlánrésze köszönõviszonyban sincs a floatokkal, hisz egy RGB egész hármason alapuló technológiának ilyesmi természetesen abszolút nem kell, persze akadhatnak kivételek, de ettõl még a videólejátszás idevonatkoztatása eléggé rossz dolog. A videó (de)kódolás egy tipikusan olyan folyamat, ahol számhármasokkal, számnégyesekkel kell dolgozni, ahhoz pedig MMX és egész számok kellenek de marhamód, nem pedig lebegõpontos számok. Épp emiatt a Cyrix processzorok gyengeségét nem lehet kizárólag az FPU gyengeségére fogni, sõt, egyáltalán nem, hisz az FPU sebessége egy bizonyos szint felett egy vegyes, átlagos bonyolultságú alkalmazást gyakorlatilag csak nagyon lagymatag mértékben gyorsít. A Cyrixnek egymillió más problémája is volt, amik azt a lassú videólejátszást eredményezték.
Hogy példának okáért modjak párat, ami a videódekódoláshoz kell: jó hatásfokú utasításbecslés, nagy memóriasávszélesség, MMX, marha mód gyors stack mûveletek, marha gyors jump és return, JÓL MEGÍRT CODEC...

És mégegyszer, ami nem kell hozzá: spéci FPU.

[akosf]

Idézet: Telcontar - Dátum: 2009. febr. 2., hétfõ - 22:56

A folyamat eredményét jól jellemzi, hogy pl. a PowerDVD megnemmondom hányas változatának hivatalos hardverigénye min. 400 MHz-es Celeron, vagy bármilyen K7 alapú processzor. És tényleg: egy 400-as Celkával meg lehet nézni egy DVD filmet hardveres dekóder nélkül is (csak ne fusson semmi felesleges szolgáltatás a háttérben), de ugyanaz a film nem képes röccenés nélkül futni a K6-oson (én egy K6/2+-550-esen próbáltam), semmilyen szoftveres beállítással, trükkel sem.

Valószínûleg a PowerDVD 5-ös lesz az. CyberLink PowerDVD 5 System Requirements

Ha lesz idõm, utánanézek ennek is. Úgy gondolom hogy a 400-as Celeron és az 550-es K6-2+ közel azonos teljesítményû processzorok, így érdekel a dolog hogy mégis min hasal el a K6-os.

[Telcontar]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 1:31

Telcontar: ez egy nagyon rossz példa volt a véleményem szerint, ugyanis a codekek oroszlánrésze köszönõviszonyban sincs a floatokkal, hisz egy RGB egész hármason alapuló technológiának ilyesmi természetesen abszolút nem kell, persze akadhatnak kivételek, de ettõl még a videólejátszás idevonatkoztatása eléggé rossz dolog. A videó (de)kódolás egy tipikusan olyan folyamat, ahol számhármasokkal, számnégyesekkel kell dolgozni, ahhoz pedig MMX és egész számok kellenek de marhamód, nem pedig lebegõpontos számok. Épp emiatt a Cyrix processzorok gyengeségét nem lehet kizárólag az FPU gyengeségére fogni, sõt, egyáltalán nem, hisz az FPU sebessége egy bizonyos szint felett egy vegyes, átlagos bonyolultságú alkalmazást gyakorlatilag csak nagyon lagymatag mértékben gyorsít. A Cyrixnek egymillió más problémája is volt, amik azt a lassú videólejátszást eredményezték.
Hogy példának okáért modjak párat, ami a videódekódoláshoz kell: jó hatásfokú utasításbecslés, nagy memóriasávszélesség, MMX, marha mód gyors stack mûveletek, marha gyors jump és return, JÓL MEGÍRT CODEC...

És mégegyszer, ami nem kell hozzá: spéci FPU.

Jó.

Akkor csak azt nem értem, hogy egy 66 MHz-es FSB-vel szaladgáló 400 MHz-es Celeron miként tudja megverni dekódolásban a 100 MHz-es FSB-vel hasító K6/2+-550-est. Ennyivel gyengébb lenne a K6-os elágazásbecslése? Vagy hiába a magasabb FSB, a memóriasávszélesség mégis kevesebb? A gyengébb MMX utasításvégrehajtás talán nem jön szóba, hiszen a K6/2-eseknek két MMX-végrehajtó egységük van.

[_Geri_]

Én sem tudom, a legjobb lenne lemérni. Ami miatt biztos hogy nem, az az fpu.
Ha gondolod, írhatok pár, bizonyos specifikus részegységekre rátehénkedõ sebességmérõ tesztet, amit aztán ráereszthetünk több processzorra, és megvizsgálhatjuk, melyik feladatot melyik processzor milyen sebességgel teljesíti. Már csak ki kellene találni, hogy mik legyenek ezek a feladatok, és találni kellene valakit, aki végigfuttatja vagy 10-20 processzoron õket, majd az eredményeket idemásolja.

[Valdy]

Idézet

Hardware Information:
  Processor: AMD Athlon™ 64 X2 Dual Core Processor 4000+ running at 1189 MHz
  3DNow! technology:  In Use
  Enhanced 3DNow! technology:  In Use
  3DNow! professional technology:  In Use
  IA MMX technology:  In Use
  IA sStreaming SIMD extensions:  In Use
  IA SSE 2:  In Use
  Video accelerator:  DirectX VA (not in use)
  Multispeaker audio device:  Creative SB Audigy (not in use)
  S/PDIF output device:  SB Audigy Audio [AC00] (not in use)

Ki kéne próbálni, hogy újabb powerdvd-vel (ami támogatja ezeket az utasításkészleteket) hogy viselkedik k6 alatt, hardveres mpeg2 gyorsítás nélkül.
Bár k6-nál nyilván csak a 3dnow, enhanced 3dnow (k6+ esetén) és az mmx jöhet szóba.

Szerkesztette: Valdy 2009. 02. 03. 18:40 -kor

[akosf]

Idézet: Telcontar - Dátum: 2009. febr. 3., kedd - 19:00

Vagy hiába a magasabb FSB, a memóriasávszélesség mégis kevesebb?

Gyorsan belenéztem az Everest beépített eredményeibe.
Memória olvasás:
Celeron 266MHz: 360MB/mp PC66 SDRAM 3-2-2-5
K6-2 333MHz: 150MB/mp PC66 SDRAM 3-3-3-6

Valamint még megjegyezném hogy az Intel processzorok rendszeresen jobbak az elágazásbecslésben és általában az MMX utasítások végrehajtásában is.

Szerkesztette: akosf 2009. 02. 03. 18:45 -kor

[_Geri_]

No igen, ez a másik tévhit, hogy az emberek azt hiszik hogy a memóriaolvasás sebessége az minden processzor számára megegyezik az fsb bizonyos konstans szorosával, holott ez nagyon nem így van. Az olvasás sokkal erõsebben függ attól, hogy a processzor egy memóriaszelet olvasásakor hány várakozó órajelet kénytelen eltölteni, mire a kívánt adatok megérkeznek. És ez nem 1-2 órajel, hanem platformtól, processzortól függõen lehet akár 400-1500 is.

Szerkesztette: _Geri_ 2009. 02. 03. 18:47 -kor

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 19:47

No igen, ez a másik tévhit, hogy az emberek azt hiszik hogy a memóriaolvasás sebessége az minden processzor számára megegyezik az fsb bizonyos konstans szorosával, holott ez nagyon nem így van. Az olvasás sokkal erõsebben függ attól, hogy a processzor egy memóriaszelet olvasásakor hány várakozó órajelet kénytelen eltölteni, mire a kívánt adatok megérkeznek. És ez nem 1-2 órajel, hanem platformtól, processzortól függõen lehet akár 400-1500 is.

Már csak az a kérdés hogy videodekódolásnál miért van szükség nagy memóriasávszélességre. Mondjuk egy képkocka 2MB-nyi adat írását igényli, akkor 25fps mellett ez 50MB/s. Ez azt jelenti hogy csak a kész képkockák videomemóriába juttatása 20-25%-ban is felemésztheti egy K6-2-550 erõforrásait. Ez jó hipotézisnek tûnik, nem?

[_Geri_]

Nem, ez nem így mûködik. Az, hogy egy 2 megabájtos kockát te 25 fps-en ki tudd tolni, nem 50 megabájt sávszélesség szûkséges, hanem legalább 500. Nem szorozni kell, a programok nem így mûködnek
Egy videó dekódoláshoz elõször a nyers adatokat át kell másolni a DMA-n keresztül egy központi tárolóba, dekódolni kell ezeket az adatokat gyakran úgy, hogy az elõzõ frame vagy kulcsframe alapján kell bizonyos számításokat elvégezni, ezek röviden azt jelentik, hogy azon az ominózus 2 megabájtos kockán legalább 8x átméssz teljesen, mire odajutsz, hogy a driver DMA-n keresztül ismét csak mirrorozzon és strameljen rajta egy szépet.

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 20:00

Nem, ez nem így mûködik. Az, hogy egy 2 megabájtos kockát te 25 fps-en ki tudd tolni, nem 50 megabájt sávszélesség szûkséges, hanem legalább 500. Nem szorozni kell, a programok nem így mûködnek
Egy videó dekódoláshoz elõször a nyers adatokat át kell másolni a DMA-n keresztül egy központi tárolóba, dekódolni kell ezeket az adatokat gyakran úgy, hogy az elõzõ frame vagy kulcsframe alapján kell bizonyos számításokat elvégezni, ezek röviden azt jelentik, hogy azon az ominózus 2 megabájtos kockán legalább 8x átméssz teljesen, mire odajutsz, hogy a driver DMA-n keresztül ismét csak mirrorozzon és strameljen rajta egy szépet.

Úgy látszik csak elolvastad amit írtam, de dekódolnod nem sikerült. 

Nem arról beszéltem hogy mekkora sávszélesség igénye van egy dekódernek, hanem csak arról hogy a kész adatok videomemóriába írása mennyi idõbe telik.

[_Geri_]

Kezdjük ott, hogy mivel a számítógépek DMA vezérlõáramköröket és IOMMU-t használnak, a processzor szempontjából egyetlen árva ezredmásodpercbe sem.

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 20:11

Kezdjük ott, hogy mivel a számítógépek DMA vezérlõáramköröket és IOMMU-t használnak, a processzor szempontjából egyetlen árva ezredmásodpercbe sem.

Nem kívánok se vége se hossza típusú vitába bocsájtkozni, nekem erre nincs energiám.
Mindenesetre egy jót nevettem az "idealizmusodon".

[_Geri_]

Ha esetleg tisztában lennél, hogy milyen hardveres részegységek végzik az ilyen jellegû feladatokat, nem beszélnél zöldségeket

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 20:21

Ha esetleg tisztában lennél, hogy milyen hardveres részegységek végzik az ilyen jellegû feladatokat, nem beszélnél zöldségeket

Azt elfelejtetted hozzáírni hogy természetesen Te vagy az egyetlen ember a Földön aki érthet hozzá.

[_Geri_]

Nem, de fel a kezeket, kettõnk közül melyikünk írt már videólejátszót és dekódert 80286osra

[djculture]

Idézet: Valdy - Dátum: 2009. febr. 3., kedd - 18:39

Ki kéne próbálni, hogy újabb powerdvd-vel (ami támogatja ezeket az utasításkészleteket) hogy viselkedik k6 alatt, hardveres mpeg2 gyorsítás nélkül.
Bár k6-nál nyilván csak a 3dnow, enhanced 3dnow (k6+ esetén) és az mmx jöhet szóba.

sse nem volt a elsõ athlonokba se,nekem sincs az 1000tb be

[_Geri_]

Egészpontosan a Thunderbird széria az, amiben még nincs SSE, az meg emlékeim szerint 1400 mhz-ig skálázódik. Ha egy kis bennfentes infót akartok hallani - az ezt követõ Athlonokban sincs SSE igazából - 3dnow!-al emulálja a processzor feldolgozóegysége az SSE kódokat, és az SSE támogatást szoftveresen le is lehet akár kapcsoni.

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 20:26

Nem, de fel a kezeket, kettõnk közül melyikünk írt már videólejátszót és dekódert 80286osra

FLC lejátszó is megteszi? Akkor jelentkeznék én is...

[_Geri_]

Elfogadom, mert ilyen jó szívem van

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 20:39

Egészpontosan a Thunderbird széria az, amiben még nincs SSE, az meg emlékeim szerint 1400 mhz-ig skálázódik. Ha egy kis bennfentes infót akartok hallani - az ezt követõ Athlonokban sincs SSE igazából - 3dnow!-al emulálja a processzor feldolgozóegysége az SSE kódokat, és az SSE támogatást szoftveresen le is lehet akár kapcsoni.

Ez érdekes, még nem hallottam róla. De szerintem könnyû kideríteni hogy valóban a 3DNow! egység emulálja-e az SSE egységet vagy sem. Ugyanis a reciprokképzés az AMD féle 3DNow! elõírása ( AMD 3DNow! Technology Manual ) alapján 14 bit pontosságú, míg az Intel féle SSE szerint a relatív hiba nem lehet  nagyobb 1,5*2^-12-nél ( kb. 12,35 bit pontosság ). Vagyis ha emuláció, akkor 14 bites pontosságú eredményt kapnánk SSE kóddal is. ( PFRCP vs. RCPSS )

szerk.: Ami természetesen elfogadható, hisz a 14 bites eredmény "belefér" a 12,5 bitesbe.

Szerkesztette: akosf 2009. 02. 03. 20:08 -kor