PCTuning fórum

Ja ten rozdil chapu, presto to ale nic nemeni na realnem vyuziti obou reseni, jak u Cyrixu, tak u AMD je grafika vpodstate jen zobrazovadlo. OpenCL existuje hmm, 5 let? A kde jsou aplikace, nikde.

Jak jsem rikal, na prstech se daji spocitat. A stejne v nich OCL pohani jen par bezvyznamnych efektu, cili k nicemu.
http://www.tonymacx86.com/graphics/9348 ... -apps.html

Stejně tak (ne)reálné využití je u FMA či AVX. To však nic nemění na tom, že je v nových procesorech použít prostě můžeš , ale ve starých holt ne
Není vše pouze o OCL a CUDA, nezapomeň, že s Win7 přišlo také DC.

Sdílení pamětí a spopráce CPU a GPU na jediném aplikačním threadu, ala použití GPU částí pro operace na které je CPU část slabá, ala to co umožní až nadcházející HSA, u toho budu souhlasit s pojmeme "spolupracují na výpočtech". To se zatím u těch současných technologicky outdated APU neděje, tečka. Odlejvat specifické openCL výpočty na GPU neni to samé. To můžeš dělat na diskrétní GPU také, takže tam APU koncept ničim nebenefituje a je to poměrně latentní záležitost. Až nyní s nástupem HSA tu ta možnost bude. A takováto APU možná jednou mzěněj svět, ale ty llano/trinity/richland tlajdy opravdu ne a hodně rychle upoadno udo zapomění. Zastaralá VLIW architektura na kterou už nikdo nebude dělat drivery, neschopnost HSA, neschopnost jakejchkoliv benefitů z GPU na stejném DIE co CPU, to jest ten problém.

Hádáme se tady o kravinách ale já opravdu nevidim v 32nm AMD APU žádnou výhodu, naopak mi to už v době vydánbí připadalo jako zkostnatělé řešení, která asi bylo ve vývoji moc dlouho protože bylo zastaralé architekturou GPU. Bez GCN je to joke, GCN má úplně jinej GPGPU potenciál a na VLIW už sere pes teď, natož výhledově. Pro AMD, hlavně driver team, bude odchod těhlech APU z prodeje vysvobozením, protože konečně nebudou muset dělat drivery pro více naprosto rozdílnejch architektur GPU, už se budou moci soustředit jen na GCN based.

Takze, kdyz v pulce 2011 vyslo Llano s VLIW5 tak to byl zastaraly joke... Oni vzdycky musi mit 1 generaci skluz, kdyz verifikace CPU+GPU zabere delsi cas nez GPU. Kdyby tu misto Richlandu bylo v Q3 2013 puvodni Kaveri, tak by jim to vychazelo.

havli píše:Jak jsem rikal, na prstech se daji spocitat. A stejne v nich OCL pohani jen par bezvyznamnych efektu, cili k nicemu.
http://www.tonymacx86.com/graphics/9348 ... -apps.html

Tohle je snad vtip, ne? Proc sem tahat jablickare?

10min googleni: http://pastie.org/private/tebyxxl3snpc9t2mo2xpqq
Tohle by melo byt platform independent, cili zadna CUDA.

No dobre, tak misto peti je jich 50, to na veci nic nemeni. Az bude GPU akceleraci vyuzivat kazdej druhej program, bude to mit teprve smysl. Z toho seznamu obcas pouzivam CyberLink PowerDirector a ikdyz povolim GPU akceleraci, tak vytizeni grafiky je porad na nule. Cili to funguje presne podle predpokladu = vubec. Je to presne to samy jako byly kdysi k Radeonum X1800 SW na prevod videa, ktery se tvarily, ze jedou pres grafiku. Mno, akorat se tam nastavila horsi kvalita (aby to slapalo rychleji) a jelo se stejne pres CPU.

Vsechny tyhle advanced instrukce jsou dnesnim CPU platny asi jako SSE2 pro P4. Trvalo 10 let nez se zacaly psat aplikace vyzadujici SSE2, takze neocekavam prilisne zrychleni ani tady.

JJ, přesně tak, nulová akcelerace. Ty SW na video co rádoby používaj GPU nepoužívaj jeho výpočetní výkon ale jen jeho UVD jednotku k určitejm operacím. Nemusím snad 2x říkat že enkóding přes UVd je poměrně hnusnej a ačkoliv je video hotové rychleji, kvalita při srovnatelném bitrate je menší než přes CPU only. Takže to nepoužívám a dokud se toto nezmění nebudu.

