Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Ennek az Intel nem örül, hogy idő előtt kikerült pár termék. Eleve a mai napon van az Ivy rendezvénye, ahol bemutatják, és elmondják, hogy mi mikor startol, de ez a cikkben már le van írva (Jim dátumai jók. Több gyártó is megerősítette.). A hivatalos NDA is később jár le.
David Kanter már mondta, hogy a gyártással van gond. Ezért jelentették be hivatalosan is a csúszást. Ez nem meglepő. Új gyártástechnológiánál nem mindig úgy alakul a felfuttatás, ahogy azt eredetileg várják. Az Intel is meghatározott egy minimum kihozatalt, ami mellett úgy gondolják, hogy ki tudják szolgálni az igényeket. -
Jack@l
veterán
Itt azért szó nincs erről, elvileg holnap már lehet is értemenni, én csak örülök ennek. Sőt sztem a -végre rendes procira vágyóknak- is jobb ez hogy előbb (időben) kikerültek, csak járjon erre még több kamion is.
Gyártással úgytom nincs gondjuk, csak az a fránya pénzsóvárság ami visszatartja a kiadást. -
Abu85
HÁZIGAZDA
válasz
zoleeno1
#179
üzenetére
Becsomagolt Ivy Bridge-et. Valszeg ezek már kiadásra jelölt verziók, legalábbis meglepne, ha nem azok lennének. A termékkel tudtommal nincs gond a gyártástechnológia felfuttatása halad lassabban a vártnál. Ez több selejtarányt eredményez. Nem nagy gond, de annyira elég, hogy csússzon egy picit a start. Azt tartom valószínűnek még, hogy ez nem jutott el mindenkihez, és elkezdték forgalmazni a már kész termékeket. Az eredeti start március vége, vagyis már küldözgetni kellene a holmikat az egyes országokba. Akik pedig kaptak értesítést, azok lelőtték a kiszállítást.
-
-
zoleeno1
veterán
Nem tudom ez hogy lehetséges, mert semmi hír nem jött róla, de iponban (más kiskernél sehol nem látom még) rendelhető 3db Ivy is, raktáron van és a ma leadott rendeléseket holnapra teljesítik. Megerősítették e-mailben, én azt hittem ez csak valami adatbázis hiba lehet, de nem
konkrétan ezekről van szó:
INTEL Core i7-3770 3.40GHz 1155 BOX
INTEL Core i5-3550 3.30GHz 1155 BOX
INTEL Core i5-3450 3.10GHz 1155 BOX -
Abu85
HÁZIGAZDA
-
lenox
veterán
Egy HD kep 2 millio pixel, 24 fps-sel az kb. 50 millio pixel masodpercenkent. 200 MHz-en a Brazos 80 stream procija pixelenkent 320 muveletet tud vegezni. Egy jofele lanczos scaling ebbol egy parszor kijon, szoval nem hinnem, hogy ettol akadna, vagy akkor valami nem mukodik optimalisan.
-
Abu85
HÁZIGAZDA
A számítási teljesítmény az nem mindegy. Ha 200 MHz alá viszed a Brazos IGP órajelét, akkor már akadozgat. Ilyen Brazos nincs, mert 275 MHz a minimum, de mesterségesen ezt le lehet vinni 150-re. A bandwith az elég neki, már amit a mai mobil memóriák kínálnak ... DDR3 1066 MHz 64 biten.
Sajnos ezen a szinten túl nagy összehasonlítási alap nincs. Az Atom buta, míg az Iont nem gyártják már. De az Ion 1-gyel nem volt gond, amikor teszteltük. -
lenox
veterán
Szerencsére nem. Elég jól elvan például a SimHD egy Brazos-on, vagy egy kisebb minimalisztikus GPU-n. Pedig az algoritmus ugyanaz.
Mi az, ami szerencsere nem? Nem a bandwidth a bottleneck? Hanem mi? Marmint ha a szamitasi teljesitmeny mindegy, abbol mi kovetkezik, hogy mi a bottleneck?
-
Abu85
HÁZIGAZDA
Szerencsére nem. Elég jól elvan például a SimHD egy Brazos-on, vagy egy kisebb minimalisztikus GPU-n. Pedig az algoritmus ugyanaz.
A dekódolóhardver az nem sokat tud ebből a szempontból (de ez általános dolog). Ezt az egészet a Purevideo HD teszi teljessé a hozzá kapcsolódó minőségi post-processekkel. Ettől nem lesz teljesen fix funkciós a képjavítás. Egy része az, de jó része shaderes. Az persze igaz, hogy az NVIDIA nem kínál annyi beállítást a driverben, de ez nem a hardver miatt van. Ugyanazokat be tudnák építeni, amiket az AMD használ, és akkor jobb lenne a GeForce-ok HQV HD 2.0 eredménye is. Ezt csak el kell dönteni, hogy rágyúrnak-e erre a területre. Egyelőre nem érdeklő őket. Elégedettek a kínált minőséggel. Az Intelt így is verik.
Alapvetően ez a fő cél, hogy bekerüljenek az Intel IGP-s notikba. Az AMD ellen felesleges menni, mert még ha egy csomó munka árán el is kapnák a Radeonokat képminőségben, akkor sem sanszos, hogy a Dual Graphics helyett a gyártók GeForce-ot válasszanak. -
lenox
veterán
Nade egy mitchell vagy lanczos filteres felnagyitasban egy gyengebb kartyan vagy egy apun gondolnam, hogy ugyis a bandwidth lenne a bottleneck, nem az, hogy az lds-bol gyorsabban jon-e az adat, mint a texture cache-bol, szoval nem lennek benne biztos, hogy ebben az esetben szamitana.
Nekem az nvidia elmondasa alapjan fix funkcios hardver remlik a scalingre, meg a purevideo oldalan is azt latom, hogy azt meg a leggagyibb is tudja (pl. nv 6200), szoval szerintem az nem shaderes.
-
Abu85
HÁZIGAZDA
Például ott a DirectCompute-ban az LDS. Ezzel a post-process effektek feldolgozás erősen felgyorsítható. Egy nagyobb VGA nyilván elbánna mindennel, de egy IGP már nem. Ezeknek az új API-k jelentik a sebességet.
A Purevideo az olyan, mint az UVD. Szimpla dekódolómotor. A képminőség javítása a shaderekből jön. Ezért vannak eltérő HQV 2.0 eredményei a különböző sebességű termékeknek. A Purevideo ugyanaz bennük, de a shaderes post-process már nem, mert egy kisebb GPU nem biztos, hogy elbírja. Ezt a gyártók driverben szabályozzák. Persze, ahogy láttam az NV és az AMD ezt felülbírálhatóvá teszi. Adnak egy alapértelmezett beállítást, amit úgy finomhangolsz, ahogy akarsz.
Igen a noise reduction is a része. Ennél viszont sokkal több van egy driverben. A Catalyst-ben például van: Smooth Video Playback, Dynamic Contrast, De-blocking, Mosquito Noise Reduction, De-noise, Edge-enhancment és Steady Video. Ezek mind shaderrel dolgozó eljárások. Hasonlóak vannak az Intel és az NVIDIA driverében is. Nem mind és nem ilyen néven, de a céljuk ugyanaz.
-
lenox
veterán
A felskálázáshoz gyorsabb algoritmus írható OpenCL-ben és DirectCompute 5.0-ban.
Miert is?
A képminőség javítására senki sem használ fix funkciós hardver.
Annyira nem kovetem, de ez a purevideo vagy purevideo hd-nak resze, nem? Szoval a legtobb szoftver tudna hasznalni, ami hasznal purevideot, az volt a benyomasom, hogy hasznalja is. Amugy annak idejen csesztettem is az nvidiat, hogy adjanak sdk-t hozza, hogy purevideon kivul is lehessen hasznalni, de nagyon huztak a szajukat, es vegul mast csinaltak, cserebe errol meg le kellett mondani. Mondjuk azota eleg sokat nott a gpu teljesitmeny, szoval mar nem erdekes, de pl. egy 8400 szintjen erdekes lehetett volna.
Az csak dekódolásra, illetve a deinterlace-re van
Meg pl. noise reduction-re.
-
-
Abu85
HÁZIGAZDA
A legtöbb szerkesztőt nem próbáltam ki, de a Sony Vegasban az effektek renderelése van gyorsítva. A HD 5850 nálam 7x gyorsabban végzett a feladattal mint a Q9550. APU-t nem tudtam kipróbálni. Abból az AMD-től vannak mérések. App gyorsítással a Sony Vegas Pro 11 kétszer-háromszor gyorsabbak dolgozik függően az effekttől. Ezt egy Llano A8-3850-en 1866-os RAM-mal.
A felhasználói programok nagyon nagy többsége már OpenCL-re, vagy DirectCompute-ra váltott. A zárt felületek főleg olyan programoknak maradtak meg, amelyek nem éppen az átlagfelhasználóknak készültek. Annyi, hogy a felhasználói programoknál a CUDA, mint alternatíva megmaradt, de ez csak ideiglenes. Például az Arcsoft a következő körben már több programból kiveszi ennek a támogatását, és csak az OpenCL-re szavaznak. Erről már kérdeztem őket, és azt mondták, hogy egyszerűbb egy mindenki által támogatott felületre koncentrálni, mintsem megosztani az erőforrásokat. A dolog logikus a felhasználónak mindegy, hogy mivel gyorsít csak gyorsítson, és legyen jó az eredmény.
Pont a lényeg maradt ki az SB-ből, de ezt már korábban elmondtam. Te pontosan tudod, hogy hogyan működik az egész, de egy átlagfelhasználó csak lesi, hogy nincs gyorsítás SB-n, miközben le-APU-zzuk.
A felskálázáshoz gyorsabb algoritmus írható OpenCL-ben és DirectCompute 5.0-ban. A PowerDVD például DirectCpmpute 5.0-ra szavazott. Nem kötelező tehát az OpenCL. Valószínű, hogy az ArcSoft azért döntött az OpenCL mellett, mert így azok a VGA-k is felskálázhatnak, amelyek nem DX11-esek.
A képminőség javítására senki sem használ fix funkciós hardver. Az csak dekódolásra, illetve a deinterlace-re van (illetve újabban az enkódolásra is van kiegészítés). A képjavítást mindenki shaderekkel végzi, mármint amit a driverbe építenek funkciókat. Ezeket nyilván a fejlesztők kiválthatják egyéni megoldásokkal, mint a SimHD az Arcsoftnál. -
lenox
veterán
Probaltad a legujabb intelt? En meg nem, de az biztos, hogy nagy unnepelve kuldtek rola emailt egy par hete, hogy van szuper uj verzio, es most mar sokkal jobb.
Masik erdekesseg, hogy macen tobb kod is joval gyorsabb volt, mint windowson valamiert. Meg egy erdekesseg, mac-en quadro 4000-re nincs opencl driver. Kb. az egyetlen kombinacio, hogy mai vga-val nem megy az opencl. -
lenox
veterán
A szerkesztes alatt az effekteket, pluginokat erted? Ebbol amugy nem nagyon derul ki, hogy mennyire van ertelme, ugy ertem mekkora sebesseget lehet nyerni azzal, hogy ezek opencl-ben vannak. Csak mert eleg sok kepfeldolgozasi eljarashoz fontos a bandwidth, amibol apunal opencl-ben is ugyanannyi van, mint a cpu-nak, szoval kerdeses a gyorsitas merteke. Nade vegul is mindegy, az erveket elmondtuk.
Szerintem Brook-kal, ctm-mel, streammel egyutt is sokkal tobb cudas program van. Es osszesen is alig van felhasznaloi, ami nem erdekesseg, vagy nem transzkodolas. Ezt is kiveseztuk szerintem.
Ha a tudast nezem, tehat nem a sebesseget vagy az elerheto felhasznaloi programok szamat, akkor az sb-t az amd apuktol az opencl/directcompute kulonbozteti meg. Szoval ha a tudast nezem, muszaj a definicioba bevenni, hogy milyen technologiat kell tamogatni, mert meg veletlenul az sb is apu lesz.
Amugy a videok valos ideju felskalazasahoz minek opencl? Egyreszt shaderrel is megy, es akkor nem kell az opencl es a directx vagy opengl kozott interopolni, masreszt szokott lenni fix funkcios hardver ra, gondolom amd-nel is van. -
zoltanz
nagyúr
Viszont sztem a Cuda-t ehhez már nem kell fejleszteni, max vas kell neki.
A Cuda -hoz van telepítési útmutató MPC-hoz, magyar nyelven, és pofon egyszerű Win-el.
(Valamint lehet kombinálni őket, DXVA -val megy a lejátszás és amire már nincs kapacítás azt Cuda-n keresztűl számolja) -
Abu85
HÁZIGAZDA
Nem a CUDA miatt szar az encode minősége. A driverrel érkező enkódoló gyenge, a Mainconcept enkódolója például jó. Persze az nem is olyan gyors. De a lényeg, hogy nem a CUDA a szar, hanem az algoritmus.
(#153) zoltanz: Az OpenCL-nek is mindegy. Egyébként a DXVA-nak is. Az is egy fejleszthető API.
-
Jack@l
veterán
-
Zeratul
addikt
Miért érné meg a Cudat támogatni? PC platformon ott az AMD és lassan Intel is a saját APUjával ami OpenCL, C++ AMP, WebCL/GL stb vele párhuzamosan az ARM fronton gyártók mindegyike felnőtt már az nV mellé saját SoCjával, az AMD meg várható ide. Egyszerűen nem éri meg fejleszteni egy gyártó platformjára amikor keresztplatformra fejlesztve sokkal több gyártó termékére el tudod adni a szoftot.
-
Abu85
HÁZIGAZDA
Ha az a cél, hogy a gyártók beálljanak támogatni, akkor arra ilyen feltételek mellett semmi esély. Amíg az NV zárva fejleszt, addig ez annyit jelent, hogy ha kifejlesztik az új CUDA verziót, akkor csinálnak rá hardvert, és akkor hirtelen odaadják a többi gyártónak a specifikációkat, akik egy, vagy két év múlva tudnak reagálni rá egy konkrét hardverrel. Ilyen feltételek mellett úgy gondolkodnak a gyártók, hogy nem állnak be támogatni, és hagyják, ahogy az OpenCL és a C++ AMP megteszi a hatását.
-
Abu85
HÁZIGAZDA
Az lényegében semmi. Az NVIDIA próbálja életben tartani, de a gyártóknak nem az kell, hogy nyílt legyen, hanem, hogy a fejlesztést egy gyártófüggetlen szerv végezze. Ez legyen akár a Khronos, vagy egy olyan megalakuló konzorcium, amibe bárki beléphet, és a fejlesztésbe mindenkinek ugyanannyi beleszólása legyen.
-
-
Abu85
HÁZIGAZDA
Az OpenCL lehetővé teszi a heterogén módon való programozást, ha nem GPGPU-ra találták volna ki, akkor ennek aligha lenne értelme.
A sebesség sokban függ a drivertől. Nekem fent van a procimhoz Intel és AMD driver is telepítve, de rendszerint az AMD-ét használóm, mert az Intel drivere lassabb. Mondjuk az én procim régi, így kevesebb optimalizálást kaphat. A luxrendert nem nézem. Én a felhasználók számára hasznos programokban hiszek.
Az elterjedtség nem is változik meg, amíg a programozást nem könnyítik meg. Erre már vannak elképzelések. A gyártók virtuális ISA-val szeretnének dolgozni. Ez egyszerűsíti a programozást, cserébe viszont a hardveres támogatás platformszintűvé válik. -
Abu85
HÁZIGAZDA
Egyszerűbb, ha a felsoroltak közül leírom, hogy mi mire használ GPU-t. vReveal MotionDSP (videoszerkesztés: képstabilizálás, minőségi felskálázás, stb.), a Sony Vegas Pro (videoszerkesztés, transzkódolás), az ArcSoft Panorama Maker Pro (képszerkesztés, panoráma funkciók), a Corel VideoStudio Pro (videoszerkesztés, transzkódolás), az eyeon Fusion (képszerkesztés), az ArcSoft TotalMedia Theatre (videók valós idejű felskálázása), a Corel WinDVD (videók valós idejű felskálázása), az ArcSoft ShowBiz (videoszerkesztés, transzkódolás), a Corel Digital Studio (videoszerkesztés, transzkódolás), a Cyberlink PowerDirector (videoszerkesztés, transzkódolás), a Sony Vegas Movie Studio HD (videoszerkesztés, transzkódolás), az ArcSoft MediaConverter (videotranszkódolás), a Viewdle Uploader (arcfelismerés, és eszerint keresés), az ArcSoft Webcam Companion (beérkező anyag valós idejű felskálázása), a Windows 7 drag&drop transcodere (videotranszkódolás), a Cyberlink MediaEspresso (videotranszkódolás), a Cyberlink PowerDVD (videók valós idejű felskálázása), a Cyberlink MediaShow (videoszerkesztés: képstabilizálás, minőségi felskálázás, illetve arcfelismerési szolgáltatások).
Ha a CUDA-t bevesszük, akkor bevehető a Brook és a CTM is. Ezt az AMD már nem fejleszti, mert belátták, hogy ugyanaz lesz a vége ennek a harcnak mint korábban. A gyártófüggetlen szabványok kivégzik a zártakat. Ettől függetlenül az eddig elkészített támogatás megmaradt. Erre most hirtelen 30+ programot fel lehet sorolni. Ezek zöme sajnos nem teljesen a felhasználókat célozza, de akad kivétel is, mint mondjuk a Shogun 2, ami ha egy AMD APU van a gépben, akkor az AI számítását az IGP-n végzi (CTM-en keresztül). Ehhez persze feltétel, hogy ne legyen dGPU az APU mellett.
A tudást nézd. A sebesség másodlagos. Arra majd a tesztek választ adnak.
-
Jack@l
veterán
Na most akko megváltozott az érvelés és mégis GPGPU-ra találták ki az opencl-t?
SZóval a nagy helyzet, hogy optimalizálásra mint olyanra opencl kódban elég kevés a mód realtime dolgoknál lehet játszani speciálisan kártyára és unitokra elosztani a párhuzamosítást, de! általában a kernelek az összes uniton futnak, ha az egyik kész, a queue-ból fogja a következő "szálat" és megcsinálja. Magyarul ha több szabad unitpd van több szálon dolgozik. Processsszornál is ugyanez a helyzet, ott kevesebb unit van ezért lassabb is, optimalizálást mint olyat javarészt max az opencl driverbe csinál a gyártó.
Nem, nem lassabb egyáltalán mint a natív kód(legalábbis amit eddig én láttam) sőt pl. LuxRenderbe(vagy LuxMark) gyorsabb is only cpu-n az opencl kód mint a natív cpu-val futtatva.
dGPU-nak az opencl-hez van köze, mert van aki arra játszik hogy gyorsan tudjon futtatni kódokat, és nem arra hogy APU-ja legyen.
Nagy jelentősége van az opencl-nek és a cuda-nak is, csak jelenleg még mindig gyerekcipőbe jár az elterjedtsége, főleg a közemberek körében. -
lenox
veterán
Szerintem eleg nagy resz, foleg, ha a gyartokat nezzuk, nyilvan egy panorama kepeket keszito szoftvert nem fog a quicksync gyorsitani.
Nade hadd kerdezzek. Hany olyan van a felsoroltak kozul, ami nem codec-et gyorsit (mert quicksync-es program is van jopar), viszont szignifikansan gyorsabb (szoval legalabb 2-szer, hogy ne legyek nagyravagyo, mert amugy 5-10-szerest varnek el) amd apu-n, mint egy hasonlo aru sb-n?
Amugy cuda-s program egy nagysagrenddel tobb van, nem? Szoval akik csodalkoznanak, hogy lam az sb nem sok mindent gyorsit, azok amd apu-n is csodalkozni fognak, hogy nem sok mindent gyorsit. Ezt arra az ervedre mondom, hogy szerinted amd apu-ra nem csak elmeletben vannak programok, mert szerintem altalaban is alig van gpgpu-s felhasznaloi program, nemhogy opencl-re. Nyilvan a trend szerint opencl-re tobb lesz, de ugye szerinted az sb azert nem apu, mert nincs ra eleg gpgpu-s felhasznaloi program (akar egy sem, a pontos szamot nem tartom lenyegesnek), es ezert ha apunak hivnad, akkor a userek szomorkodnanak, hogy lam megsem gyorsitja a sok programot, bezzeg amd apu-ra van egy csomo...
Persze, egyetertek, hogy nem erdemes egy kalap ala venni oket, egy llanos gep 2012-ben nem szamit fellabunak, mint egy diszkret vga nelkuli sb-s gep. Csak azzal a reszevel nem ertek egyet, hogy ez az altala gyorsitott programokon mulik, ivy bridge eseten is fellabu lesz a gep, ha a gyengebb igp lesz benne, hiaba tud opencl-t, persze ezt csak tippelem, aztan majd meglatjuk, mit tud a valosagban. -
Abu85
HÁZIGAZDA
Kötve hiszem, hogy bárki GPGPU-ra optimalizált OpenCL kódot futtat majd CPU-n. Nincs értelme. Akkor már ott a natív kód.
A dGPU-nak mi köze az APU-hoz?
A Windows 7 tartalmaz d&d transzkódolót. Ez egy beépített fícsör. A Catalystban egy másik van, illetve az csak egy legacy felület marad az AML megfelejésével és a VCE támogatásával. -
Jack@l
veterán
Nemtom mért vitáztok a múlton.
Egyrészt opencl-es program futni fog még sandy-n is, mert natúr procival is elmegy.
De ha netán van aki olyan szerencsés, hogy a mai világban megengeddheti a dedigált gpu-t is, akkor meg pláne....
Az a drag and dropos transzkódoló meg egy trutyi (sokkal jobbak és gyorsabbak is vannak), legalábbis ha arra gondolsz ami a catalyst-al telepedik. -
Abu85
HÁZIGAZDA
Maradjunk annyiban, hogy a felsorolt programok közül a QSV-t a Corel Digital Studio, a Cyberlink PowerDirector, az ArcSoft MediaConverter és a Cyberlink MediaEspresso támogatja. Ez kis túlzással sem nagy rész. És mint mondtam. Ilyen alapon a DXVA-gyorsítás is APU-vá tesz egy processzort. Pont az a lényeg, hogy az APU-t úgy értelmezzük, hogy az IGP-jét a programok általános számításra használják. Ha mindent egy kalap alá veszünk, akkor a potenciális vásárlók nem tudják megkülönböztetni a modern rendszert a butától, aztán majd néznek, hogy miért nem fut az OpenCL-es program az IGP-n, vagy miért nem tudják gyorsítani IGP-vel a Windows 7 drag&drop transzkódolóját.
-
lenox
veterán
Nyilvan nem, altalaban irtam az opengl shader alapu gpgpu-ra. Lehet, amugy, hogy van olyan, ami sb-n is elfut, de a keresesere sajnalnam az idomet elpazarolni. Persze attol, hogy senki nem vallalta be 10 dollaros gpgpu szoftver irasat sb-re, attol meg elvi lehetoseg van ra, szoval egy definicional erre figyelni kell.
Amugy az vicces, hogy az Abu altal sorolt programok nagy reszet ugyan az sb opencl-lel nem gyorsitja, de quick sync-kel igen, szoval a Fusionnel egyutt azert ezt ongolnak tekintem. -
lenox
veterán
Hat sajna ez annyit nem er. A quick sync-et kiprobaltam, meg az opencl-t is az intel fele sdk-val, de ennek mar semmi ertelme nincs, ugyhogy kihagyom.
En filmes/videos utomunka szoftverben illetve orvosi szimulacios szoftverben hasznaltam, de mint irtam, ha rakeresel a siggraph papperekre, akkor megtalalod, hogy milyen otletek voltak, aztan azokbol meg lehet keresni, hogy mi valosult meg.
#120: Szerintem neked tudnod kene, hogy ezt elsosorban nem is consumer kategoriaban kellene keresni.
-
Abu85
HÁZIGAZDA
Felőlem nézhetjük. Bár furcsa, hogy ennyi véletlen van.
Persze, hogy ugyanazok a korlátjai, de ez is skálázható lesz egy darabig. Mindig beleütközünk majd a fizika korlátjaiba. Az egymagos processzorok után nem volt kérdés, hogy a homogén többmagos processzorok ideje is lejár majd. Ellenben ha megnézed, akkor több évig a piacon voltak, vagyis éveket adtak a hardvergyártók kezébe a skálázásra. Ugyanez lesz a heterogén többmagos lapkáknál. Időt nyerünk, amíg nem lesz valami alternatív, és jobb gyártástechnológia a chipek számára. Elvileg egy tíz éves ciklust tudunk a heterogén árával nyerni, ami egyelőre elég jónak tűnik. Addigra azért csak lesz valami alternatíva a chipgyártásra.
-
Jack@l
veterán
"Pedig, ha megfigyeled, akkor a Llano érkezésével lódult meg a szekér."
Nevezzük inkább az eltelt idő és érdeklődés véletlen egybeesésének, előtte 1-2-3 évvel is meglódulhatott volna, ha nem lenne olyan foghúzós/nehézkes rá fejleszteni, sok korláttal.
Igen, a képfeldolgozást valóban kihagytam véletlen, arra is nagyon jó.UI: a heterogén cuccnak is ugyanazok a fizikai korlájai, energia, hő, helyfoglalás (tranzisztorszám)
-
Abu85
HÁZIGAZDA
Pedig, ha megfigyeled, akkor a Llano érkezésével lódult meg a szekér. Előtte nem volt sok program, de egy év alatt ezek száma a többszörösére nőtt. Most úgy 50-nél tartunk. Az OpenCL esetében még a Library-k hiánya a fő probléma, de erre lesz (illetve technikailag már van) az AML, ami megkönnyíti a médiaalkalmazások fejlesztését OpenCL-re. Amit még meg kell oldani, az a memóriára vonatkozik. Sajnos a GPU nem éri el a CPU memóriáját, és ez heterogén módon való programozás mellett egy erős korlátozás. Majd a jövőben érkező APU-k segítenek. A Trinity már vezet be erre egy alternatívát, de a tényleges megoldást a Kaveri hordozza, amikor a CPU és a GPU teljesen koherens memóriát oszt meg. Tudtommal az NV Maxwell is ugyanilyen lesz. Az Intelnél valszeg a Larrabee integrációja jelenti majd ezt a lépcsőt.
Pedig van felhasználási terület. Az említetteken kívül a legfontosabb, amit meg szoktak jegyezni a NUI. A Kinect például azért nem elég pontos, mert sok limitációt köt meg, a számítási teljesítmény érdekében. A GPU-nál kevés dolog alkalmasabb arra, hogy a képet elemezze, és kalkuláljon belőle, vagyis ez egy fontos fejlesztési irányzat. Az MS persze valószíni, hogy nem az OpenCL-t, hanem a C++ AMP-t fogja erre használni.
Nézd attól, hogy az Intel tolja auralizációt még lehet értékelhető fejlődési ágazat. Valóban nincs sok tapasztalatuk az OpenCL-ben, de látszik, hogy nagyon erősen ráfeküdtek. Nekik is fontos ez, mert ők sem tudják már skálázni a homogén többmagos processzorokat, ennek fizikai határai vannak. Egyelőre az OpenCL az egyetlen értékelhető alternatíva, amivel előre lehet lépni. Esetleg majd a C++ AMP, és tudtommal azt is erősen támogatják. Legalábbis az Ivy RC driverében már benne van az előzetes támogatás. Majd lesz végleges, ha kész lesz a felület. -
Jack@l
veterán
Az még a gf6600 sorozatban volt alternatíva az opencl előtt (meg talán még egy kicsit később is)
DE még nagyobb cumi, mit az opencl-re fejlesztés.
Viszont OpenCL évek óta van (4+), hardver is van alá, program viszont nagyon kevés. Nem az APU hiánya az oka, az biztos.
Hogy fog majd megsokszorozódni ez a közeljövőben? ( őszintén, még a 3d-s grafikán meg a videokódoláson, fizikán kívül nem is nagyon látok hirtelen felhasználási területet se)
Jó tudom az auraizé, amit igazából pár x-fi-s reverb -el simán meg lehet oldani emberi fülnek teljesen hihető módon játékokban. -
Abu85
HÁZIGAZDA
Inkább annak tekintem, különösen a poén rész miatt, mivel ha nem húznám meg ezt a határvonalat, akkor az olvasók jogosan érthetnék félre az APU lényegét, és jönnének a kérdéseket, hogy az SB-n - amellett, hogy APU-t csináltunk belőle - meg sem nyikkannak a GPGPU-s kódot tartalmazó felhasználói programok.
Ahogy te is leírtad az SB IGP-je buta mint a tök. Innentől kezdve ez egy óriási kavarás, amit te átlátsz, de egy átlag user már nem. Ők összekötik az APU-t azzal, hogy gyorsíthatja a fentebb leírt programokat. Az SB-re ez nem igaz, ezért nem lesz APU. Emellett az OpenGL támogatásról már ecseteltem a lényegi részt. Az az SB-n formálisan létező dolog. Valszeg ez az új Intel IGP-kkel sem változik meg, egyszerűen az Intel nem látja a jelentőségét. Én a technikai oldalról ezzel nem értek egyet, de az tényleg tény, hogy alig van OpenGL-t használó játék. Stratégiailag az Intelnek nem éri meg belekezdeni az OpenGL drivert jelentősen felzárkóztató fejlesztésekbe, vagy akár a teljes újraírásba. Olyan amilyen és kész, foltozgatják, hogy legalább az a kevés játék fusson, de többet nem adnak hozzá.
-
lenox
veterán
Jo, akkor nem idezted, csak nekem ugy tunt, hogy hasonlit a te definiciod az ovekre.
Akkor nem tekinted definíciónak. Köszönöm, hogy megosztottad velem.
Nincs mit, maskor is szivesen. Te amugy annak tekinted? Kulonosen azt a reszt, hogy ne csak poenbol irjanak ra programot? Nem hinnem...
Googlezz ra: 'gpgpu opengl'. Vagy nezd meg a gpgpu.org-ot. Esetleg a gpu gems sorozatot. Vagy esetleg keress egy par siggraph pappert. Viszonylag nehez lesz ezekkel vitatkozni.
Nyilvanvalo, hogy az a teny, hogy a felsorolt programok olyan apit hasznalnak, amit az sb nem tamogat, nem zarja ki az sb-t a gpgpu capable halmazbol. Vagy akkor ha mondok egy programot, ami cudat hasznal, akkor az kizarja az osszes amd aput is belole? Ugye, hogy nem.
Na most akkor melyik a jó?
A jo az, hogy ha azt allitod, hogy az sb nem apu, akkor ez kovetkezik a definiciodbol. Jelenleg ez nem all fenn, tehat nem jo. Szoval vagy a definicion vagy az allitason valtoztatni kellene.miért nem futnak az SB-n a fenti GPGPU-s alkalmazások.
Azert, mert nem tamogatja a megfelelo apikat. Nem azert, mert nem lehet heterogen modon programozni, mert azt lehet.
-
Abu85
HÁZIGAZDA
Nem, az AMD-t sosem idéztem, mert ők egy cég. Tudom, hogy nekik van egy definíciójuk az APU-ra, de azt szándékosan úgy alakítják ki, hogy a saját termékekre illeszkedjen. Ez engem nem érdekel, mivel marketing az egész, és hagy ne vegyem át.
Akkor nem tekinted definíciónak. Köszönöm, hogy megosztottad velem. Azt kötve hiszem, hogy az industry standard definíció az OpenGL-t GPGPU-s felületnek tekinti. Tudtommal maga a Khronos is grafikus API-ként fejleszti. Egyébként hívhatod az SB-t is APU-nak, csak te megérted, hogy a rendszernek milyen technológiai korlátjai vannak a Llanóhoz, a Brazos platforhoz, az Ivy Bridge-hez, meg a Trinity-hez és még jó ég tudja, hogy a jövőben milyen lapkához képest. Egy felhasználó viszont lesni fog, hogy az APU ott van a médiában, mint olyan fogalom, ami gyorsítást jelent a GPGPU-s alkalmazásokban, de a megvásárolt SB-n már nem fut az IGP-n a vReveal MotionDSP, a Sony Vegas Pro, az ArcSoft Panorama Maker Pro, a Corel VideoStudio Pro, az eyeon Fusion, az ArcSoft TotalMedia Theatre, a Corel WinDVD, az ArcSoft ShowBiz, a Corel Digital Studio, a Cyberlink PowerDirector, a Sony Vegas Movie Studio HD, az ArcSoft MediaConverter, a Viewdle Uploader, az ArcSoft Webcam Companion, a Windows 7 drag&drop transcodere, a Cyberlink MediaEspresso, a Cyberlink PowerDVD, a Cyberlink MediaShow és nincs kedven folytatni.
Na most akkor melyik a jó? Elmondani az olvasónak, hogy az SB csak akkor programozható általánosan, ha a programozók egy grafikus API-t hackelnek úgy, hogy valamennyire működjön az egész, de erre nincs tényleges program, vagy egyszerűen látva a hihetetlenül kevés OpenGL-re írt GPGPU-s programot (hirtelen nem tudok mondani egyet sem, de lehet, hogy ha keresek egy óráig a neten, akkor találok egy fingást szimuláló sample-t) ... egyszerűen megelőzni a sok kérdést, hogy miért nem futnak az SB-n a fenti GPGPU-s alkalmazások. -
lenox
veterán
Oke, en elhiszem, hogy nem fogadod el, de eddig pont oket idezted. Akkor melyik definiciot fogadod el? Ezt:
Az APU-t lehessen heterogén módon programozni, de ne csak poénból írjanak rá programot.
Ezt en nem tekintem definicionak a masodik tagmondat miatt. Amugy nem nyomatom az opengl-t, csak felhoztam azt a tenyt, hogy sb-re lehet gpgpu programot irni (opengl-lel). Pont azt nyomatom, hogy tul sok ertelme nincs, de ha ez a kriterium, akkor ennek az sb megfelel, tehat vagy erdemes elfogadni az industry standard definiciot, ami szerint az sb is apu, vagy akkor masikat kell keresni.
Bármennyire is próbálod ezt az OpenGL-t erőltetni, hidd el senki sem fog rá olyan programot írni, ami a GPU erejét általánosan kihasználja.
Mar irtak ra, ez nem a jovo, hanem a mult. Megjegyzem, van gpgpu-s patentem, amihez opengl shaderes a kod, siggraph pappereket is nezegettem eleget, szoval kb. ismerem a temat. Persze en cuda-t nyomattam, amikor mar volt, viszont volt olyan, hogy nem en dontottem el, viszont nekem az a hozzaallasom, hogy ezek (marmint opencl, cuda, opengl, stb...) eszkozok, es nem a celok. Ha az a feladat, en erre is meg arra is tudok fejleszteni. Azt lehet mondani, hogy az opengl szar gpgpu celra, meg hogy az sb igp-je is szar, csak akkor mondjal olyan definiciot, amivel ezek ki vannak zarva.
Ha tetszik az opencl, akkor vedd be a definiciodba, ezt mar eddig is javasoltam.
-
stratova
veterán
Már nem mai hír, de nem láttam még itt. Tudom extrém tuning, de miért ne
i7-3770K 7 GHz-en -
Abu85
HÁZIGAZDA
Nem fogadom el az AMD definícióját. A szememben egy UVD motor nem tesz egy rendszert APU-vá. Jó dolog, hogy benne van, de ez egy fix funkciós egység, ami nagyon jó egy dologra, de semmi másra nem, persze nincs is több elvárva tőle. Az APU-t lehessen heterogén módon programozni, de ne csak poénból írjanak rá programot. Erre jó az OpenCL és majd a C++ AMP, ami ugye a DirectCompute 5.0-ra épül. Bármennyire is próbálod ezt az OpenGL-t erőltetni, hidd el senki sem fog rá olyan programot írni, ami a GPU erejét általánosan kihasználja. A fájltömörítés csak egy példa, mert azt is lehet, de nincs értelme, mert az OpenGL API-t nem erre fejlesztették. Olyan limitációk vannak benne, amik brutálisan megnehezítik a munkát. Egy fejlesztő inkább használ OpenCL-t, vagy később C++ AMP-t. Ezek sem ultimate megoldások, de nagyságrendekkel kevesebb problémába fog ütközni például egy GPGPU-s fájltömörítő fejlesztése.
Az Intel az OpenCL-t eléggé tolja, későn kezdtek neki, de erősen fejlesztik. Nekik ez a felület a közhiedelemmel ellentétben nem rossz. Elég szép tanulmányokat írnak rá, hogy hol lehetne hasznosítani. Például engem nagyon meggyőzött az auralizácóval kapcsolatos ötlet, ami tényleg nagyon hasznos, hiszen beszélünk itt a jobbnál-jobb grafikáról, de a hang méltatlanul kevés figyelmet kap. Pedig eléggé fontos tényező. Az Intel az értékes felületeket támogatja. Az OpenGL csak azért van félvállról kezelve, mert kevés a lényegi értelme. Ezen persze lehet vitázni, de tény, hogy a PC-s játékok nagyon nagy többsége DX-et használ. Persze nem tagadom, hogy egy vállalatnak nem úgy kellene hozzáállni a témához, hogy ha valami nem elég elterjedt, vagy van rá jóval jobban kihasznált alternatíva, akkor arra a support is visszafogott.
-
lenox
veterán
Ilyet csak poenbol van ertelme csinalni, vagy masik oldalrol nezve nincs ertelme. De ha ugy definialod, hogy akkor apu, ha lehet ra gpgpu-s file tomoritot irni, akkor nem az a kerdes, hogy van-e ertelme, hanem lehet-e. Ha 100-szor lassabb is, mintha cpu-n futtatnad, attol meg lehetni lehet. Persze lehet mindenfele mas vitathato definiciot is gyartani, de szerintem nem erdemes, inkabb erdemes az iparagban elfogadott definiciot hasznalni, ami alapjan apu, vagy kimondani, hogy kell opencl, akkor meg nem az. Egyelore ha jol ertem, te az amd altal mondott definiciot fogadod el, ami alapjan apu, es kozben azt mondod, hogy nem apu, szoval ha jol ertem ezt az ellentmondast meg nem oldottad fel. Amugy egyre jobban hajlok arra, hogy ki kell mondani, attol apu, hogy a gpu-jan tud opencl kodot futtatni.
#103: Nem tudom, nekem az az erzesem, hogy az ivy opencl supportja sem lesz tul erdekes a consumer piacon.
-
dezz
nagyúr
Helyesbítek, a "GPU2" már CAL+CUDA alapú volt.
(A Core 15 OpenMM [Open Molecular Modeling simulation library] alapú, ami Nvidián CUDA, AMD-n OpenCL alapú.)
És igen, a "GPU3" (Core 16) pedig OpenCL-es.
http://en.wikipedia.org/wiki/Folding@home_cores -
Abu85
HÁZIGAZDA
Lényegében nagyon kicsi esélyét látom annak, hogy lesz valaha, mondjuk olyan fájltömörítő, melynek OpenGL-ben lesz írva a GPGPU-s kódja. Ezt az API-t nagyon nem erre találták ki. Ez olyan dolog, hogy írhatsz egy szoftver rendert a CPU-ra, és ellátja azt a munkát amit a GPU. De ettől GPU lesz? Én nem hiszem. A lehetőség még nem tesz alkalmassá egy terméket az adott feladatkörre.
Az SB-re kétlem, hogy bármi normális születhet OpenGL-ben. Szegénykémnek olyan gyenge az OpenGL támogatása, hogy még a grafikai programokkal is baja van, pedig azok nem éppen egzotikus igények szerint születnek. A hardver technikailag megfelel az OpenGL 3.3-nak és támogathatná a GLSL 3.30-at is. A gond az, hogy az Intel nem lája értelmét. Ezért van csak OpenGL 3.1-es driver GLSL 1.40 támogatással. Túl kevés OpenGL-es játék születik, így ezzel a felülettel a cég annyira nem törődik. -
dezz
nagyúr
"Le van tiltva = nincs benne."
A sarki fűszeres számára bizonyára... Nekünk ez nem egyenlő, hiszen ott van a lapkán, csak le van tiltva, nem használható.
(#100) lenox: "A gpgpu-s programokat foleg nem a consumer piacra szanjak, igy alig van a consumer piacon gpgpu-s program."
Jelenleg! De az OpenCL/stb. képes cuccok elterjedése (amiben jelentős szerep jut majd az Ivy Bridge-nek is) megnyitja az utat a szélesebb körű consumer piaci alkalmazás előtt.
Egyébként, az elmélkedés helyett, inkább ki jellene próbálni néhány shaderes GPGPU kódot, fut-e egyátalán SB-n...
-
lenox
veterán
Na jo, de akkor ezzel a gyakorlatban azt mondod, hogy hiaba lehet gpgpu-zni, ha nem opencl (vagy directcompute, vagy ...), akkor nem apu. Ha felsorolod, hogy melyik technologiat kell supportalni ahhoz, hogy apu legyen, az nyilvan oke.
Amugy egy csomo feature-t fejlesztettek opengl-ben is, ami konnyiti a gpgpu fejleszteseket, ha nagyon akarnek nyilvan tudnek filetomoritot is irni, csak ertelme nincsen, de attol meg lehet ilyet csinalni, szoval egy ezen (lehet, vagy nem lehet) alapuplo definico megint csak igaz lenne az sb-re is. -
Abu85
HÁZIGAZDA
Az AMD definíciója szerint az UVD önmagában APU-vá teszi a rendszert. Nekik ez jó, de nekem szerencsére nem kell a marketingtrükköket követnem.
Az alig abból a szempontból érdekes, hogy hol lehet jelenleg a GPGPU-t kamatoztatni. A multimédiás programoknál biztos, és ezek nagyobb többsége támogatja is a GPGPU-t. Ahol nincs előnye még a GPGPU-nak ott még nem lesz program, de idén már lesz OpenCL-es WinZip is, tehát haladunk.
Szerintem maradjunk a földön és lássuk be, hogy az OpenGL shaderei nem éppen úgy vannak alakítva, hogy általánosan lehessen programozni az SB IGP-jét, pláne, hogy a GLSL verzió leragadt 1.40-nél. De majd meglátjuk, hogy írnak-e hozzá fájltömörítőt OpenGL-ben programozva. Ha megjelenik egyszer, akkor írok egy cikket, hogy tévedtem, és az SB mégis APU.
-
lenox
veterán
Az APU egy heterogén módon programozható processzor.
Az amd definicioja az heterogeneous computingra:
A system comprised of two or more compute engines with signficant structural differences
Ez nyilvanvaloan illik az sb-re is.
A GPGPU-s programok főleg OpenCL-t, vagy DirectCompute 5.0-t használnak. Ezért nem tudod a Sandy Bridge IGP-jét használni több multimédiás programban.
A gpgpu-s programokat foleg nem a consumer piacra szanjak, igy alig van a consumer piacon gpgpu-s program. Az lehet, hogy a gpgpu-s programok ezen kis hanyadabol a mai modern programok foleg opencl-t es directcompute-ot hasznalnak, de ebbol nem lehet kovetkeztetest levonni arra, hogy az eddig fejlesztett gpgpu programok milyen resze futna sb-n.
tudományos cikkekkel pedig a felhasználó nem sokra megy.
A nem kihasznalt opencl-lel sem megy semmire, meg nem is kell nekik semmire. Legalabbis majdnem semmire. De attol meg, hogy a user nem jut vele semmire, attol meg a hatterben sokan sokmindent fejlesztettek. De amugy ennek nincs akkora jelentosege, annyi a lenyeg, hogy vagy ki kell mondani, hogy opencl, directcompute, c++ amp, vagy akarmi kell ahhoz, hogy valami apu legyen, vagy nem, de akkor az sb-re is igaz a definicio. Az nem annyira elegans, hogy nem mondjuk ki, hogy pl. opencl kell hozza, de a masfajta (shaderes) gpgpu-ra azt mondjuk, hogy csak kalandorok hasznaltak, tehat az nem illik a definicioba.
-
quex
tag
Nem értek hozzá, csak kérdeznék, mert nagyon zavaros nekem ez az egész APU-s jövőkép.
- A CPU-val együtt integrált grafikus mag nagy lehetősége az lenne, hogy speciális, nem csak grafikával kapcsolatos számítási feladatokra is tudjuk majd használni?
- Elképzelhető-e, hogy a jövőben úgy válik hasznos részévé a CPU-nak, hogy a dVGA-k feladatának csak egy részét vállalják át, esetleg nem is a grafikus megjelenítés lesz a fő felhasználási körük?
- Lehet-e programozni, illetve használni speciális számításokra, de nem grafikus megjelnítésre olyan alaplappal, ami nem támogatja a megjelenítést, mint pl. P67-es alaplapok? Arra gondolok, hogy a P67-es alaplapokban egyáltalán nem működik, esetleg áramot sem kap ez rész, vagy csak a VGA csatlakozó kivezetés hiányzik és számításokra így is használható?
-
Abu85
HÁZIGAZDA
Pont azt írtam, hogy az UVD nekem nem számít ide. A gyártónak számít, de a PH-nak nem.
Az APU egy heterogén módon programozható processzor. A tudományos cikkekkel pedig a felhasználó nem sokra megy. A GPGPU-s programok főleg OpenCL-t, vagy DirectCompute 5.0-t használnak. Ezért nem tudod a Sandy Bridge IGP-jét használni több multimédiás programban. Az Ivy Bridge-ét már használni lehet. -
lenox
veterán
Hat eleg sok tudomanyos cikk szuletett shader alapon, nem hiszem, hogy le lehet az osszes szerzot kalandorozni. Felhasznaloi szempontbol is sokkal tobbet talalkozhatsz shader alapu gpgpu koddal, mint opencl alapuval pl., szoval nem tudom ertelmezni azt, hogy az opencl vallalhatobb lenne. Tudomanyos vagy ipari celokra jobb, de ezekre meg a shadereket is nagy eroval hasznaltak.
Szerintem van definialva az apu, nem biztos, hogy pl. a ph-nak kulon definicioja kell legyen (sot, szerintem nem kene). Filozofalni persze barkinek lehet. De pl. ha az uvd neked ide szamit, akkor a quick sync nem kellene szamitson?
-
Jack@l
veterán
Bakke, egy hülye rövidítésen vitatkoztok, ahelyett hogy ilyeneket linkelnétek, sajnos úgy néz ki a Ph -hoz még nem jutot el a hír:
http://en.expreview.com/2012/02/26/ivy-bridge-core-i7-3770k-overclocked-to-7ghz/21410.html -
Abu85
HÁZIGAZDA
A GPGPU természetesen azóta létezik amióta shaderek vannak. De azért az nagyon ritka, hogy egy grafikus API-n keresztül általános számításra kihegyezett program fusson. 5-7 éve nem volt más lehetőség, így nyilván a kísérletező kedvű, úgymond kalandor programozók próbáltak trükközni, de abszolút nem általános dolog, mivel piszkosul nehéz így programozni. Igazi felhasználói alkalmazás nem is született. Az áttörést a tényleges GPGPU-s felületek hozták (OpenCL, DirectCompute 5.0, stb.). Ez már vállalható alternatívát képez, hiszen olyan szintre emelte a GPGPU-t, hogy nem csak a kalandor programozóknak számított kísérletnek. A multimédiás programok fejlesztői rá is repültek ezekre.
Jelenleg ennyit lehet elérni. Nyilván kell egy következő lépcső, ami még egyszerűbb programozhatóságot tesz lehetővé a tömegek számára. Ezen dolgoznak a cégek.Az APU-t én úgy definiálom, hogy egy olyan lapka, melyet heterogén módon lehet programozni. A kalandor programozókat ide nem veszem bele, mert az szimpla kísérletezés volt, aminek a felhasználói programok oldalán nincs igazi eredménye. Régen jó volt, ma már van jól működő alternatíva.
Az APU-t az AMD elég sajátosan értelmezi. Maga az Accelerated szó arra utal náluk, hogy valahogy gyorsítja az alkalmazást. Ezzel az AMD-nél az UVD motor használata is ide számít például. A FAD-on ismertették, hogy 200+ program használja már a rendszer valamely elemét gyorsításra. Én nem akarom ennyire sajátosan értelmezni. Egy cég megengedheti magának, sőt elvárható, hiszen az a jó, ha sok programot tudnak felmutatni. Nekem szerencsére nem kell ezzel törődnöm, így úgy értelmezhetem az APU-t, ahogy az valóban célszerű és lényeges.
-
-
#78
LackoMester
addikt
LackoMester
addikt
Jaj de szépen elkanyarodtunk a témától.
Bíztam benne, h. májusra meglesz az Ivy-m, de valószinűleg nem így lesz, szerintem is ennek oka, a bentragadt raktárkészletekben keresendő.
Idő mint a tenger, megvárom.
-
clippy
tag
Anyám ezt a sok szörszálhasogatást.. ezzel az erővel akkor a magyarban is más nevet adjatok a procinak mert ugye az intel és az amd "központi vezérlő egységét" processzornak hívjátok
.. amúgy jót röhögök, hogy egy processzor fórumban kolbászokról és diesel motorokrol olvasok 
talán visszakéne kanyarodni az eredeti cikkhez "késik az Ivy Bridge" pont.. 
-
lenox
veterán
Amugy en azt a definiciot talaltam csak az apura, hogy olyan lapka, ami a cpu-n kivul plusz feldolgozasi lehetoseget is tartalmaz, pl. gpgpu-ra alkalmas gpu-t, fpga-t, vagy mast. A Sandy Bridge-en meg lehet opengl shaderekkel gpgpu-zni szerintem, szoval a definicio illik ra. Ettol persze nem fogjak ok maguk apu-nak hivni, mert nem csinalnak reklamot az amd-nek, de nekem ugy tunik, hogy opencl nelkul is lehet valami apu.
-
Mumukuki
aktív tag
Ne viccelj már, a TDI a VW konszern brandje, opel pl nem használhatja a közvetlen befecskendezésű dieseleiben. (de a ford igen, bizonyos motoroknál)
Ráadásul benne is van az általad linkelt oldalban
"In many countries, TDI is a registered trademark of Volkswagen AG"Egyébként pl a mostani common rail is közvetlen befecskendezésű turbós, de már működését tekintve sem ugyanaz, mint az első TDI, sőt, a PDTDI is teljesen más működésű, mégis TDI-t használ rá a VW, mert ez a brand
Az, hogy "általános elnevezés" nem igaz, csak a köznyelvben, mint ahogy sajnos sok ember "Dzsip"-nek hívja a terepjárókat, holott az maga a Jeep márka.
hallari: Akkor biztos én vagyok "kütyübuzikkal" körülvéve, de nálunk pasik így sosem beszélnének, még azt is tudják, ha egy fiat konszern JTD épp egy opelben van CDTI néven, vagy hogy ugyanúgy CDTI néven fut a corsa 1,7 motorja, pedig az egy Isuzu
Az pedig egyenesen hülyeség, ha egy nem VW autónál le TDI-zik ha diesel motoros.
Aki meg nem, az csak annyit tud, hogy gázolajjal megy
Amelyik szerelő viszont ezekkel nincs tisztában, nos az hozzá ne nyúljon egy modern dieselhez inkább!Egyébként ez is azt bizonyítja, hogy ezek a jelölések Brand, nem típus (mármint, hogy ha más márka motorját használja saját néven), viszont az APU jelőlés még nem egyértelmű, hogy brand, vagy típus lesz hosszú távon, ezt majd az idő eldönti. Nyilván az AMD típust szeretne belőle
-
dezz
nagyúr
"Mellesleg az APU megnevezés az AMD sajátja"
Nem egészen, az APU-t, mint Accelerated Processing Unit, ahol a hagyományos CPU magok mellett más, célorientált számító egységek is vannak, már korábban is használták. Lásd APU-s wiki link.
"ergo ezt az Intel sosem fogja használni."
Hát, az Inteltől kitelik, hogy csak azért ne használják (ami amúgy kézenfekvő), mert x86 vonalon az AMD kezdte használni...
(Lásd pl. HyperTransport vs. QuickPath Interface, az utóbbi lényegében az első másolata, épp csak annyiban más, hogy nem kell úgy hívniuk.) -
dezz
nagyúr
válasz
#02119936
#63
üzenetére
"Úgyértem szoftveres odalról kihasználni sem lehet az új szolgáltatásokat."
Hát dehogynem! Számos OpenCL program van már és egyre több lesz (illetve kiegészítő meglévő programokhoz). Igaz, játékban még nem láttam alkalmazni, de várhatóan pl. a fizika jellemzően ezzel fog menni -- és a mainál sokkal komplexebb, látványosabb lesz. Amúgy már nagyon ideje.
(#60) zka67: A CPU az CPU, az APU az APU és CPU =/= APU. Nem tudom, mit nem lehet ezen érteni...?
(Egyébként mindegyik SB-ben és IB-ben (nem az -E-sekről beszélek) ott van az IGP, legfeljebb le van tiltva.)
-
#63
#02119936
törölt tag
bmollszeptim
#62
#02119936
törölt tag
válasz
bmollszeptim
#62
üzenetére
Nem jelemző a hibás CPU. Túl gyorsan jött a 22 nm nayg feladat és incs még szükség ezekre a APU-kra . Úgyértem szoftveres odalról kihasználni sem lehet az új szolgáltatásokat.
-
#62
bmollszeptim
aktív tag
bmollszeptim
aktív tag
még mindig jobb ha késnek,mint ha utána hibásan adnák ki.
-
hallari
tag
Pont ezért alkalmas az APU összefoglaló elnevezésére az integrált megoldásoknak.
Az általad linkelt szócikkből: "Examples include AMD Fusion, IBM CELL, Intel HD Graphics, and NVIDIA's Project Denver." (kiemelés tőlem)
nem is új a fogalom:
"The term accelerated processing unit or APU was first used in a public context with respect to accelerated computing in 2006..." -
hallari
tag
válasz
Atom_Anti
#55
üzenetére
Mondjuk talán pont a sokféle elnevezés miatt, de én még senkitől nem hallottam ezeket az elnevezéseket (szerelőtől se). Általában csak dízelt mond mindenki, aztán ha valakinek a SAJÁT kocsijáról van szó, akkor megemlíti, hogy "tudod, ez olyan nagynyomású Peugeot-dízel", vagy "ez ilyen drága gyűjtőcsöves-dízel", esetleg "ez még a hagyományos TDI".
Van egy általánosan bevezetett megjelölés, amit mindenki ért, aztán ha attól eltérünk, akkor már magyarázkodni kell. Az APU pont ezért lenne jó szerintem, mert pont a "TDI" általánosságát húzná rá a szegmensre, amit már nemigen kell magyarázni, esetleg csak specifikus szakcikkben.#Zeratul: ez egy nagyon jó összefoglaló, danke.
-
Atom_Anti
senior tag
Nem tudom bevenni egyenlőre, talán idővel megszokom. APU számomra egy jelzés ami mögött (AMD) technika áll. Úgy mint TDI, DTI, JTD, DTI, CDI, D, jelzések dizel motorra utalnak de mind más technikát jelent és más teljesítményt nyújtanak. Intel is más technikát használ és teljesítményben is eltér, habár ugyanazt a célt szolgálja.
-
Zeratul
addikt
-
Abu85
HÁZIGAZDA
Egyszer jelezték HPU-nak egy technikai doksiban. Utána semmi. Valószínűleg a marketinges részleg elvetette a HPU-t. Egy technikai doksi ebből a szempontból más. Az nem a médiának készül, hanem a partnereknek, akik úgy is látják, hogy mi történik. A médiában kétséges egy ilyet felvállalni, mert az jelezné, hogy az Ivy Bridge elvi szinten az AMD-t elképzelései után megy. Nyilván egy hozzáértőnek ez egyértelmű, de az embereknek nem, és ez az Intel számára most jó. Szimpla marketing és stratégia az egész, amivel mi úgy sem foglalkozunk.
-
#43
Plazmacucci
félisten
Mozsa
#28
-
Prof
addikt
Nem kell itt aggódni, karácsonyra megjönnek az új hídak és továbbgyarapítják a busás Intel profitot.
Megsúgom akinek egy i5 egy olcsó hűtővel 4.5ghz-en nem elég gyors az ivy se lesz az![;]](//cdn.rios.hu/dl/s/v1.gif)
Vállalati szférába még jó, hogy nálunk Intelt vesznek >-drágább ->több jut a zsebbe
és különben is "az AMD szar mert leég" mert láttak 10éve egy leéget AMD procis gépet.
Valamiért pl. Angliában ahol többet keresnek az emberek pl. ez nem teljesen van így.Másik meg a sok szar 3rd party chipset ami az amd-khez volt, egyik rendszergizda se akar több gondot magának ha nem muszály.
-
Szlovi
senior tag
Ebben a cikkben említetted,hogy várhatóan meg fog változni a neve CPU-ról HPU-ra :
...". A pletykák szerint a CPU megjelölés is el lesz hagyva, és a Santa Clara-i óriáscég utalni fog arra, hogy az újdonság már heterogén módon is programozható. Várhatóan ez a HPU jelölést vonja maga után, ami a Heterogeneous Processing Unit rövidítése." ...
Esetleg meg tudod erősíteni,hogy HPU lesz a neve a "gyereknek" vagy marad az "APUzás"
#38 +1
-
dahneey
tag
egyre neccesebb tartani ezt a tick-tock stratégiát. igaz hogy most közrejátszik hogy ezek lesznek az intel első apu-i, meg új csíkszélesség, meg 3d tranzisztorok (gondolom főleg az utóbbi kettő a probléma, nem hiszem hogy gyártás során sokat számít hogy cpu-ról van szó vagy apu-ról, de javítsatok ki ha tévedek). bár, ha már jól állnak az új architektúrával, és megoldják a gyártósorok problémáit akkor még menni fog egy darabig az évente új csíkszél/architektúra.
-
Abu85
HÁZIGAZDA
válasz
Atom_Anti
#33
üzenetére
Az A betű az APU-ban nem AMD-t jelent, hanem az Accelerated rövidítése.
Igazából pont az a lényeg, hogy közös legyen a jellemzés, mert mindkét rendszer ugyanolyan elvi felépítést alkalmaz, vagyis jellemezhető egy kategória alatt. Az APU itt a legelterjedtebb fogalom, és úgy gondolom, hogy már az is marad, hiszen az Intel nem szeretne bevezetni saját meghatározást. Ha hozok be egy minden szempontból definiálatlan jelölést, mint mondjuk az IPU, akkor pont a célt nem érem el, vagyis azt, hogy az olvasó megértse, hogy miről van szó. Az APU-t már sokan értik, hiszen nagyon sokszor írtunk a mögötte álló elvről. -
Abu85
HÁZIGAZDA
Technikailag az AMD kezdte az APU-t mint elnevezést. Igazából nincs levédetve, csak ugye különbséget akartak tenni a heterogén módon programozható processzorok és a homogén többmagos processzorok között. Lényegében az AMD találta ki az APU-t, mint elnevezést, ahogy a GPU-t például az NV találta ki. Idővel ezek általánossá vállnak, mert jóval egyszerűbb ráírni, hogy APU, mint magyarázni, hogy nem olyan processzor ez, mint a korábbi fejlesztések.
-
Abu85
HÁZIGAZDA
válasz
Atom_Anti
#24
üzenetére
Mert egy heterogén módon programozható lapka lesz az Ivy Bridge, pont olyan, amilyen az AMD-nél a Zacate/Desna/Ontario, vagy a Llano, illetve az érkező APU-k. Kell valami egységes jelzés, mert ezek már nem egyszerű processzorok, hiszen az IGP OpenCL-lel, DirecCompute 5.0-val, vagy C++ AMP-vel aktívan befogható általános számításra. Az Intel egyelőre nem jelzi ezt külön, míg az AMD igen, és ezt jelenti az APU jelzés. Mivel ez már nagyon elterjedt, ezért egyszerűbb az APU-t leírni, mint több mondatban ecsetelni, hogy az Ivy Bridge már azt a koncepciót követi, amit az AMD az elmúlt évben elkezdett az integrációval. Hívhatjuk felőlem máshogy is, de legyen valami egységes jelzés, amivel tudod, hogy a termék programozható-e heterogén módon vagy sem.
Az APU egyébként már kezd általános elnevezéssé válni. Erről már tudja a többség, hogy mit takar, így nem kell több mondatban részletezni, hogy nem hagyományos processzorról van szó. -
MPowerPH
félisten
"Ezért nem is állnak sem teljesítmény sem határidő kényszer alatt."
Dehogynem.
Csak nem tudnak mit csinálni, nincs a kezükben megfelelő eszköz, amivel az AMD APU-hoz hasonló konstrukciót tervezzenek.Oliverda: Ez nekem új?! Mármint az, hogy az APU az AMD sajátja. Az világos, hogy az Intelé CPU+IGP miért nem APU, de az nem, hogy ez a jövőben miért ne változhatna, és miért ne hívhatnák az is APU-nak?!
-
hallari
tag
"(pl. notiban vagy óccó irodai konfigban)" A legtöbb cég nem AMD-ben gondolkodik, úgyhogy a céges megrendelések jelentős része az Intelt gyarapítja. És ők ugye nem egy-két darabban gondolkodnak. Nem véletlen a ~70-30 arány. Ezért nem is állnak sem teljesítmény sem határidő kényszer alatt.
-
TomiLi
addikt
Innen is meg lehet világítani.
Nekem az jutott az eszembe, hogy azért tolják ki az Ivy rajtot (már ha beszélhetünk egyáltalán csúszásról), mert még mindig sok Sandy van raktáron. Így - elvileg - 21 napig még nincs választási lehetőség az Ivy és a Sandy között.
Ugye pár hete is arról szóltak a hírek, hogy nagyon sok sandy van raktáron, amit el kéne passzolni még az ivy előtt....Én is vettem egy átmeneti i3-ast....
-
Oliverda
félisten
Egyelőre még nem létezik olyan, hogy "Intel APU" mivel az Intel IGP-je nem támogatja az általános számítások gyorsítását.
Mellesleg az APU megnevezés az AMD sajátja, ergo ezt az Intel sosem fogja használni. Vagy találnak maguknak valami külön elnevezést a heterogén cuccukra, vagy marad simán CPU.
-
#18
Tibor_560sec
aktív tag
Tibor_560sec
aktív tag
Ez is amolyan "nyereséges okokból" csúszik ...
-
MPowerPH
félisten
-
vanye
senior tag
Másként látjuk a dolgot.
Sztem APU-ban is az Intel diktál. Az egy dolog, hogy az ő grafikus magjuk kicserkész az AMD megoldásához képest, no de aki (jelenleg!) APU-t vesz (pl. notiban vagy óccó irodai konfigban), az még mindig inkább Intelt választ, s még mindig a CPU-gyártásban kivívott neve miatt dönt a kékek mellett.
De értelek. Ha diszkrét VGA nélküli rendszert dobnék össze magamnak, úgy persze én is AMD-t vennék. -
-
#5
matteo_szg
őstag
matteo_szg
őstag
Jim McGregor jól tudja az új dátumokat.
-
#4
vanye
senior tag
Ł-IceRocK-Ł
#1
vanye
senior tag
válasz
Ł-IceRocK-Ł
#1
üzenetére
Már jó ideje csak maguknak diktálják a tempót, szóval némi késedelem így konkurencia nélkül... Gyanítom, nem ettől fognak szívrohamot kapni a cég részvényesei. (Ha egyáltalán.)
-
#3
SQX_Barto
addikt
Ł-IceRocK-Ł
#1
SQX_Barto
addikt
válasz
Ł-IceRocK-Ł
#1
üzenetére
Augusztusra jöjjenek ki legkésőbb, mert kb akkor rakom össze a gépem...
De a késének én sem örülök, minél újabb, annál drágább lesz (gondolom én)
Ha lehet inkább venném meg 1-2 hónaposan, mint azon a héten kijött CPU-ként, mert a kezdőára biztos nem lesz szimpatikus... -
#1
Ł-IceRocK-Ł
veterán
Ł-IceRocK-Ł
veterán
Ennek most nagyon nem örülök.
úgy értettem arra vagyok kíváncsi, hogy mit árul az ip.n 
(Valamint lehet kombinálni őket, DXVA -val megy a lejátszás és amire már nincs kapacítás azt Cuda-n keresztűl számolja)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Persze az a lényeg, hogy a lehetőség megvan. 
Új hozzászólás Aktív témák
- Xbox Series S 512 GB + kontroller 6 hó garancia, számlával!
- Apple Pad 5.generácio / 32GB / Wi-fi / 12Hó garancia
- BESZÁMÍTÁS! LENOVO LOQ 15APH8 15 notebook - R7 7840HS 16GB DDR5 1TB SSD RTX 4060 6GB WIN11
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- Samsung Galaxy A32 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest