Hirdetés

2024. május 2., csütörtök

Gyorskeresés

Hozzászólások

(#51) gyiku


gyiku
nagyúr

meg itt sincs az elso, de mar nyuzzak a kovetkezot :R

hüllő

(#52) LordX válasza GerykO (#47) üzenetére


LordX
veterán

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.

(#53) dezz válasza LordX (#52) üzenetére


dezz
nagyúr

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 ]

(#54) LordX válasza dezz (#53) üzenetére


LordX
veterán

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.

(#55) GerykO válasza dezz (#50) üzenetére


GerykO
aktív tag

Kicsit félreértesz, ez valószínű a gondolkodásom, illetve a fogalmazásomnak tudható be. :B 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? :B
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. :U
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. :U :C

(#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. :P ;]
Remélem érted a tréfát. :B

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. :R

[ Szerkesztve ]

Válaszolj a privátra!!! Elég annyi is, hogy szarok rá(d)...

(#56) dezz válasza LordX (#54) üzenetére


dezz
nagyúr

Mindent az UVD csinál, kivéve a post-processinget, ami éppen hogy a munka kisebb része.

(#57) GerykO válasza dezz (#56) üzenetére


GerykO
aktív tag

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. :B

Válaszolj a privátra!!! Elég annyi is, hogy szarok rá(d)...

(#58) dezz


dezz
nagyúr

"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. ;)

(#59) GerykO válasza dezz (#58) üzenetére


GerykO
aktív tag

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. :DD
Akkor mindketten üljünk le a magyar egyesünkel. :C

[ Szerkesztve ]

Válaszolj a privátra!!! Elég annyi is, hogy szarok rá(d)...

(#60) dezz válasza GerykO (#59) üzenetére


dezz
nagyúr

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.)

(#61) LordX válasza dezz (#56) üzenetére


LordX
veterán

Ez egyáltalán nem igaz, a post-processz az H.264 esetén kötelező, és pont hogy a munka legnagyobb része.

(#62) dezz válasza LordX (#61) üzenetére


dezz
nagyúr

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 ]

(#63) LordX válasza dezz (#62) üzenetére


LordX
veterán

"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.

(#64) dezz válasza LordX (#63) üzenetére


dezz
nagyúr

"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...

(#65) dezz válasza dezz (#64) üzenetére


dezz
nagyúr

(A video renderer lehet a system default [quartz.dll], vagy pl. a MadVR.)

(#66) LordX válasza dezz (#64) üzenetére


LordX
veterán

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..

(#67) dezz válasza LordX (#66) üzenetére


dezz
nagyúr

"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.

Copyright © 2000-2024 PROHARDVER Informatikai Kft.