Új hozzászólás Aktív témák
-
#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
-
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.
-
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...
-
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.
[ Szerkesztve ]
-
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
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.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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).
[ Szerkesztve ]
-
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
-
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.
-
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.
Új hozzászólás Aktív témák
ph A gyártók két microATX-es modellel készül az év végére, melyek támogatják a Kaveri APU-t is.
- Ukrajnai háború
- WLAN, WiFi, vezeték nélküli hálózat
- Kormányok / autós szimulátorok topicja
- Helldivers 2 (PC, PS5)
- iPhone topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Megjelent az iOS 17.4, minden idők egyik legfontosabb iPhone-frissítése
- gban: Ingyen kellene, de tegnapra
- Autós topik
- Óra topik
- További aktív témák...
- Hibátlan - MSI H110M PRO-D Intel LGA1151v1 alaplap + Windows 10 HOME digitális licensz
- Hibátlan - ASUS PRIME H310M-R R2.0 alaplap LGA1151v2
- Újszerű - ASROCK B450 Fatal1ty Gaming K4 AMD AM4 alaplap + Windows 10/11 HOME digitális licensz
- Újszerű - ASROCK B450 Pro4 AMD AM4 dobozos alaplap
- Hibátlan - CORSAIR Vengeance - KINGSTON Predator - 16GB (2x8GB) DDR4 RAM memóriamodul kit - 3000MHz