Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
De nem fog működni a direkt programozás. Ezerszer nekivágtak már a gyártók ennek, de sosem jutottak egyezségre, mert megakasztja a fejlődést. Azok a cégek, amelyek GPU-architektúrát fejlesztenek tényleg nem viccből cserélik le az ISA-t 4-7 éves ciklusokban. A GPU-knál a memóriamodellbe van beletervezve a skálázódás, ami szükséges, hiszen egy multiprocesszor sokszáz, vagy többezer szálat kezel párhuzamosan. Meg lehet enélkül is oldani, csak akkor irtó tranzisztorpazarló lesz az egész, mert amit amúgy megoldanak az ISA szintjén azt a gyorsítótárakkal kell helyettesíteni. Nem véletlenül dolgozik a Larrabee/MIC multiprocesszoronként 512 kB-os L2 gyorsítótárral és egy baromi vaskos belső busszal. A többiek ezt elvetik, mert nekik erre nincs szükségük, hiszen a rendszereik 16-32 vagy akárhány MB-os gyorsítótár nélkül is működnek.
Az x86 skálázása is lehetséges ilyen módon, csak lassan 1 MB-os tár kell magonként, aztán 2 MB-os, és a buszrendszert is folyamatosan duplázni kell. Ez korlátozza a lehetőségeket, mivel a legtöbb tranzisztor nem a feldolgozókra megy el, hanem a skálázódást biztosító buszra és L2-re, amivel viszont a többiek nem élnek, mert ők nem restek letervezni egy új ISA-t.
Egyébként ha a fenti probléma nem lenne már rég lenne egy közös ISA és a GPU-kat direkten programoznák a fejlesztők, csak hát van ez a probléma. Abból pedig hiba kiindulni, hogy ha az x86 vagy az ARM 4-8 maggal megfelelő skálázódást mutat, akkor bizony kötelessége 40-80 maggal is azt mutatnia. Nem, sajnos ez nem így működik.Szerintem, ha az Intel bármit el akar érni, akkor a mostani architektúrát kell gatyába rázni. A Larrabee/MIC látványosan nem működik, kár erőforrást pazarolni rá. A grafikában óriási hátrány lesz a mozaikos deferred feldolgozás. A ZiiLabs-ot vették meg a Creative-tól, de ők csak úgy illenek a képbe, ha olyan lenne a lapka, hogy lenne pár főmag, lenne egy ZiiLabs-féle számolótömb, és maradna egy Genx IGP, amiben lennének a fixfunkciós egységek. A Parallella efféle dizájnokat már felvázolt. Igaz a saját rendszerükkel, de a ZiiLabs architektúrája ettől nem sokban különbözik. Ha a Parallellával működik, akkor működni fog a Zii-vel is.
A Gen 7.5 egyébként annyira nem tragikus. Mint hardver nyilván több ponton az, de mint irány igen jó, hogy az Intel felismerte a problémákat. Végre belátták, hogy minden amit eddig csináltak semmit sem ér, mert már a driveren elvesztik a teljesítmény zömét. Az írjuk újra felfogás tehát üdvözlendő, és úgy írják újra, ahogy az AMD és az NV évek óta csinálja, vagyis a driver parancsai az API-hoz igazodnak, erős profilozással, és komplex rutinrendszerrel. A mostani architektúra nyilván kuka ebben a formában, mert felesleges bele 80 EU-t rakni, ha a teljesítményen nem látszódik majd. Kell egy új alap, és arra fel kell húzni egy jobban skálázódó rendszert. Az Intel ráadásul maradhat az egyszerűbb szeletes skálázásnál, mert őket csak az IGP érdekli. Csak az AMD-nek és az NV-nek szükséges a jóval komplikáltabb tömbös skálázás, mert nekik 300+ wattos VGA-khoz is kell lapka.
-
Fiery
veterán
>Itt elértünk oda, ahol a Larrabee életképtelen volt, és az egész AVX is az lesz
Ez egy eros kijelentes
Az SSE-re is kopkodtek anno, amikor a vektorizalt adat kezeles me'g idegennek hatott, aztan latjuk, hogy hova jutott a dolog. Vagy arra gondolsz, hogy az AVX eletkeptelen a GPU-knal? Ez megint furcsa kijelentes, hiszen maga az utasitaskeszlet nem hatarozza meg a hw architekturat. Lasd P5 vs. P6 vs. Netburst vs. Banias vs. Silvermont vs. Larrabee vs. Bulldozer vs. Jaguar vs. Isaiah, mind-mind x86-os architekturak, de baromira nem azonos hardveres implementaciok. Az AVX utasitasokat szamtalan modon vegre lehet hajtani, az OpenCL es tarsai pedig mar most is kezelnek 16 szeles vektorokat, tehat a GPU-fejlesztoknek baromira nem idegen az ilyen szeles vektorok kezelese.>Tök esélytelen ez az egész MIC és AVX irány. Nem véletlen, hogy minden legalább egy maréknyi GPU-s tervezési tapasztalattal rendelkező cég elveti.
Marmint ugy erted, hogy a VIA es az AMD veti el, mert a tobbi cegnek nincs x86 licence eleve, tehat naluk a MIC es az AVX baromira nem opcio semmilyen szempontbol.
>Túl sok vele a programozói probléma
Mire gondolsz? Mikor hallottal _programozot_ arrol karogni, hogy milyen sz*r az x86? Foleg ugy, hogy a legtobb PC programozo eleve az ido nagytobbsegeben C/C++-ban nyomul, aminel nem igazan szamit az, hogy x86 van "alatta" vagy sem.
>és a skálázhatóság megszűnésével az egész átcsap masszív tranzisztorpazarlásba, mert direkt programozás mellett nem tudod lecserélni az ISA-t
Az ISA nem limitalja annyira a fejlodest, mint ahogy probalod beallitani. Az x86 sem rekedt meg soha az elmult 30 evben, erdekes modon. Egy flexibilis, x86 alapu GPU architektura ugyanugy tudna alkalmazkodni a piac valtozasahoz, mint ahogy az x86 alapu CPU-k.
-
Fiery
veterán
Pont az altalad idezett interjuban ecseteli Carmack azt, hogy direkt(ebb)en kellene a GPU-t programozni, es hogy az Intel-fele irany me'g aka'r mukodhet is, mert direktebb hozzaferest nyujt. Meg mintha arrol is szo lenne ott, hogy mennyire megerosodtek az x86-os CPU-k, es hogy mennyivel kellemesebb x86-ra fejleszteni, mint OpenCL-re:
" If it’s a choice of... now that we have these awesome multi-core x86 CPUs where we can get 24 threads in commodity boxes... it’s true that one GPU card can do more ray tracing than one 24 thread x86 box, but it’s not multiples more and if it’s just a matter of buying more $2000 boxes, it makes the development, maintenance, and upkeep much better. While everyone in high performance computing is all “rah-rah” GPUs right now, I’ve come full circle back around to saying the fact that we can get massive amounts of x86 cores and threads... it wont win on FLOPS/watt or FLOPS/volume, but in terms of results per developer hour it is much, much better."
Es ez egy 2 eves interju, amikor me'g a Sandy Bridge es az AVX volt a csucs. Abban totalisan igaza van, hogy sokkal kenyelmesebb, egyszerubb, megszokottabb fejleszteni x86-ra, mint mondjuk OpenCL-re.
>A GPU-k tervezése nem olyan egyszerű, mint azt sokan gondolják. Sokkal nehezebb összerakni egy ilyen rendszert, mint egy CPU-t.
En ezzel baromira nem ertek egyet, de teny, hogy egyiket sem csinaltam. Kivancsi lennék azonban arra, ha az nVIDIA-nak vagy az onallo ATI-nak kellene _nullarol_ egy CPU architekturat osszeraknia (tehat nem ARM, nem x86, nem IA-64, nem-akarmi-mar-letezo architekura alapjaira), elsore olyan frankon sikerulne-e, mint a Larrabee. Ha visszanezunk a multba, elsore az Intelnek sem szoktak osszejonni a dolgok, akarmilyen nagy es eros ceg is. Sot, nem egyszer elofordult, hogy parhuzamosan futtattak kulonbozo architekturakat, es az egyik kerult ki gyoztesen, a masik ment a levesbe (pl. Netburst vs. Banias/Dothan/Yonah). Siman lehet, hogy a MIC/Larrabee/LRBNI vonal is megy a levesbe, es AVX-512 lesz helyettuk. Vagy me'g az is lehet, hogy egy harmadik megoldas lesz a nyero, majd kiderul.
>A Larrabee ma a MIC. Annak hatékony kihasználásához van a vector intrinsics, de ez olyan mintha assemblyben programoznál. Nem fogom elhinni a programozókról, hogy ez számukra kedvezőbb, mint a C++. Szóval én ezt a direkt programozást kapásból kilövöm, senki sem szeretne Assembly szint közelében data parrallel kódot írni, még az Intel kedvéért sem.
Ha intrinsics-ekkel hatekonyabban lehet programozni, mint az OpenCL compileres baromsagaival meg overheadjevel, akkor hidd el, azt fogja hasznalni a programozo. Csak jelenleg me'g rendes Windows tamogatas sincs a MIC-hez, es maga a vas is brutal draga es rettento ritka egy mainstream fejleszteshez. Egyebkent mindket nyelv C/C++ lenyegeben, csak az OpenCL ugy le van butitva, mint az allat. Ha van idod, bongeszd at az OpenCL teljes specifikaciojat, olyan "erdekes" shortcutok vannak benne, amitol egy C/C++ fejlesztonek a hatan felall a szor. Pl. csinalsz valamit, amit ugymond "nem illik", es "not guaranteed", hogy mi fog tortenni. Annyira faek az egesz, hogy az valami botrany, de persze hasznalhato, csak ne hasonlitsuk egy C/C++-bol x86 kodot fordito rendes compileres/linkeres megoldashoz.
-
Abu85
HÁZIGAZDA
Az Intelnek még nincs Gen8 IGP-juk. A Haswell az Gen7.5. A Broadwell is az lesz, de nem biztos, hogy fejlődik, mert a 20 EU-ről 40-re lépés 10% pluszt hoz, és a tervezett 40-ről 80-ra lépés semmi gyakorlati sebességelőnyt nem jelent. Éppen ezért a mai Gen7.5-tel nem érdemes 40-nél több EU-t beépíteni, mert hiába raknak bele akár 500 EU-t, 40-nél nem skálázódik tovább a teljesítmény. Ez tipikus GPU-architektúra para. A rendszer elérte az úgynevezett skálázhatósági maximumot. Ez minden gyártóra érvényes, és ez az oka, amiért az NV, az AMD, és az ARM-os grafikában utazó társaság 4-7 évente kidobják a kukába az aktuális GPU ISA-t és terveznek egy újat, ami jobban skálázódik majd.
Itt elértünk oda, ahol a Larrabee életképtelen volt, és az egész AVX is az lesz. Nem tudod kidobni, így ha eléri a skálázhatósági maximumot, és a Larrabee azért nem jelent meg, mert már elérte, akkor ennyi volt. Nem lehet tovább növelni a teljesítményét. A Knights Ferry 32 magból nagyjából 12-14 magig skálázódott grarfikai számítás során, minden beépített mag afölött csak tranzisztorpazarlás volt. Ez ellen a Knights Corner úgy védekezik, hogy óriási cache-t és belső buszrendszert használ. Ezzel a skálázhatóság biztosítható, de csak akkor, ha minden adat ott van a mag saját L2 gyorsítótárában. Így működhet a MIC, de kérdés, hogy mennyire gazdaságos egy maghoz 1-2 MB-os gyorsítótárat fenntartani, illetve mi lesz akkor, ha a háromszöglista mérete nagyobb lesz, mint amennyi a hardver által támogatott mérethatár. Ilyenkor a feldolgozást két fázisra kell bontani mélységpufferrel, ami nagyon kellemetlen lesz a teljesítményre nézve. Illetve kötelező lesz a programozók számára a scene markerek használata, mivel ezek nélkül a hardver nem tudja majd, hogy minden háromszöget felpatchelt-e, vagy esetleg van még ilyen elem a mozaikon belül. És ha van, akkor az látszik-e, mert ha látszik, és nincs benne a listázásban, akkor az megjelenítési hiba lesz. Nem véletlen, hogy ma már az ultramobil szintre fejlesztő GPU-s cégek is menekülnek ettől a feldolgozási elv elől.Tök esélytelen ez az egész MIC és AVX irány. Nem véletlen, hogy minden legalább egy maréknyi GPU-s tervezési tapasztalattal rendelkező cég elveti. Túl sok vele a programozói probléma, és a skálázhatóság megszűnésével az egész átcsap masszív tranzisztorpazarlásba, mert direkt programozás mellett nem tudod lecserélni az ISA-t
-
Abu85
HÁZIGAZDA
Az OpenCL-nek az a gondja, hogy a kód teljesítménye és működése nem portolható direkten. A későbbi fejlesztésekkel az lesz, de ma még nem az. A gondot tetézi, hogy az AMD OpenCL implementációja igen specifikus, tehát a manapság jellemzően erre optimalizált programok igen rosszul működnek a többi cég OpenCL meghajtóján. A WinZipnek ez volt a baja egy évig, így a 16.5-ös verzió nem is működött az Intel és az NV termékeken, de a 17-es verzió már igen. Az Adobe jelenleg ugyanezzel a gondal küzd. Működik a többi hardveren az OpenCL implementációjuk, de annyira az AMD-re szabták, hogy iszonyatos hátrányban vannak a többiek a sebesség szempontjából. Ezért vannak a HSA mellett, mert azzal portolható teljesítményű kódokat írhatnak.
John Carmack sosem volt a direkt programozás mellett. Sweeney volt az, aki azt mondta régen, hogy a direkt GPU programozás a jövő, és lesz egy GPU-architektúra, ami domináns lesz, és csak arra kell dolgozni. A többiek majd szépen kiesnek. Ezzel ugye az a probléma, hogy nyilván a konzolok miatt ezt az AMD igen támogatja, hiszen a GCN lett a Sweeney által vizionált domináns architektúra, de szerinted egy Intel vagy egy NVIDIA ehhez mit szól? Az meg kizárt, hogy háromszoros munkát végezzen egy fejlesztőcsapat, mert egyszerűen nincs meg rá az anyagi keret. A PC-s porton nincs pénz, a konzolos portok hozzák az eladást.
Carmack a HSA-s jövőképről ennyit mondott egyszer egy interjúban: "The current generation Fusion parts are really a separate CPU and separate GPU connected on the die by better or worse interconnects, but their vision is integrating them much more tightly such that they share cache hierarchies, address space, and page tables. I think its almost a foregone conclusion that its going to be the dominant architecture in the marketplace ..."
Igazából őt ma a megatextúrázás érdekli, és jelenleg két cég (AMD és NV - még az ARM is, de ők ultramobil szint) kínál olyan GPU-architektúrát, ami tartalmaz MMU-t, és képes bindless textúrázásra. Ezzel már hardveresen támogatható a megatextúrázás, ahogy az OpenGL ezt fel is vette ARB-be. Az AMD annyiban kínál extrát a PRT-vel, hogy a GCN úgy támogatja a megatextúrázást, hogy minden hardver által támogatott textúraformátum megfelelő, így nem kötelező tömörítetlen textúrát használni.A GPU-k tervezése nem olyan egyszerű, mint azt sokan gondolják. Sokkal nehezebb összerakni egy ilyen rendszert, mint egy CPU-t. Bárki le tud rakni az asztalra egy működő GPU multiprocesszort, mert az nem nagy dolog, de egy olyat, ami skálázódik is, az már nehéz. Oda 10-20 év tapasztalat kell és nem dollármilliárdok. Tipikus példa erre a Larrabee. Az Intelnek is volt tapasztalata és szakembergárdája, csak a vezetőség elküldte azokat az embereket, akik azt mondták, hogy a Larrabee sohasem fog működni. Itt követték el a hibát, hallgatni kellett volna rájuk. Főleg John Gustafsonra, Michael Abrashra, vagy Andrew Richardsra. Ők a világ legokosabb emberei a parallel computing területén, és semmibe vették a véleményüket. Végül nekik lett igazuk.
A Larrabee ma a MIC. Annak hatékony kihasználásához van a vector intrinsics, de ez olyan mintha assemblyben programoznál. Nem fogom elhinni a programozókról, hogy ez számukra kedvezőbb, mint a C++. Szóval én ezt a direkt programozást kapásból kilövöm, senki sem szeretne Assembly szint közelében data parrallel kódot írni, még az Intel kedvéért sem. -
Fiery
veterán
>Jelenleg az egyik legnagyobb gátja a GPGPU-zásnak a kernelek körülményes és nagy késleltetésű indítása. Ezért kisebb számításokat nem érdemes GPGPU alapon megvalósítani.
Ez igy igaz. Ezt velhetoen megoldja majd a HSA, csak az a gond, hogy ez me'g mindig csak APU-knal lesz igazan franko, azaz a szoftvernek fel kell ismernie majd, hogy a gepben levo GPU-k kozul melyik az APU, es azzal kell vegeztetnie az idoben rovid lefutasu szamitasokat. Kerdes, hogy ki fog ilyen szinten belemaszni a dolgokba, ki fog ilyen melysegeben foglalkozni a GPU meghajtasaval, mikozben a CPU/FPU is "felno" a feladathoz.
Persze mobil alkalmazasoknal bejon az, amit irsz, azaz hogy a CPU/FPU jelenleg me'g nem eleg energiahatekony, igy nem feltetlenul erdemes vele vegeztetni bizonyos szamitasokat, de erre meg sejtesem szerint egyre inkabb jellemzo lesz a dedikalt hardveres gyorsitas, mint ahogy bejott az AES-NI es a transcoding, ill. jon majd a hardveres SHA gyorsitas is.
Tovabba, az lesz egy erdekes kerdes, hogy az Intel ragaszkodik-e vajon hosszutavon a homogen CPU-magokhoz, vagy esetleg a MIC mintajara keszit egy olyan oszver megoldast, aminel a CPU-magok kozott lesz mondjuk 4 db teljes erteku (mint most a mainstream desktop/mobil vonalon), valamint mondjuk 20-30 egyszerubb, kifejezetten AVX-512 szamitasokra optimalizalt "GPU-magja", ami azonban az operacios rendszer fele rendes CPU-magkent latszodik. Vagy netan elmennek abba az iranyba, hogy 2 vagy 4 db teljes erteku CPU-mag osztozik egyetlen AVX-512 feldolgozon, mint a Bulldozer eseteben. A variaciok szama szinte vegtelen, mindenkepp izgalmas lesz a 2015-2016-os idoszak
-
dezz
nagyúr
Persze, az Intel is megteszi, ami tőle telik, csak nem vagyok biztos benne, hogy ez hasonlóan energia- és helytakarékos/-hatékony tud lenni, mint egy GPU, aminek a nagy részét az "ömlesztett" ALU-k teszik ki.
Jelenleg az egyik legnagyobb gátja a GPGPU-zásnak a kernelek körülményes és nagy késleltetésű indítása. Ezért kisebb számításokat nem érdemes GPGPU alapon megvalósítani. Ennek megoldása egy jelentős lépés lesz. Az már az adott számítástól függ, hogy milyen sávszélre van szüksége.
Az Xbox One-t csak az eSRAM vélhetően GDDR5-nél alacsonyabb költsége kapcsán említettem meg. (Igaz, ott az CU-kból is kevesebb van.)
-
Fiery
veterán
Persze hogy sok kozos vonas van, hiszen az AMD az OpenCL fejleszteset a HSA iranyaba lokdosi folyamatosan
Irjak a sok blablat, hogy milyen nyelvekkel lehet fejleszteni HSA-ra, de ugyis szinte mindenki OpenCL-en fog. Ezert is fontos az, hogy milyen minosegu, milyen konnyen kezelheto az OpenCL...Marketingben egyebkent jo vagy, tetszik ahogy es amiket irsz a HSA-rol. Legyen igazad, az AMD-nek kene mar egy sikerelmeny is (a konzolokon meg a Kabinin kivul).
-
Fiery
veterán
Az AVX-512 kapcsan alapvetoen arra gondolok, hogy ha megnezed az Intel architektura fejlodeset mondjuk a Lynnfieldig visszamenoen, akkor "gyanusan" 2 evente duplazodik az elmeleti lebegopontos SIMD savszelesseg, amennyiben azt FLOPS-kent definialjuk. A Lynnfield 128 bites SSE egysegeihez kepest a Sandy Bridge 2x szelesebb (256 bites AVX), majd a Haswell az FMA-val kvazi megint duplazta ezt. Persze most le fog lassulni a tempo, hiszen a Skylake kapcsan nem varhato az AVX-512 beepitese, de ha csak egy olyan processzort veszunk, ami Haswell + AVX-512, az megint duplazasa a szamitasi kapacitasnak. Raadasul -- ez sem elhanyagolhato szempont -- a dupla pontossagu szamitasi kepessegek sokkal kedvezobb aranyban allnak az egyszeres pontossaguval, mint mondjuk egy Kabini vagy Richland eseteben (ahol 1/16 az arány).
Par eve me'g elkepzelhetetlennek tunt volna egy ilyen eros SIMD FPU, mint amivel most a Haswell buszkelkedhet. Emiatt sem tudtuk volna elkepzelni me'g par eve, hogy egy FPU-val hozni lehet egy also-kozepkategorias GPU szamitasi teljesitmenyet.
Ha eloretekintunk par evet, akkor siman osszejohet az Intel FPU-bol az a szamitasi ero, amit mondjuk a Kaveri fog tudni a GCN2-es iGPU-javal. Innentol pedig csak egy-ket kiegeszito modul vagy szoftveres emulacio szukseges ahhoz, hogy ki lehessen hajitani az egyebkent is erosen problemas Gen7/Gen8-as iGPU-t a Goldmontbol, es mehet minden FPU-val. Es akkor nincs szukseg semmi hokuszpokuszra, direktben lehet programozni a "GPU"-t.
Persze mindez csak elmeletileg lesz/lehet igy, az Intel pontos terveit egyelore nem ismerjuk. Az biztosnak latszik, hogy -- furcsamod -- a Larrabee 512 bit szeles SIMD utasitaskeszlete helyett vagy mellett megkapja a kovetkezo generacios MIC/Xeon Phi (Knights Landing) az AVX-512 tamogatast. Az azonban kerdeses, hogy mikepp fog valtozni a Gen8 utan az Intel mainstream iGPU-ja, pl. lesz-e MIC alapu iGPU, vagy esetleg kihuzzak a mostani architektura patchelgetesevel a Goldmontig -- ami az elso AVX-512 tamogatasu hagyomanyos CPU lesz, ha minden igaz. Nem vagyok egy roadmap magus, igy egyelore nem tudnam megmondani, mikorra varhato a Goldmont, ugyanis tul sok kodnev repked a levegoben
Jovore Broadwell, 2015-ben Skylake, utana Skymont, Airmont, Goldmont -- de ezek kozott siman lehet egy-ket Silvermont architekturas low-end proci is 
Mindenesetre, latva az AVX fejlodeset, en siman el tudnam kepzelni, hogy ne legyen szukseg iGPU-ra mondjuk 3-4 ev mulva. Az FPU-t, IMC-t, PCI Express vezerlot (stb) is sikerult kavarasmentesen integralni, pedig azok is kulso egysegkent kezdtek palyafutasukat.
A HSA kapcsan egyebkent nagyon keves a kozos cimter. Segit, jo dolog, de keves. Egy atlagos szoftverbe nehez lesz me'g igy is beilleszteni, foleg mert nem feltetelezheted, hogy minden a gepben levo GPU tamogatja ezeket a fejleszteseket (lasd diszkret GPU-k). Olyan szoftvert pedig csak konzolra lehet irni, ami azt feltetelezi, hogy APU-d van, es nincs semmilyen dGPU-d -- ezert sincs sok ertelme a konzolokat a PC-hez hasonlitani.
-
dezz
nagyúr
Sok közös vonás van a HSA és az OpenCL 2.0 között. Ebből is láthatod, hogy nem haszontalan dolgok ezek.
Jól megférhetnek egymás mellett, sőt egymást erősítik. Ha egy hw támogatja az OpenCL 2.0-át, onnan már nem sokból áll a HSA támogatása. A HSA jobb kompatibilitást és könnyebb portolhatóságot biztosíthat a programoknak, az OpenCL mellett más nyelveken írottaknak is. -
dezz
nagyúr
Pl. #33-asból eléggé ez jött le. Nem tudom, mennyi realitása van, hogy a programozók nekiállnak direktben különféle GPU-khoz low-level kódolni GPGPU-s alkalmazásokat, amikor eleve a CPU-tól is nehezen szakadnak el? Vagy tulajdonképpen az Intel AVX-512 alapú GPU-szerű, x86 alapú chipjeire gondolsz, ami talán véleményed szerint idővel majd kiszorít mindent, így a végén nem kell majd többfelé kódolni? Én meg erre nem fogadnék.
A HSA-nak csak egy része a HSAIL-es megoldás. A HSA kompliancia adott szintjeihez tudnia kell a hw-nek az ezen a képen látható tulajdonságokat. Ezek könnyítik meg a programozó és a compiler dolgát és teszik gyorsabbá a több szinten a folyamatokat. (Talán nem kell ecsetelnem a közös címtér, pointerek, lapkezelés, koherens memória- és cache-kezelés előnyeit. Aztán jön majd a többi.) A HSA tehát a korábbiaknál nagyobb elvárásokat támaszt a GPU-kkal szemben, hogy mindezzel sokkal jobb alapokat nyújtson GPGPU-s célra.
A HSAIL-nek lényeges eleme a portolhatóság (ami manapság igen fontos szempont), de nem csak ezt tudja. Nem ront az eddigi OpenCL-es "helyzeten", hanem javít. Gyorsabbá teszi a funkció invokációt, stb.
Maga az egész HSA nagyban optimalizálja az egész GPGPU-s funkcionalitást. (Nem csak a host <-> device sávszélt.)
Nem tudom, a HSA hogy viszonyul a dGPU-khoz, nem biztos, hogy parlagon hagyja őket.
A HSA Finalizer közvetlenül az adott platform CPU-jára is tud natív kódot fordítani, a HSAIL kihagyásával.
Ha az eDRAM vagy eSRAM cache-ként funkcionál, akkor különösebb szoftveres bűvészkedés nélkül is sokat tud segíteni a sávszélproblémán.
Egyelőre nem nagyon ismerjük az AMD későbbi terveit. Megtehetik, hogy gondolnak egyet, és a dGPU-ik helyére is (brutális) APU-kat tesznek majd... Az Nvidiának is vannak efféle tervei, csak x86 licencek híján ARM alapon.
-
Fiery
veterán
Mikor irtam olyat, hogy bukasra van itelve a HSA? Szo sincs errol. En csak azt irtam, hogy en tobb fantaziat latok a direkt GPU programozasban, mint a HSA-ban. Aztan majd kiderul, kinek a fantaziai jonnek be a valosagban
Eleve van kb. 3 ev, mire az AVX-512 implementalva lesz egy x86-os mainstream processzorban; es a HSA sem holnaputan kezdi meg a hoditast. Az ido majd eldonti a kerdest.En szemely szerint egyszeruen nem fogadom el kritika nelkul a marketing BS-et. Akarmilyen PDF-et meg webes oldalt mutogathatsz, hidd el, nem azzal van a gond, hogy ne tudnam, mire jo a HSA es mikepp lehet fejleszteni (majd) ra. A problema az, hogy nem oldja meg az OpenCL/CUDA problemait, hanem -- SZVSZ -- tovabbi reteg(ek)et rak ra, hiszen ahogy irjak is a PDF-ben:
"The HSA platform is designed to support high-level parallel programming languages and models, including C++ AMP, C++, C#, OpenCL, OpenMP, Java and Python, to name a few."
Tehat nem a felsorolt nyelveket valtja fel, hanem azokra epitkezik. Nem lenne ezzel semmi baj, ha:
1) Nem lenne mar most is problema a latency ezekkel a nyelvekkel. Fenyevekre van az elerheto latencyje egy direkt C++ nyelven (plane assemblyben) programozhato architekturanak az OpenCL-lel/CUDA-val/stb programozhato GPU-ktol.
2) Nem lenne mar most is problema ezekkel a nyelvekkel az optimalizaciok kapcsan. Persze mondhatod, hogy ezek a nyelvek nem errol szolnak, plane a Java, de nezzuk csak meg, hogy pl. Javaban es rokonaiban (pl. .NET) tipikusan milyen szoftvereket is fejlesztenek? Pl. Catalyst Control Center, netbankok, AbevJava, stb. Olyan szoftverek, ahol a portolhatosag az elsodleges, es nem igazan szamit a teljesitmeny. Na most, ha en egy GPU-t akarok meghajtani, akkor pont a vart/megalmodott nagyobb teljesitmeny miatt fordulok a GPU-hoz, es nem a kozvetlenul programozhato CPU-hoz. Ahogy hulyeseg Javaban megirni egy teljesitmeny orientalt szoftver(modul)t, ugy OpenCL/CUDA/tarsain is csak akkor mukodhetne ez a dolog, ha a teljesitmenyt sokkal jobban ki lehetne aknazni.
Jelenleg egyebkent azt ajanlja minden gyarto, hogy hosszan futo, sok szamitast igenylo kodot irjunk a GPU-kra, minel kevesebb host <-> device forgalommal. Ez pont azert van igy, mert az egesz hobelevanc latencyje nem tul kedvezo, es rossz a savszelesseg a host es device kozott. Az utobbira megoldas lehetne a HSA -- pontosabban az egyseges cimter, amihez nem kell HSA, hanem csupan OpenCL 2.0 --, csak ugye az APU-knak me'g jovore sem lesz elegendo savszelessege, tehat eleg korlatozottan lehet kihasznalni az egyseges cimteret is. Egy 4 csatornas memoriavezerlovel + DDR4 memoriaval + eDRAM-mal megspekelt konfiguracional egesz mas lenne a szitu, csak ugye az AMD nem azon a piacon focizik. Ha meg diszkret GPU-t programozol, akkor megsutheted az egyseges cimteret meg a HSA-t, sajnos...
>De valószínű az OpenCL compilernek is könnyebb dolga lesz a HSA-compliant hw-eken (most teljesen más architektúrák között kell hidat képeznie.)
Mi koze az OpenCL compilernek ahhoz, hogy HSA- vagy nem HSA-compliant a hw? A HSAIL --> GPU direkt gepi kodja forditast nem tudod meguszni. Es ha nem HSAIL binarist mellekelsz a szoftveredhez (mert mondjuk nem-HSA-s konfiguraciokon is szeretned, hogy fusson), akkor a source --> HSAIL --> GPU direkt gepi kodja forditasi lanc pont ugyanaz a maszlag, mint most a "sima" OpenCL eseteben. Raadasul, jelenleg hazon belul foglalkoznak az OpenCL forditok a 2 lepcsos forditas mindket szakaszaval, megis elcseszik a forditot a gyartok. Ha ilyen korulmenyek kozott -- amikor csak sajat magukkal kell "egyeterteniuk" -- is ilyen silany munkat vegeznek, belegondolni is rossz, mi lesz majd a mixed HSA meg hasonlo konfiguracioknal. Pl. APU + diszkret GPU, hogy csak egy egyszeru peldat mondjak.
Megjegyzem, ha a HSA egyszerunek tunik, akkor az altalad linkelt PDF-ben ajanlom tanulmanyozasra a 4.1 es 4.2-es abrakat. Ennel szamomra egy piciket egyszerubbnek tunik a direkt programozas
Vicces az is, hogy az abrak szerint a CPU-t is HSA-n keresztul hajtjak meg: na az egy baromi hulye otlet. Erdemes kiprobalni, milyen teljesitmenye van a meglevo OpenCL CPU drivereknek: nagyjabol a siralmas es a nevetseges kozotti hatarmezsgyen mozognak, hiaba van bennuk SSE meg AVX vektorizalt optimalizacio is. Ezen pedig vajmi keveset fog segiteni a HSA...A konzolok pedig fix hardverek, azokra mindig is baromi konnyu volt szoftvert gyartani, compilert irni, hardver-szoftver optimalizaciokat megoldani. Ne hasonlitsunk egy barmilyen konzolt a HSA-s PC-hez. Ha az AMD-nek is csak annyi feladata lenne, hogy egyetlen GPU architektura (GCN2) egyetlen GPU generaciojahoz (Kabini es tarsai) keszitsen egy utos OpenCL compilert, hidd el, semmi baj nem lenne a compilerevel. Megertem egyebkent, hogy benaznak, csak a fejlesztoket pont ezekkel a baromsagokkal idegenitik el. Maga az OpenCL szogegyszeru, mint ahogy a HSA is az lesz, a problema azonban az, hogy a legtobb szoftverbe nehezen illesztheto be ez a fajta megkozelites. Nem veletlen, hogy baromi keves OpenCL-t _rendesen_ kihasznalo szoftver letezik jelenleg.
-
dezz
nagyúr
Én is programozom (idestova 25 éve). Igaz, a GPU programozással, OpenCL-lel csak mint érdekesség ismerkedem, érintőlegesen (jelenleg nincs rá szükségem és időm sem, bár kedvem lenne szórakozni vele). Mindenesetre tudom, milyen távol tud állni egy rutin/függvény megírása egy rendszerre az utóbbi beható ismeretétől. Meg hát az OpenCL és a HSA más állatfaj. Nem értem, miért esik ennyire nehezedre akár csak az alap pdf elolvasása. Előre eldöntötted, hogy bukásra ítélt hülyeség az egész GPGPU téma, mert hogy jön majd a megváltó AVX512, ezért annyira sajnálod rá az időt, hogy meg sem nézed, pontosan miről is van szó?
Igen, többektől hallottam már, hogy sokat lehet szívni az OpenCL-lel. Kb. ugyanígy van a CUDA-val is (vagy pl. az FPGA-kkal, ehhez képest egy egész iparág foglalkozik vele). Aztán valahogy mégis sikerül összehozni, amit akarnak. Ha kell, kerülőutakon. Egyébként szerintem konzultáljatok lenox-szal (lásd blogja!).
Szóval, jelenleg OpenCL és C++AMP, de nem sokára Java is, aztán C++ és a többi. De valószínű az OpenCL compilernek is könnyebb dolga lesz a HSA-compliant hw-eken (most teljesen más architektúrák között kell hidat képeznie.) A HSA nagyon sokmindent leegyszerűsít, megkönnyít és felgyorsít. Programfejlesztés és végrehajtás terén is.
Az Xbox One-ban is ott van az EDRAM, márpedig ez volt az olcsóbb opció a PS4 GDDR5 ramos megoldásával szemben. Lehet persze, hogy desktopra/mobil vonalra így is drága, nem tudom. Megjegyzem, nem feltétlen kell 128 MB belőle (mint az Iris Pronál), hogy sokat gyorsíthasson a számításokon. A DDR4 nem létszükséglet mellette (inkább a CPU-nak van rá szüksége).
-
Fiery
veterán
Oke, akkor ha nem OpenCL-lel programozod a HSA-t, akkor mikepp? C++AMP, CUDA es tarsai ugyanaz a maszlag, mint az OpenCL. Ha nem ezekkel, akkor mit csinalsz, hogy kodot tudj irni egy HSA-s GPU-ra?
Egyebkent rossz helyen kopogtatsz
Tobbek kozt OpenCL-re is fejlesztek, szoval van egy egesz kicsi esely ra, hogy tobb ralatasom van erre az egesz temara, mint a WikiPedia alapjan Neked. Tenyleg nem bantani akarlak, es tavol alljon tolem a szemelyeskedes, csak ha mar igy belemerulunk, akkor szeretnem tisztazni a szitut. Nem a levegobe beszelek, amikor az OpenCL f***sagait feszegetem, most is 2 olyan OpenCL compiler buggal kuzdunk, amire az egyik nagy GPU gyarto ceg valasza ez volt:"I’ve reproduced the issue and filed a bug for our compiler team. I can’t give you a timeframe for resolution"
A masik nagy GPU gyarto ceg valasza pedig ez volt 1 honapja, es azota sem tortent semmi elorelepes:
"I’m giving this issue over to our compiler team to see what they come up with. I’ll let you know once we have root causes and if there is any guidance XXXX has regarding either issue." (XXXX = ceg neve)
Es nehogy azt hidd, hogy egy bonyolult kodot probalunk leforditani OpenCL-re. Egy szogegyszeru, faek kodrol van szo, aminek a nagy resze ugyanaz a sor, azaz egy borzaszto redundans loop unroll kodrol van szo. A 3 nagy cegbol (AMD, Intel, nVIDIA) csak az egyik OpenCL implementacioval mukodik a kodunk, a masik kettovel bugos. Es nem, nem az eredeti kod a bugos, az hibatlan. Szerinted ez egy olyan platform, amire biztonsaggal lehet epiteni? Irsz egy franko kis programot, hogy kihasznald a GPU kepessegeit, aztan vagy mukodni fog egy adott hardveren, vagy nem. Ezt hogyan vallalod, hogyan vallalhatod be szoftver fejlesztokent?
Arrol meg aztan ne is beszeljunk, hogy ha le is fordul vallalhato ido alatt a kod az OpenCL segitsegevel, me'g mindig semmi garancia nincs arra, hogy normalis sebesseggel futni is fog az adott hardveren. Es ahogy irtam fentebb, semmi de semmi ralatasa vagy rahatasa nincs a fejlesztonek arra, hogy mikepp fog futni a kod egy adott hardveren. Lehet persze kormonfont modon specifikusan kodot kesziteni adott architekturakra, de az is csak takolas, es azzal sem lehet extrem optimalizaciokat implementalni.
Ertem en, hogy a HSA azt (is) celozza, hogy egyszerubb, direktebb legyen a hardver meghajtasa, az jo lehet a latency csokkentesere, de sajnos sok mas gubanc is van, amikkel szivatjak a fejlesztoket.
Amit irsz a DDR4-rol meg az eDRAM-rol, az pedig a nagyon tavoli jovo. A realitas az, hogy 2014-ben nem lesz az AMD-nek DDR4 tamogatasu processzora. 2015-ben sem valoszinu, ha az eddigi trendeket vizsgaljuk, hiszen az AMD mindig 1-2 ev lemaradassal koveti a memoriaszabvanyok Intel altali adoptaciojat. Ha pedig az Intel a mainstream szegmensben 2015-ben, a Skylake-kel vezeti be a DDR4-et, akkor 2016-2017 tajekan jon az AMD-nel. Addigra pedig mar annyira megnovekszik a memoria savszelesseg igeny, hogy a DDR4 is baromi keves lesz a "boldogsaghoz".
Az eDRAM-hoz pedig en kicsinek erzem az AMD-t, no offense. Az Intel sem veletlenul kussol a Crystal Well kapcsan: volt 2 review a neten egy betas cuccal, aztan azota nagy semmi. Senkinek nincs, teszt (ES) peldanya sem. Ha engem kerdezel, en gyartasi nehezsegeket szagolok a levegoben. Na most ha az Intel a jol bejaratott 22 nanon is sziv az eDRAM-os CPU-val, akkor nem hiszem, hogy pont az AMD tudna a kozeljovoben gazdasagos gyartassal implementalni 28 nanon. Akkor mar nagyobb eselyt szavazok a GDDR5-nek: talan jovore lesullyed az ara annyira, hogy 8-16 GB-ot elfogadhato aron es elfogadhato teruleten tudjak az alaplapra illeszteni.
-
dezz
nagyúr
A HSA-t nem húzzák rá az OpenCL-re (esetleg fordítva), mert ez egy rendszerarchitektúra. A kedvedért ide másolom a linkről:
"Heterogeneous System Architecture
Heterogeneous System Architecture (HSA), maintained by HSA Foundation, is a system architecture that allows accelerators, for instance, graphics processor, to operate at the processing level as the system's CPU. To ease various aspects of programming heterogeneous applications, and to be HSA-compliant, accelerators must meet certain requirements, including:
- Be ISA agnostic for both CPUs and accelerators
- Support high-level programming languages
- Provide the ability to access pageable system memory
- Maintain cache coherency for system memory with CPUs, and so on.[17] HSA is widely used in System-on-Chip devices, such as tablets, smartphones, and other mobile devices.[18] HSA allows programs to use the graphics processor for floating point calculations without separate memory or scheduling.[19]"
Az OpenCL csak egy lehetőség a több közül a HSA-compliant HW programozására.
Amiket írsz, az első és második bekezdésben is, nos abból nem az jön le, hogy ismernéd és értenéd, sőt éppen ellenkezőleg. A helyedben inkább alaposan utánanéznék, mielőtt nyilatkozok róla.
A HSA többek között éppen, hogy közvetlenebb, egyszerűbb és gyorsabb hozzáférést biztosít a GPU-hoz:
E helyett:
Ajánlott olvasmány(ok): [link]
-
stratova
veterán
Sajnos én nem merültem el ebben kimondottan részletesen. Programozás szintjén pedig egyáltalán nem. Nekem úgy tűnik, maga a HSA is változik idővel. Gondolom a hardverek/integráció előrehaladottságával párhuzamosan.
Elvileg a pointerek + zero copy hivatott mérsékelni a pl. Llano esetében sem éppen bőséges sávszélességet.
De a GDDR5 elvetését én sem értem. A Sony is amellett tört lándzsát. Ha másutt nem is Opteron vonalon tán még kifizetődő is lehetne (bár ott a kimondottan nagy mennyiségű memória is szempont).
-
Fiery
veterán
Ne aggodj, ismerem a HSA-t. Vagy az nem az a reteg, amit az OpenCL-re huznak ra?
Milyen nyelven programozod a HSA-t? Nem OpenCL-lel (peldaul) ? En egy olyan architekturat (HSA), amit egy tobbszintu meglevo retegre (OpenCL) huznak ra pluszban, egy plusz retegnek nevezem. Az OpenCL mar onmagaban is tobbszintu, hiszen megirod egy C-szeru nyelven a programot, azt elkuldod forditasra (clBuildProgram), amit az OpenCL driver lefordit egy koztes nyelvre (pl. AMD IL vagy nVIDIA PTX), majd az OpenCL ujra leforditja azt, immar az aktualis GPU nativ gepi kodjara. Vegul persze lefut egy gepi kod a GPU-n, amire a programozonak nincs sem ralatasa, sem kozbeavatkozasi lehetosege. Ha bugos a 2 szintu forditas valahol, akkor igy jartal, nem fog mukodni rendesen es/vagy nem fog mukodni optimalisan a kod. Na most erre a maszlagra ranyomnak egy plusz reteget, ez szamomra nem tunik eletkepes megoldasnak. Plane ugy, hogy a nalam sokkal hozzaertobb emberek is azt szajkozzak, hogy mar onmagaban a Direct3D is tul nagy latencyt eredmenyez, es sokkal durvabb dolgokra lennenek kepesek a jatek engine fejlesztok, ha direktben tudnak programozni a GPU-kat. Nyilvan nem lehet ezt jelenleg me'g elkepzelni, hiszen pl. az AMD onmagaban is 3-4 kulonbozo GPU architekturat futtat parhuzamosan. De en a gyartok helyeben inkabb effele probalnek tendalni, mintsem a meglevo katyvaszt tovabb bonyolitani es tovabb rombolni az egesz rendszer hatekonysagat.Persze tudom, a HSA-val jon majd az egyseges cimter meg egy csomo mas erdekes nyalanksag is -- amikre azonban semmi szukseg nem lenne, ha a GPU-t a CPU nyers erejevel valtanak ki, vagy koprocesszorkent hasznalnak a GPU-t pl. egy masodik foglalatban. Arrol nem is beszelve, hogy eddig azt szajkoztak mindenhol, hogy ha optimalis CUDA vagy OpenCL kodot akarsz irni, akkor vedd figyelembe a savszelesseg szukosseget (videokartya <-> PCIe <-> CPU <-> rendszermemoria). Most meg majd mindenki eleresztheti a fantaziajat, mert lesz egyseges cimter es az milyen jo dolog? A nagy francokat, hiszen ahhoz kellene egy normalis savszelesseg a CPU-nal, ami nincs es nem is lesz egyhamar, ha az AMD igy folytatja! Nagyon kellett volna a GDDR5, helyette kapunk DDR3-2133-at, ami mar a Richlandnel sem mukodik rendesen...
-
Fiery
veterán
A GPU most is beemelheto a rendszerbe, pl. OpenCL vagy CUDA segitsegevel, a HSA csak egy plusz reteg azon a tobbretegu sz*ron, ami mar most se mukodik rendesen.
>Az AVX512 a szokványos FPU némi kibővítése
2x SIMD szelesites, 2x tobb regiszter = "némi" ? A mar most piacon levo Haswell nyers szamitasi teljesitmenye (AVX+FMA-val) is elerheti a 450-500 GFLOPS-ot a "szokványos" FPU-ja segitsegevel, egyszer pontossagot feltetelezve. A Richland VLIW4-es iGPU-ja ehhez kepest 648 GFLOPS. Szorozzuk be a Haswellt kettovel (AVX-512), legyen nagyvonaluan 1 TFLOPS. A vicc az, hogy azzal a nyers erovel mar foghato lenne az iGPU, ha direktben, x86-on programozna az ember. Persze tudom, az csak GPGPU-ra lenne jo, meg a FLOPS/watt mutatoja nem tul kedvezo, de a nyers teljesitmeny AVX-512-vel brutalisan nagy lesz. Egy kis fantaziaval el lehetne kepzelni egy buta iGPU-t (4 EU, a la Silvermont) es 2-vel tobb Haswell CPU-magot, es maris 1.5 TFLOPS-nal jarunk. Ezt programozzuk direktben, es hopp, van egy erdekes koncepcionk. En ebben tobb fantaziat latok, mint a HSA-ban, de majd hosszutavon kiderul, mire megy az AMD a HSA-val.
-
Fiery
veterán
Tehat lenyegeben ugyanugy 2 szintu forditas lesz, hiszen elso korben a nyers C-szeru kodot le kell forditani HSAIL-re, majd azt a GPU drivere forditja at a GPU nativ gepi kodjara. A vicc az, hogy most is ugyanez van pl. OpenCL-en, es ha ott bugos es sz*rul mukodik, akkor nem vilagos szamomra, hogy a HSA-nal ez miert mukodne jobban.
A direkt programozas temajaban erdemes megnezni, John Carmack milyen velemenyen van. En inkabb neki hiszek, mint annak az AMD-nek, aki a 5 evnyi tokoles es milliardos (USD) koltsegek utan egy ilyen Bulldozert rakott ossze...
-
dezz
nagyúr
Az Intel a tőkéjével ér el sokmindent, miközben az ilyen kis cégeknek, mint az AMD, nem nagyon marad más, mint az kreativitás, szellemi innováció...
Ez a "HSA maszlag", tehát a GPU valós beemelése a rendszerbe (eddig csak mint "külsős" dolgozott) szerintem nagyon is forradalmi dolog.
Az AVX512 a szokványos FPU némi kibővítése, de szerintem hosszabb távon nem bizonyul túl hatékonynak.
Az OpenCL-nek valóban van egy overheadje, a HSA részben pont ennek alapos lefaragása érdekében született.
-
Abu85
HÁZIGAZDA
A HSA-val nem fordulhat elő, hogy másképp fut a megírt kód a többi gépen. Ez a rendszer egyik alappillére. A fordítást minden gyártónak a saját finalizere végzi. Úgy működik a rendszer mint a Java. Lesz egy runtime, és mögötte a kapott HSAIL kód fordításáért egy gyártói finalizer felel, ami küldi a hardverhez a kódot. Ma is így működik a GPU-s dolog, csak az a különbség, hogy a HSAIL az egy szabványos vISA lesz, míg ma minden gyártó sajátot használ.
Az Intel és az NV GPU-kra eleve nem fordul majd HSAIL kód. Azokra a rendszerekre legacy opció lesz, vagyis a lapkában található processzoron fut majd a kód.
A direkt programozás kizárt. Erről már Johan Andresson is beszélt, nincs rá pénz és idő. Ő már kiadta az ultimátumot, hogy vagy beáll mindenki a HSA mögé, vagy aki nem áll be az így járt. -
Fiery
veterán
Most is abszolut pozitivan varom a Kaverit, csak tudni kell helyén kezelni a dolgokat. Nem fogja megvaltani a vilagot, mint ahogy az elodei sem tették/tudták. Az AMD mar nem eloszor probalja forradalmi(nak tuno) technologiakkal elkapraztatni a nagykozonseget, azonban a multbol kiindulva en nem fogadnek ra, hogy tenyleg akkora durranas lesz ez az egesz HSA maszlag. Oke, volt egy-ket baromi jo technologiajuk, amit lemasolt/atvett a konkurencia is (pl. IMC, HyperTransport, x64), de kozben egy csomo otletuk ment a sullyesztobe vagy kiderult rola, hogy a gyakorlatban nem kivitelezheto. A HSA, GCN es ezek kombinacioja helyett en inkabb a direkt GPU programozasban latom a jovot, amire a legjobb megoldasnak jelenleg szamomra az AVX-512 tunik. A HSA/OpenCL-nek nagy overheadje van, raadasul a fejleszto kenytelen kitenni magat a gyartok benazasainak is (bugos compilerek, bugos video driverek, stb). Megirod a jo kis HSA-s kodot egy AMD GPU-n, aztan csodalkozol, hogy a teljesen szabalyosan, a szabvanyokat kovetve megirt kodod nem mukodik rendesen, vagy csak baromi lassan fordul le mondjuk Intel vagy nVIDIA GPU-n; vagy epp kozeleben sincs a valos teljesitmeny az elmeletinek. Na ilyen nem fordul elo, ha direktben programozod a GPU-t, mint anno a hoskorban.
-
-
-
Gausz
aktív tag
Ezek szerint a Kaveriben már 7000/8000 van, tehát GCN, ami a 6000-rel nem köthető össze
[link] szerint "The AMD Radeon HD 8670M (sometimes known as the ATI Mobility Radeon HD 8670) is a DirectX 11.1 graphics card for laptops. Just like the 8500M and 8700M series, it is based on the Mars chip (28nm GCN architecture)"
-
Vartanus
őstag
És ebben mi nem érthető?
a 7000/8000 az az APU-ban(mert ez az a APU lényege ugyebár az X86/64-es magok és grafikus shader magok egy szilíciumlapkán laknak) van lásd 5800K with Radeon 7660D IGPAzért nem lehet a Richland/Trinityk mellé nagyobb dVGa-t tenni mint a 66xx/65xx,mert 7xxx-es szééri már GCN alapú az 5800K és / 6800K IGP-je pedig VLIW4-es architektúrát használ a kettő pedig nem köthető DG-ba.
-
-
Gausz
aktív tag
Megnéztem a hivatalos oldalán a specifikációt. Egyszerűen nem bírom felfogni, hogy Dual Graphicshez miért még mindig a 6000es sorozat alsó-középszintű kártyáit írják elő. Miért max 6670 vagy közel hasonló VGA-val használható? Ha már egyszer azt reklámozzák, hogy a 8000-sel is milyen jó lesz az alaplap, akkor legalább valami komolyabbat is befoghatnának erre a feladatra.
-
Abu85
HÁZIGAZDA
A Kaveri inkább a konzolokhoz igazodik. Azokat a szolgáltatásokat amiket támogat a két új konzol, átmenti PC-re, így a PC-s portból nem kell kivágni az effekteket/extrákat. Már 2014-ben lesznek ilyenek. 2014-től a Fifának három évig két programkódja lesz. Egy a HSA hardverekhez, és a butított a többi konfighoz.
(#17) Bici: Amelyik konzoljáték az IGP-t használja általános számításokra az portolhatatlan PC-re. Ilyen a Fifa 13. Ezért kap a PC butított portot, amit a PS3 és az Xbox 360. Az AMD azt találta erre ki, hogy partnerkednek az EA-val és két programkód lesz pár évig a PC-s Fifában. Ha van hardvered hozzá, akkor a modernebb portot is eléred. A grafikát meg majd számolja a VGA.
-
Taragas
aktív tag
A 88x-es variáns tetszetős... és még jól is néz ki...
Először úgy is lapot cserélek, de nézzük azért a többi versenyzőt is. Amúgy biztos vagyok benne, hogy már ott áll egy rakat a raktárban(hisz először nyárról volt szó), csak késik a kaveri, meg az előző lapokat is el kell adni. Én amúgy azért várom a kaverit, mert sztem full grafikán tudom futtatni majd a wotot egy integrált wgán, ami nekem bőven elég lesz... 
-
#13
Bici
félisten
KevinMulder
#12
Bici
félisten
válasz
KevinMulder
#12
üzenetére
A Kaveri abban lesz jó, hogy közös memóriát használ a GPU és a CPU.
Novemberben kezd el szivárogni majd, de leginkább jövőre lesz elérhető.
OpenCL-re valószínűleg verhetetlen lesz, és több, mint valószínű, hogy lezs belőle alacsony fogyazstású verzió is.
Egyébként ha hamarabb kell, és kisebb teljesítmény is elég, akkor a Kabini is jó alternatíva OpenCL-ezni - szerintem. -
#9
cairojack
aktív tag
KevinMulder
#5
cairojack
aktív tag
válasz
KevinMulder
#5
üzenetére
Szerintem irodába, meg HT-PC-be érdemes venni, ahova nem kell videokártya. Amiben van VGA kártya, ott ez felejtős, semmi értelme.
-
#8
Silentfrog
veterán
Silentfrog
veterán
Azért nem dobálják ki gyorsan ezeket a lapokat,mert akkor a meglévő Fm2 tokozásút nem venné senki?
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#7
Fiery
veterán
KevinMulder
#5
Fiery
veterán
válasz
KevinMulder
#5
üzenetére
Ugyanarra, mint a Richland. A Core i3-hoz kepest egy jo ar/ertek aranyu alternativa, arahoz kepest igen jo integralt GPU-val. Nagyjabol ennyi
-
#5
KevinMulder
tag
KevinMulder
tag
Tudnám, hogy mire jó a Kaveri ... alacsony fogyasztású szervert lehet belőle építeni?
Az SSE-re is kopkodtek anno, amikor a vektorizalt adat kezeles me'g idegennek hatott, aztan latjuk, hogy hova jutott a dolog. Vagy arra gondolsz, hogy az AVX eletkeptelen a GPU-knal? Ez megint furcsa kijelentes, hiszen maga az utasitaskeszlet nem hatarozza meg a hw architekturat. Lasd P5 vs. P6 vs. Netburst vs. Banias vs. Silvermont vs. Larrabee vs. Bulldozer vs. Jaguar vs. Isaiah, mind-mind x86-os architekturak, de baromira nem azonos hardveres implementaciok. Az AVX utasitasokat szamtalan modon vegre lehet hajtani, az OpenCL es tarsai pedig mar most is kezelnek 16 szeles vektorokat, tehat a GPU-fejlesztoknek baromira nem idegen az ilyen szeles vektorok kezelese.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Elsőre nem így értettem. 
Új hozzászólás Aktív témák
- HP Victus 15-fb1002AX - 15,6"FHD IPS - Ryzen 5 7535HS - 8GB - 512GB SSD - RTX 2050 - Win11
- Bomba ár! HP ProBook 440 G7 - i5-10GEN I 8GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Gar
- DELL Precision 7730 i5-8400H Quadro P3200 32GB 1000GB FHD 17 1 év garancia
- NYÁRI BOMBA AKCIÓK! PSN, STEAM, UBISOFT CONNECT, EA APP, XBOX EREDETI KULCSOK 100% GARANCIA
- LÉZEREZÉS! külföldi billentyűzet magyarra kb. 20-30p alatt!
Állásajánlatok
Cég: FOTC
Város: Budapest