meg itt sincs az elso, de mar nyuzzak a kovetkezot
hüllő
meg itt sincs az elso, de mar nyuzzak a kovetkezot
hüllő
Azt megnézném, hogy hol erősebb a 4xxx szériánál. 128 shader processzorával, 500 MHz-es órajelével a leggyengébb 4xxx-es GPU-t, a 4350/4550-et valóban üti, a többit nem valószínű. Annak meg 64 bites memóriavezérlője van.
Illetve, ha jól értettem a fusion APU felépítését, bizonyom az IGP-ben van egy hardveres videólejátszó rész, és a textúrázokat, és skalár procikat csak a post-processre használja. (Lehet én értettem félre)
Te érted félre, az AMD jelenleg is a shadereket használja dekódolásra, csak az Intel olyan hülye (ill. nem hülye, csak üzletpolitikai döntés), hogy hardveres videokódolót tegyen a procijába, ami egyébként kb. ugyanaz a hardver, csak a szoftver más.
Az UVD dedikált hardware (a lapkára integrálva). Enkódolásra használják a shadertömböket. Illetve, talán transzkódoláskor használják dekódolásra is őket, ha az UVD kimenete nem érhető el további feldolgotásra, de miért ne lehetne elérhető?
[ Szerkesztve ]
Az UVD nem végzi el az egész dekódolást, csak a videodekódolás egy kis részét (a bitstream dekódolást és az inverz frekvencia transzformációt, talán még a mozgáskompenzációt is, bár szerintem az már simán párhuzamosítható), viszont a munka kb. 95%-99%-át (deblock szűrő, deinterlance, denoise, színtér konverzió, stb.) már a shaderek végzik.
Kicsit félreértesz, ez valószínű a gondolkodásom, illetve a fogalmazásomnak tudható be. Az aláhúzott idézet azért lett olyan, hogy megkülönböztessem, hogy máshonnan idéztem. Igen, volt olyan amiben igazad van, de szerintem írtam is. Vagy csak akartam?
Félreérthető, megjelenésekor bizony nagyon sok előnye származott az AMD-nek az IMC-ből, és az intelnek 3évbe tellett, mire utolérte, viszont a cikk a K10-es architektúra bemutatkozásakor íródott, és kb akkor már jelen volt a core-i széria is, ami nem most volt...
A fusion APU meg k8 alapokra építkezik, és etetnie kell ennek az IMC-nek még egy IGP-t is, ezért tartom szűkösnek ezt a 64 bites megoldást. Persze előny is származik abból, hogy a CPU magok és az IGP között nem kell a "lassú" rendszerbuszt (HT-linket) használni, ez sokat gyorsít, különben nem integrálnák... De akkor is kevés az a 64 bit, ha a CPU-t meg a GPU-t is kell etetni egyszerre.
A core architektúra az utasításkészlete, illetve jobb felépítése miatt verte el az AMD-t ha nem is sokkal, az IMC-t a jobb előbehívó algoritmussal (nagyobb asszociatívításával), és a nagyobb L2-vel kompenzálta. Aztán a fogyasztásban meg a gyártástechnológiai előny miatt nyert. De én nem ezekről szeretnék beszélni.
Szimplán arra szerettem volna rávilágítani, hogy egy 64 bitesnél szélesebb IMC-vel gyorsabb lehetne a fusionAPU, és mivel a DDR3 már nem igazán fogyaszt sokat, főleg ha az 1.5Vos ramokat nézed, nem biztos hogy akkor érvágást eredményezne.
Ha tippelnem kéne a nagyon alacsony fogyasztásu rendszerekben lesz egycsatornás az IMC, és ahol meg kicsit nagyobb teljesítmény kell, ott pedig hadrendbe állítják/állíthatják a DC által nyújtott többletet. Lehet nem akarnak minden puskaport elsőre ellőni.
(#52) LordX: Te meg abszolút benéztél valamit. Én integrált IGP-kről beszéltem végig, nem dedikált videókártyákról. IGP!=GPU
"Értem én, hogy nem egy 69xx kártya az IGP, de bizony a 4xxx IGP szériánál erősebb, azon pedig az alacsonyabb késleltetés miatt rengeteget dobott a sideport -a 3xxx IGP-nél szintén."
Olvasás egyes, ülj le.
Remélem érted a tréfát.
Persze ha megjelenik, akkor mindenre fény derül, és nem kell találgatni.
Nem tudom, én elolvastam a hsz-eket és teljesen érthetőnek találom amit írtam, mégis félreértelmeztetek. Remélem most már világos, hogy mit akartam mondani.
[ Szerkesztve ]
Válaszolj a privátra!!! Elég annyi is, hogy szarok rá(d)...
Mindent az UVD csinál, kivéve a post-processinget, ami éppen hogy a munka kisebb része.
Akkor ezt jól értettem, csak abban tévedtem, hogy az UVD1, illetve UVD2 is tartalmazott már speciál hardver részt. Bár így utólag belegondolva logikus a dolog, hisz akkor ha a shaderek dolgoznának, akkor a powerplay nem tudná jelentősen levenni az órajeleket. Néha lusta vagyok utánaolvasni mindennek, és a kicsit homályos emlékeimre hagyatkozom.
Válaszolj a privátra!!! Elég annyi is, hogy szarok rá(d)...
"A fusion APU meg k8 alapokra építkezik"
Egyrészt, ez így helytelen, mert a Llano K10.5 alapokra építkezik. A Zacate/Ontario Bobcat magja a butított K8 (kb.). Az IMC-t szintén nem csak úgy copy-paste-zték egy régebbi tervből.
"De akkor is kevés az a 64 bit, ha a CPU-t meg a GPU-t is kell etetni egyszerre."
Itt az a kérdés, hogy mire és megérné-e összességében egy relatave kisteljesítményű, kisfogyasztású és nem utolsó sorban kisméretű platformnál a dual-channel (amivel már nem is lenne kisméretű). Jó lenne arról egy link, hogy a 3xxx és 4xxx IGP-ken "rengeteget dobott" a (32-bites) sideport, mert én sem így emlékszem.
Mint már szó volt róla, a nagyobb CPU és IGP teljesítményű, fogyasztásilag és méretileg kevésbé korlátozott Llanonál ott van a dual-channel.
"és a nagyobb L2-vel kompenzálta. Aztán a fogyasztásban meg a gyártástechnológiai előny miatt nyert."
A nagyobb L2-t is a gyártástech. előny tette lehetővé. Ezt magyarázom.
Néha kiragadsz egy-egy olyan részt a hsz-emből, amit "trehányan" fogalmaztam meg, és nem érted mit akarok mondani. Nem látod a fától az erdőt. Persze mielőtt megint félreértenél köszönöm, hogy felhívod rá a figyelmem és helyesbítesz. Ezt kértem is ha valamit rosszul írnék, de azért ne értsd félre amit mondani akarok.
Akkor ugyanarról akarjuk meggyőzni a másikat kb.
Akkor mindketten üljünk le a magyar egyesünkel.
[ Szerkesztve ]
Válaszolj a privátra!!! Elég annyi is, hogy szarok rá(d)...
Mit értettem félre?
Az meg egy másik dolog, hogy ha egy hsz-re reagálok, hát csak nem hagyom szó nélkül az egyéb tévedéseket. (Tudod, ez egy fórum, ahol a leírtakat egyesek hajlamosak készpénznek venni.)
Ez egyáltalán nem igaz, a post-processz az H.264 esetén kötelező, és pont hogy a munka legnagyobb része.
Nem tudom, honnan veszed ezt az információt, de használtál te már szoftveres H.264 dekódert? FFDShow, CoreAVC? Vagy a korai GPU-k dekóder blokkjait? Mert akkor tudnád, hogy a munka legnagyobb része (CPU-terhelés tekintetében) a frequency transform+pixel prediction, ezután jön a bitstream decoding (ezeket eddig az UVD és a PureVideo végzi, az in-loop deblockiggal együtt, ami "nem sok vizet zavar"). A post-processként végzett deblockingot és deringinget ki-be kapcsolgatva alig változik a proci-terhelés és a kép sem túl látványosan. (Az FFDShowban pl. default off.)
A PC-s dekóderekbe épített post-processingnek legtöbbször nem része a deinterlace és a denoise (utóbbi pl. eltüntetné a film-graint), a resize-t és a színtér-konverziót pedig a video renderer végzi (megjelenítő felülettől és beállításoktól függően sw/hw/shader).
[ Szerkesztve ]
"A PC-s dekóderekbe épített post-processingnek legtöbbször nem része"
Viszont az AMD dekóderének része, deinterlace-el együtt, ami a legizmosabb az összes postprocessz között.
"Viszont az AMD dekóderének része"
Mi? A színtérkonverzió és a resize sem része, mint írtam, ezeket már a video renderer kezeli (bár beékelhető a kettő közé egy resize filter), beállításoktól függően sw/hw/shader alapon. (Egyes más dekóderek tudnak opcionálisan színtérkonverziót, de legtöbbször nem ők végzik.)
"deinterlace-el együtt"
Az sem a része, hanem ez egy a driver által vezérelt művelet, ami többféle dekóderrel is működik.
"ami a legizmosabb az összes postprocessz között."
Csak éppen nem állandó feladat, pl. egy mozifilmes H.264 streamnél sem deinterlacingre, sem denoise-ra nincs szükség. De ha adott esetben mégis (pl. deinterlacingre egy 1080i-s DVB-x streamnél [mert pl. monitoron nézzük vagy nem akarjuk a tévére bízni], vagy a denoise-ra pl. egy VHS-ről digizett anyagnál), ezekkel együtt sem lesz 20x-100x annyi meló (a 95-99%-odból kiindulva) a post-process, mint a dekódolás. Továbbra sem értem, honnan vetted ezeket a százalékokat...
(A video renderer lehet a system default [quartz.dll], vagy pl. a MadVR.)
Banyeg. Az AMD dekóderének ez mind fícsörje. Nyisd meg a Catalyst beállításokat, és mind tudod állítani.
egy mozifilmes H.264 streamnél sem deinterlacingre, sem denoise-ra nincs szükség.
Amazon.com, Blu-Ray szekció, 1080p keresés: 448 találat, 1080i (de nem 1080p) keresés: 316 találat. Ha relevánsnak vesszük az arányokat (és miért is ne, a világ legnagyobb kiskereskedéséről beszélünk) csak a Blu-Ray filmek 40%-ában VAN szükség deinterlace-re..
"Az AMD dekóderének ez mind fícsörje."
Tudomásom szerint nem az "ATI MPEG Video Decoder" filter része, hanem a teljes videókezelési lánc része. Ha van konkrét infód az ellenkezőjéről, jöhet.
"Nyisd meg a Catalyst beállításokat, és mind tudod állítani."
Az, hogy tudom állítani, miközben másféle dekóder filtereket használok, szerinted mire vall..? (Az Edge Enhancmenthez és De-noise-hoz úgy tűnik, kell valamilyen közbülső filter, vagy ezek nem minden videófelületen működnek.) Megjegyzem, akadnak kompatibilitási gondok.
Technikai statisztikázásra inkább ezt az oldalt ajánlanám: [link]
A 3577 Blu-ray kiadvány közül 322 1080i-s (ezek nagyrészt videós/tévés forrásúak), ami 9%, a többi a mozifilmeknek megfelelő 24p/23.976p-s.