5 a 50 je faktor 10. Nepodstatne. Ok

Kazda 2. aplikace z principu GPGPU pouzivat nemuze... Mam ted otevrene tyhle appky: Operu, Visual Studio, Winamp, cmd shell a Totalcmd. Jaka z nich obsahuje alespon nejakou podulohu vhodnou pro GPGPU? Opera ma HW akceleraci pres OGL. VS ma multithread build. Ani jedno neni vubec vhodne na GPGPU - masivni objemy dat zpracovatelne paralelne algoritmem, ktery neni nijak moc branchy a obecne neobsahuje moc synchronizace.

Edit: Jsem vůl!

Ocividne nezvladas porozumeni textu... Jeste jedou a tentokrat lepe.

Jo, už chápu, sorry.

tak hlavne OpenCL je len prvy level. AMD to chce dotlacit dalej tym ze sa bude pisat kod specialne pre CPU a potom GPU ako je to teraz. chcu dosiahnut aby jeden kod bezal automaticy tam kde je to najvhodnejsie. teraz sa pouzivaju rozne rozsirenia jazykov na multithreading ako napr OpenMP kedy sa pred for cyklus da a ten cyklus sa vykona na vsetkych jadrach. micorosft prisiel s C++AMP co ma umoznit akceleraciu pomocou DirectCompute. Ako backend ale moze sluzit aj OpenCL staci len aby bola dodana spravna podpora do prekladaca.

nikto sa ale zase nehrnie do pouzivania GPGPU pretoze je to zaprve stale dost obmedzene za druhe musia sa preskumat moznosti pouzitia a nakoniec rozsirenost HW medzi pouzivatelmi. nikto nebude vyvijat s technologiou ktoru ma len zlomok pouzivatelov. bude to rovnake ako s SSE instrukciami. ked sa prvykrat objavily tak bol tiez ich prinos mizivy a dnes sa proste pouzivaju. takisto aj o par rokov budu SW ktore bez GPGPU nespustite.

DOC: Ty tu pletieš piate cez deviate. Enkóding cez UVD samozrejme nie je možný, je to len dekodér. Prečo vlastne tak strašne trpíš tým, že APU a GPGPU musí byť použité na video enkóding aby ukázalo svoj zmysel? V prvom rade by si mal vedieť, že enkóding videa moderným kodekom ako je H264/x264 je prevážne sériový proces a ako taký nie je na nasadenie GPU vhodný. Keď kodeku osekáš funkcie, tak sa vhodným síce stane, ale prídeš o kvalitu. GPGPU sa dá preto v procese enkódingu použiť len ako doplnok (ako to robí napr handbrake, ale ešte som to netestoval, tuším sa jedná o resize a podobné filtre a lookahead), a to ťa výkonom nevytrhne.

Možno si si všimol, že Intel svojím quicksync vypálil rybník AMD aj Nvidii. Ale obaja sa už chytajú a zavádzajú do svojich GPU špeciálne obvody na enkóding (AMD má VCE a Nvidia má NVENC). Špeciálne obvody zas ale nemajú flexibiltu aby uspokojili náročných típkov ako si ty, alebo ja.

yuri.cs píše:5 a 50 je faktor 10. Nepodstatne. Ok

Kazda 2. aplikace z principu GPGPU pouzivat nemuze... Mam ted otevrene tyhle appky: Operu, Visual Studio, Winamp, cmd shell a Totalcmd. Jaka z nich obsahuje alespon nejakou podulohu vhodnou pro GPGPU? Opera ma HW akceleraci pres OGL. VS ma multithread build. Ani jedno neni vubec vhodne na GPGPU - masivni objemy dat zpracovatelne paralelne algoritmem, ktery neni nijak moc branchy a obecne neobsahuje moc synchronizace.

Ok, tohle jsem trochu prestrelil, presto ale porad plati (aspon pro me) nasledujici tvrzeni: Tam, kde me brzdi CPU (MP hry, enkoding videa, komprese vetsiho mnozstvi dat pro zalohy) mi GPU nepomuze. A u ostatnich cinnosti je mi to jedno.

Zkusil jsem ten winzip a vysledek prekvapive..... zadnej. Komprese asi 7GB bordelu trva bez OCL 6:30, s OCL je to 6:10. Pricemz to na grafiku ani nesahlo a jen se mirne zvysilo zatizeni CPU - proto tech 20s uspora, coz je zanedbatelny.
Za dalsi - chtel bych predelat kvanta ruznych divx/xvid filmu a serialu do H264, kde by zabraly jen polovinu mista. Na CPU to trva dost dlouho, coz takhle to zkusit pres GPU... Mediacoder + CUDA encoder sice jede rychle, ale kvalita je hrozna -> k nicemu. OK, nainstaloval jsem handbrake, grafiku ignoruje, protoze:

It appears OpenCL is only used for downsizing video ATM

Takze zase nic.
Nez se grafika v APU stane necim vic nez pouhym zobrazovadlem bude jeste dlooouho trvat.

ifkopifko píše:DOC: Ty tu pletieš piate cez deviate. Enkóding cez UVD samozrejme nie je možný, je to len dekodér. Prečo vlastne tak strašne trpíš tým, že APU a GPGPU musí byť použité na video enkóding aby ukázalo svoj zmysel? V prvom rade by si mal vedieť, že enkóding videa moderným kodekom ako je H264/x264 je prevážne sériový proces a ako taký nie je na nasadenie GPU vhodný. Keď kodeku osekáš funkcie, tak sa vhodným síce stane, ale prídeš o kvalitu. GPGPU sa dá preto v procese enkódingu použiť len ako doplnok (ako to robí napr handbrake, ale ešte som to netestoval, tuším sa jedná o resize a podobné filtre a lookahead), a to ťa výkonom nevytrhne.

Možno si si všimol, že Intel svojím quicksync vypálil rybník AMD aj Nvidii. Ale obaja sa už chytajú a zavádzajú do svojich GPU špeciálne obvody na enkóding (AMD má VCE a Nvidia má NVENC). Špeciálne obvody zas ale nemajú flexibiltu aby uspokojili náročných típkov ako si ty, alebo ja.

Ne nepletu a ty jsi mimo. UVD možná to první na GF8600 umělo jen dekóding, ale dnešní dovedou i enkódovat. Na nvidii tak funguje shadowplay, streaming na shiled, atd. Dělá to grafika a SP se při tom nezapojujou aby to nebrzdilo hru. Tak kde se to dělá? Někde v čtvrté dimenzi? Ne dělá to její UVD.

To o čem mluvíš ty je akcelerovanej enkóding kde jak říkáš se GPU používá jen na něco. Ale i když je to jen na něco, tak to stále bohužel má negativní dopad na kvalitu takže díky ne. Navíc je to dost závislé na nastavení. Občas to zrychlí 3x a GPu load při práci je 20% ale občas jen o 20% a GPu load jsou 4% protože jsem toho chtěl moc co se týče věcí kde GPU nemůže pomoci. GPu je prostě úzkoprofilovka vhodná jen pro omezenej typ kódu, prakticky žádnej běžnej SW a ani v tom enkódingu ji nelze použít obecně, jen na hodně málo vybranejch věcí. GPU nejsou univerzální v tu chvíli by z nich byly CPU.

DOC: Nie, nie som mimo. Bolo by dobré, keby si láskavo rozlišoval dekódovacie obvody (UVD/PureVideo) a špecializované enkódovacie obvody (VCE, NVENC). Práve NVENC prítomný až v Kepleroch sa stará o Shadowplay a streaming na Shield. Ako ty hovoríš... "tečka". Prečo asi tieto veci fungujú až s Kepler GPU?

To o čom hovorím ja, je niečo úplne iné ako hovoríš ty. Enkóding v H264/x264 nie je dobre paralelizovateľný. Preto naň nepoužiješ GPGPU. Že škáluje na viacjadrových CPU bez viditeľného dopadu na kvalitu je len preto, lebo majú zatiaľ pomerne málo jadier. Prečítaj si napríklad tu, čo píšu o parametri "threads": http://mewiki.project357.com/wiki/X264_Settings#threads

Inak ale pri úprave videa môžeš použiť GPGPU na veci, ktoré sú dobre paralelizovateľné, a to bez straty kvality. V kvalitnom video enkódingu je to minorita z pohľadu náročnosti, preto malý nárast výkonu. Tam, kde dosahuješ násobné zrýchlenie už spravidla došlo ku kompromisom v kvalite, aby sa GPGPU zapojilo aj inde. Skrátka bol taký trend, aby si developer softwaru mohol napísať pekné čísla do reklamy. GPU momentálne nemajú problém s univerzalitou, ale s tým, že niečo sa skrátka nedá dobre paralelizovať. Malý prínos v enkódingu videa je preto, čo som napísal vyššie.

havli píše:Za dalsi - chtel bych predelat kvanta ruznych divx/xvid filmu a serialu do H264, kde by zabraly jen polovinu mista. Na CPU to trva dost dlouho, coz takhle to zkusit pres GPU... Mediacoder + CUDA encoder sice jede rychle, ale kvalita je hrozna -> k nicemu. OK, nainstaloval jsem handbrake, grafiku ignoruje, protoze:

It appears OpenCL is only used for downsizing video ATM

Takze zase nic.

Síce to cez CPU trvá dlho, ale veď enkóding videa môžeš púšťať na pozadí s nízkou prioritou (napr. Handbrake, StaxRip) a PC bude normálne použiteľný... teda, na hry to s mojím C2D vtedy nie je, ale možno modernejšie stroje by to dali, to neviem. Ja to tak robím. Prípadne nastaviť afinitu jadier, alebo to púšťať len cez noc. Možnosti tu sú ako sa popasovať s problémom času. Zbytočne čakáš na akceleráciu. Jediná možnosť je, že by niekto uviedol špecializované enkódovacie obvody, ktoré by podporovali nastavenie/parametre súhlasné práve s tvojími kvalitatívnymi požiadavkami. Malá šanca, lebo výkonový nárast by už zrejme nebol taký oslnivý. Pamätám si na starší test akcelerovaného enkódingu z časov prvého QuickSyncu, ten bol síce rýchly a Intel sa chvástal snáď 10-20x rýchlosťou, ale v porovnaní so SW cestou, nastavenou aby vyprodukovala porovnateľnú kvalitu to už bolo snáď len o cca 50% rýchlejšie... pravda, s použitím silného CPU i7-2600K. Snáď si to pamätám dobre.

Jo, fajn, OK chápu.

Co se týče dělání víc věcí najednou, na Core2 je to problém kvůli FSB a nízké prostupnosti. Ala něco vytíží prostupnost tak systém je celej zahlcenej. Od Nehalemu ale naprosto OK. Stačí nastavit priority a programy s high budou bržděný naprosto minimálně.

Musí se ale vypnout HT, jinak si win myslej že maj 8 CPU a hoděj to na ty HT jádra a jsme v háji. U AMD FX to samé, sdílenej front end tomu nedělá dobře a při využití celejch modulů naplno je systém slimák jak s HT. Někdo mi tu říkal, že WIN8 tento problém řeší, už dovednou rozlišovat dobře mezi reálnými a HT thready a ty priority tam fungujou i když se HT nechá zapnutý, to jsem ale nezkoušel. Nicméně budu jako vždy raději skeptický a držet se toho že sheduler u win suxx a citelně se nezlepšil od windows 2000.

http://www.gamersnexus.net/news/1240-fu ... fx-not-eol

To je galimatyáš...Nemyslím si, že původní roadmapa je fake, ale že se jedná spíše o jednu z podčástí oficiálních roadmap. Možná v AMD nevědí ani někteří co vlastně bude/nebude.

Moje teze ale je, že se příští rok ničeho smysluplného v FX nedočkáme, že se bude jednat jen a pouze o Vishery (kdyby alespon nová revize...) a šance/vidina je až rok 2015 a 20nm proces pro nějakou výraznější změnu nadšeneckých procesorů FX.

Nema vyznam na takovehle servery chodit.

Ta roadmapa neni fake a pochazi z 'AMD Q3 2013 Desktop Product Update' dokumentu, ktery obsahuje haldu slidu z APU13 a take tuhle roadmapu.
http://abload.de/img/900x900px-ll-081c2d8e6voxg.png

Je ale sranda, že pokud vlastní zaměstnanec, celkem i vyšší funkce nepozná vlastní roadmapu, je to tragikomické . Proč probůh nevyčlení třeba tým 50 lidí, co by se věnovalim komunikaci s médii, dělali marketing po netu a měli zároveň přehled o produktech? No, stačilo by možná i těch 20...

I kdyby to tam delal jen jeden clovek tak by v tom nemeli taky bordel . Oni ale asi nemaji nikoho.
Nj - HigEnd AMD CPU tu snami par let nebudou . ALe tak dlouha mezera ? But to zrusili uplne nebo zacinaji zase skoro od znova.