Új hozzászólás Aktív témák
-
lenox
veterán
Tegyuk fel fejlesztenek egy premiert hsa-val, es akkor majd nem fog futni intelen, nvidian, vagy akar korabbi amd-n? Vagy esetleg az eddigi 13 path melle felvesznek meg egy ujat, csak hogy kaverit supportaljanak hsa-val is? Amin amugy opencl-ben is tok jol futna minden...
Nyilvan nem azt mondom, hogy nem kell nekik kiserletezni vele, csak ne magyarazzuk mar bele, hogy az o platformjaikon (intel, nv, amd) majd a hsa jobban portolodik, mint az opencl, mert nem is supportalnak a platformjaik hsa-t. -
Abu85
HÁZIGAZDA
Arról, hogy az Adobe egy szoftvercég. Mindig próbálja keresni azt az utat, ami gyorsabb feldolgozást biztosít a felhasználóknak. Tudod hányszor az orruk alá dörgölték már a userek, hogy a Nik Software tök jól támogatja az AVX-et és az Adobe meg lemaradt ebből a szempontból? Nyilván minden cégnek megvan a maga prefenciája a jövő szempontjából, és az Adobe-nak mondjuk más, mint a Nik Software-nek, de a lényeg a felhasználók kiszolgálása gyorsabb funkciókkal. És ha az jó, akkor majd vesznek megfelelő hardvert.
-
lenox
veterán
Ha a klasszikus szoftereikrol van szo, akkor ok amd, intel es nvidia kozott portolnak, ebbol csak az amd hsa-zik, szoval akkor mirol beszelunk?
Mondjuk vannak mas projektek, amikrol nem tudom, hogy mennyire publikus, a videos reszleg vezetoje nagy haverom, ha talalkozunk szokott mutogatni dolgokat, eddig meg hsa-rol nem volt szo, csak regebben cudarol, meg utobbi idoben opencl-rol, de akkor majd legkozelebb rakerdezek, hogy mi a valodi velemenyuk, ami nincs a pr moge bujtatva.
-
Abu85
HÁZIGAZDA
Erről az egészről leginkább az Adobe vezető szoftvermérnöke beszélt még a HSA elindításánál. Ő vázolta fel, hogy az OpenCL nem olyan nehéz, mint ahogy a közhiedelemben le van írva, de egy algoritmus teljesítményét nem igazán lehet portolni és ez a szoftverfejlesztőknek a legnagyobb probléma. Ezért van oda a HSA azon ötletéért, hogy legyen egy olyan platform, ami portolható teljesítményt kínál a heterogén érára. Azt senki sem mondta, hogy könnyű a gyártók számára, de a Corel szerint nagyon jó az eredmény az AMD, az ARM és az Imagination HSA-s GPU-in mérve. Három teljesen különböző architektúrából már ki lehet indulni, így nem várják, hogy máshol is gond legyen ebből.
-
Abu85
HÁZIGAZDA
Az tévhit, hogy csak ennek a három gyártónak van saját IL-je. Mindenkinek van egy IL réteg a GPU fizikai ISA-ja előtt. Ennek oka, hogy minden gyártó cserélgeti a GPU ISA-t, mert a hardver elméleti skálázhatósága a fizikai ISA-ba van beleépítve. Ergo mindenkinek szüksége van egy virtuális ISA-ra a többféle GPU architektúra előtt. A HSA-val csak annyit tesznek a gyártók, hogy ezt szabványosítják és még a finalizer mögötti specifikus implementációt is belsőleg letisztázott direktívákhoz kötik.
(#719) Fiery: Az érdekes dolog lenne, hiszen a szoftverfejlesztők (a felsorolt cégek) voltak azok, akiket megkérdeztek, hogy mit akarnak. Ennek a hozománya leginkább a HSA. Semmi gond azzal, hogy zsugorodik a PC-s piac, nem ezért a szegmensért van mögötte egy kivételével minden ARM-os gyártó.
-
Fiery
veterán
"A legtöbb fejlesztő nem az első HSA implementációt célozza."
Ez jo duma
Mondjuk inkabb ugy, hogy a szoftverkeszitoket nem gyozte meg egyelore a HSA, es mindenki a masikra var, hogy valamivel eloalljon, ami erdekes, amire raharapnak a juzerek, es akkor megmozditjak a s***uket a tobbi gyartonal is a fejlesztok. Csak epp kicsit veszelyes ez az egymasra varas, ebben benne van az a veszely is, hogy senki se mozdul semerre. Plane egy zsugorodo PC-piacon, ahol a befektetesek megterulese az idei evben sokkal kevesbe egyertelmu, mint mondjuk 5 eve volt. Ilyen korulmenyek kozt fejlesztoket allokalni a HSA-ra nem egyszeru kerdes, plane amig egesz pontosan 1 db hardver van, ami tamogatja a HSA-t. Ilyen helyzetben a legjobb taktika a kivaras. -
Fiery
veterán
Tok mindegy, hogy runtime-nak vagy finalizernak hivod, attol me'g ott lesz a HSAIL --> GPU ISA fordito, amit a gyartoknak kell elkesziteni es karbantartani. A 3 gyarto, akinek van egyaltalan ehhez hasonloja (sajat IL --> GPU ISA fordito) az AMD, Intel es nVIDIA. Ebbol az AMD velhetoen fog tudni kesziteni egy megfelelo minosegu megoldast, leven hogy mar van par ev tapasztalatuk a temaban. Az Intel es nVIDIA velhetoen nem fognak ezzel babralni, hiszen nem leptek be a HSA alapitvanyba. A tobbi gyartonak meg pontosan nulla tapasztalata van ilyen forditok kesziteseben, tehat nekik is evekbe fog telni, mire valami jo minosegu forditot (finalizer) keszitenek. Sz'al en a magam reszerol az AMD-ben remenykedek, a tobbi gyarto teljesen kerdojeles, mar csak azert is, mert a nem-x86-Windows platformok sem tamogatjak specifikusan se az OpenCL-t, se a HSA-t. Amig pedig a juzereket el lehet vakitani me'g egy kicsivel tobb core-ral meg az idei es jovo ev slagerevel (64 bites SoC-ok), addig nem az OpenCL/HSA fordito irasa lesz a prioritas a gyartoknal, es a HSA sem lesz prioritas az oprendszer gyartoknal... Ne legyen igazam.
-
Abu85
HÁZIGAZDA
A legtöbb fejlesztő nem az első HSA implementációt célozza. Az AMD csinált egy JPEG dekódort a startra, ami nyilván elég hasznos, mert a Windows-ban rengetegen fognak képeket nézegetni és betölteni.
De egyébként 2014-ben fokozatosan jönnek a HSA szoftverek: a Corel, a The Document Foundation, az Adobe, a Cyberlink, a Telestream, az Arcsoft, a Roxio, a Sony, a GIMP Team, az Aviary, az eyeSight és a Mixamo támogatja a kezdeményezést a konzumer szoftverek oldaláról. Tehát a szoftvertámogatással nem lesz gondjuk. -
Abu85
HÁZIGAZDA
Pár dolog a HSA-hoz, mert nem tűnik világosnak. Ennek a platformnak csupán egy kernel drivere lesz. Ezt a HSA alapítvány teszi, vagy teteti bele az adott operációs rendszerbe. Mindenki ugyanazt a kernel drivert használja majd.
Maga a működés hosszú távon ilyen lesz: App egy támogatott nyelven írva->HSA Runtime->Finalizer->hardver. Egyedül a Finalizert készítik a gyártók specifikusan, de a HSA Runtime-ot a HSA alapítvány adja majd ki. A Finalizer esetében is számos megkötés van. Azért tartott az első HSA verzió elfogadása egy évig a working groupnál, mert a gyártók megegyeztek egymással, hogy milyen direktívák szerint készítik a specifikus implementációt. A cél az, hogy egyetlen forrás teljesítménye minden HSA-t támogató gyártó hardverén skálázódjon. Csak ez számított. -
orbano
félisten
Hat, en nem kaptam pl. mintakat, es a HSA oldalan is egy nagy nulla van a developereknek. Lehet a nagy partnerek kaptak, de gyanítom azok közül nem sok fejleszt consumer progit. No meg gondolom senki nem ad ki terméket alpha állapotú frameworkkel. Radásul még most is csak beta állapotban van, a hardvert sem kapni még gyakorlatilag, szóval fölösleges várni egyelőre bármit is
Mindenesetre nem örülök, hogy early adopterként kell beszállnom ebbe az iparba -
Fiery
veterán
-
-
Fiery
veterán
Oke, olyan szempontbol hint a native, hogy ... sz'al nagyjabol semmi ertelme azt nezni
Teljesen irrelevans, hiszen, ahogy irod is, a fordito mindent elintez. Szet kell a melot dobalni egy halom work group-ra, es megy minden szepen magatol. HSA nelkul is 
Es nem lesz lassabb vektor tipusokkal sem, a fordito elsikalja a dolgot (jo ertelemben).
-
LordX
veterán
Nem, a preferred a hint, a nativ a szabvány szerint "Returns the native ISA vector width." Mondjuk a vector data types oldalon meg azt írják, hogy mindent támogatni kell, és a fordítónak kell elintézni, ha a hardver nem tudja - valszeg az adott driver volt akkor hülye. De így is alátámasztja amit írtam, mert le fog fordulni, csak lassabb lesz.
És igen, driver is jött ki újabb azóta
-
Fiery
veterán
válasz
#32839680
#704
üzenetére
APP SDK olyan szempontbol franko, hogy egy halom sample-t adnak hozza, amik nagyon tanulsagosak. A tobbi reszet en meg se neztem, ahogy irtam fentebb is, az SDK-kat nem kedvelem, nem hasznalom, ha nem muszaj. Sample temaban erdemes me'g felrakni a CUDA Toolkit-et is, az is tartalmaz izgalmas sample-ket.
-
-
Fiery
veterán
válasz
#32839680
#698
üzenetére
Ebben az esetben melegen ajanlom az OpenCL-t, nem kell megijedni tole. Nagyon egyszeru az egesz, csak odaig kell eljutni, hogy az alapveto paradigmat megertse az ember (pl. work item, work group, device memory meg hasonlok). Par het alatt eleg jo rutint lehet benne szerezni, amennyiben van idod molyolni vele, es mondjuk a C-hez megvannak az alapok.
-
Fiery
veterán
válasz
#32839680
#694
üzenetére
Az eredeti OpenCL egy C-szeru nyelv, nem OOP. Keszuloben van az OpenCL C++, ami egy C+11-re epulo, OOP nyelv. Magyar dokumentaciot nem ismerek a temaban, lehet hogy van, de az angol doksikat is eleg konnyu megerteni. Ha programozo vagy, es angol szakmai szovegertesben nem vagy eros, akkor ott alapveto problemak vannak, amin SZVSZ az OpenCL tanulast megelozoen dolgozni kellene, no offense
-
Fiery
veterán
Akkor nem lehet megirni, amikor a ceget (legyen mondjuk az egyik "C" betuvel kezdodo) erosen tamogatja az egyik GPU gyarto
Akkor nagyon nehez mas architekturakra portolni az OpenCL kododat, sot, szinte lehetetlen ![;]](//cdn.rios.hu/dl/s/v1.gif)
Ha azonban a szoftver keszitojet nem tolja egy gyarto sem, hanem szabadon mokolhat, akkor furcsamod lehet lenyegeben platformfuggetlen OpenCL kodot kesziteni. Oke, lehet hogy lesz benne 1-2 elagazas, de nem tobb szaz, es nem tobb, mint mondjuk egy nativ x86/x64 kodban.A HSA meg az OpenCL 2.0 egyebkent teny, hogy nagyon jol jon, ha mondjuk SVM-et akar az ember hasznalni. De azert ne allitsuk be ugy, hogy mostantol minden celra tokeletes eszkoz lesz, es az eddigi problemakat egy csapasra elsopri a HSA. Ha igy lenne, akkor mar most egy halom HSA-gyorsitott szoftver lenne piacon, vagy legalabb be lennenek harangozva. Ehhez kepest van 2 db szoftver _keszuloben_, meg egy Windows patch (by AMD), es nagyjabol ennyi.
-
Fiery
veterán
Az a jo, hogy a HSA-nal nem fordulhat elo, hogy rossz a driver vagy az implementacio. Vagy megis?
Mert ugye jelenleg igy nez ki a dolog: OpenCL kernel --> OpenCL-IL fordito --> IL-GPU ISA fordito --> vegrehajtas. Itt el lehet cseszni a 2 lepcsos forditast es lehet nem-tul-optimalisan vegezni a vegrehajtast is. Ezzel szemben, a HSA-nal elso korben lesz egy AMD-fele sajat HSA implementacio, ami igy nez ki: OpenCL kernel (ha mar az OpenCL-rol van szo) --> AMD-fele OpenCL-HSAIL fordito --> AMD-fele HSAIL-GPU ISA fordito --> vegrehajtas. Itt pontosan ugyanannyi lepcsoben lehet elszurni a dolgokat, mint a HSA elotti idokben...Ha ehelyett lesz majd egy altalanos HSA implementacio, akkor meg igy fog kinezni a dolog: OpenCL kernel --> generalis OpenCL-HSAIL fordito --> AMD/Qualcomm/Samsung/stb-fele HSAIL-GPU ISA fordito --> vegrehajtas. Itt, amennyiben feltetelezzuk azt, hogy a generalis HSAIL fordito hibatlan es gyors kodot is fordit, akkor is megmarad a gyarto sajat HSAIL-GPU ISA forditoja, meg persze a vegrehajtasi resz, ahol ugyanugy el lehet szurni a dolgokat, meghozza nem kicsit, hanem pont annyira, mint a HSA nelkul. Semmi garancia nincs ra, hogy egy HSAIL kodot minden egyes gyartoi implementacio egyforma, egyenletes minosegben fog futtatni az epp aktualis GPU ISA-n. Plusz, azt me'g ki is kell varni, hogy legyen egy igazan jo OpenCL-HSAIL fordito, egyelore me'g az AMD-nek sincs, nem hogy barki masnak...
-
LordX
veterán
Na ne vicceljünk már. Egy OpenCL implementáció nem azért gyors az egyiken és lassú a másikon, mert a driver gyenge az utóbbin! Nagyon gyorsan zökkenjen ki mindenki ebből a téveszméből. Azért lassú, mert ez egy hardverközeli nyelv, és a hardverek mit ad isten különbözőek. ARM Mali-ban nincs shared memória, hanem a globális memóriában van a __shared objektum. Csoda, hogy a Radeonon gemm-ben 2x gyorsulást okozó __shared-be másolás Malin masszívan lassít? Intel GPU-ban nincs vektor típus, Radeonban van. Ezek használata Radeonon gyorsít, másikon meg le se fordul.
HSAIL drivert ugyanúgy akkor meg kell írnia a gyártónak, mint az OpenCL drivert. Innentől pontosan ugyanaz a probléma áll fent, a gyenge driver visszafoghatja a hardvert (és szerintem itt még jobban, mint OpenCL esetében, mert amíg az 1-1 leképezhető hardverfunkciókra vagy egyszerűen nem támogatott a feature, itt a finalizernek rendes fordítást és optimalizálást kell elvégeznie). És ez a lényege a HSAIL-nek: nem te végzed kézzel az optimalizációt a hardverre, hanem a finalizer.
Ami egyébként vicces, hogy egy büdös darab kódrészlet nincs a neten, amit hQ-t demonstrálna, a "HSA hQ sample code" a világ legirrelevánsabb keresési találatokat adó keresések versenyén dobogós lehet..
-
-
lenox
veterán
Azt a reszet nem erted ezek szerint, hogy aki a hsa implementaciojat meg tudja csinalni, az az opencl implementaciojat is meg tudja. Tehat ha az opencl nem skalazodik, akkor szuksegszeruen a hsa sem fog. Ha nem igy lenne, akkor opencl-rol hsail-re forditana valaki a kodot, es maris megoldana, hiszen ugy mar minden jol mukodik, ugye?
-
Abu85
HÁZIGAZDA
És ki cseszte el az OpenCL drivert? Mert írhatsz olyan kódot, ami x gyártón megy jobban, míg a másik kód y gyártó implementációján. Elkezdhetünk mutogatni, hogy na akkor neki rossz a drivere, de az OpenCL-lel minden rendben, mert a másik gyártó megoldotta, akinek meg máshol nem hatékony a drivere, de az mindegy az OpenCL rendben van, mert mindig tudunk valami pozitív példát felhozni a sok negatív mellé. Persze csinálhatjuk ezt még évekig, vagy lassan felébredünk ebből és megoldjuk a problémát úgy, hogy az a mainstream programozó számára is használható legyen.
(#688) lenox: Elfelejted azt, hogy a HSA-ban mindenki ugyanazt a Queue nyelvet használja, ami az egyik legnagyobb méregfog az OpenCL driverekben. Már ez a különbség is bőven nagyságrendi előrelépést jelent.
-
lenox
veterán
De azert gondold csak vegig, nem teljesen legbolkapott hw-ekrol beszelunk, hanem mondjuk egy amd es egy qualcomm hardverrol. Megirod a kodot, az amugy a hsa meg az opencl eseteben is kb. ugyanugy fog kinezni, es aztan majd mondjuk a hsa eseteben hasonlo sebesseggel fognak menni, az opencl eseteben meg teljesen kulonbozoen? Akkor elcsesztek az opencl drivert nem?
-
Abu85
HÁZIGAZDA
Sajnos eléggé különböznek az OpenCL implementációk. Ez nyilván abszolút nem segít a gondokon. És az adott kód teljesítményének portolhatóságán. Egyébként az egyik titok nyilván a HSA implementációjában keresendő. Vannak kötött direktívák, amiket mindenkinek követnie kell. Nagyrészt ez biztosítja, hogy ugyanaz a kód hatékonyan fusson egy teljesen eltérő hardveren.
Ezért van alapítvány, ezért van gyűlés, szavazás, és ezért halad lassan a szabványok elfogadása, mert egyezkednek az implementáció szempontjából. Az Khronos sosem egyezkedik. Mindenki úgy csinálja, ahogy akarja. Nekik csak a működés a fontos, de a sebesség már nem. Azt majd megoldják a program oldalán 2-3-4-5 opcióval. -
Abu85
HÁZIGAZDA
A HSA alapítványban nincs marketinges. Abban van egy vezető ügyvivő, illetve minden cégtől egy magas beosztású mérnök a cégre érvényes szavazati joggal. Ez az alapítvány nem akar marketinggel foglalkozni, mert nem a felhasználókat akarják megcélozni. A usereknek majd a cégek elmondják ahogy akarják. A HSA alapítvány a közös fejlesztésről szól.
Az meg, hogy soha senki sem csinálta még meg nem jelenti azt, hogy kivitelezhetetlen. Az ARM, az AMD és az Imagination eltérő architektúrákkal dolgozik, de mindhárman ugyanazt a kódot futtatják hatékonyan. OpenCL-ben ezt nem tudják megtenni. Ez az oka, hogy a két éve 5 tagból indult HSA alapítványnak ma már 50 tagja van. Megoldást találtak egy égető problémára és ezt megosztják a piaccal. -
Abu85
HÁZIGAZDA
Mert a HSA-t a nulláról tervezték úgy, hogy a teljesítmény portolható legyen. Ez volt a fő szempont. Nyilvánvaló, ha egy platform fejlesztésénél ezt helyezed előtérbe, akkor más platformokhoz képest, ahol erre nem figyeltek az alapoknál, lényeges előnyt érsz el.
A technikai részleteket azok kapják meg, akik belépnek az alapítványba. A programozó számára elég ha a HSAIL-ig felfedik a rendszer működését. A mögöttes rétegek rejtik a titkokat.
-
Abu85
HÁZIGAZDA
Nem. A dedikált GPU-ra a HSA nem lesz kiterjesztve. Úgy megoldható a működés, hogy a dedikált GPU HSA módban hagyományos formában nem használhatja a saját memóriáját. Erre valóban lesz is egy implementáció, de mivel senkit sem érdekel a HSA-t támogató cégek közül a hagyományos GPGPU modell, így érdektelen a rendszert ennél jobban fejleszteni ebbe az irányba.
A HSA ott segít, hogy valóban egyszer kell megírnod a kódot, és annak a teljesítménye minden támogató gyártó termékére automatikusan átültethető. Technikailag a HSAIL az az ISA, amit figyelembe kell venni a programozásnál. Utána a többit elintézik a gyártók. -
orbano
félisten
azert irtam hogy feketében teli oldallappal
lenox: szerintem elbeszéltek egymás mellett. A HSA arra lesz jó, hogy a jövőben ne fordulhasson elő ilyen eset. Ha egy HSA-ra írt kód egy hardveren gyorsít a progidon, akkor az összes HSA-t támogató hardveren is fog. Nyilván ha opencl-ben írsz kódot ugyanezekre a hardverekre, ott is elérheted ezt, csak akkor minden hardverre neked kell majd megoldanod az optimalizációt.
nyilván ha egy nem HSA kompatibilis hardveren az overhead miatt nem tudsz egy feladatot gyorsítani, akkor a HSA frameworkjével sem fogsz tudni. -
Abu85
HÁZIGAZDA
Egyfelől úgy, hogy teljesen másképp működik a vISA, és a mögöttes réteg, mint bármely mai megoldás. Ebből ered az, hogy bármilyen HSA-ra írt kód teljesítménye portolható minden HSA-t támogató hardvergyártó között. Egyszer megírod és mindig működni fog. Erre lehet még optimalizálni a HSAIL és a gépi kód között. Ez az egyetlen tulajdonsága, ami miatt a szoftveres és a mobil iparág mögé állt.
Ha nincs HSA-t támogató hardvered. Tehát olyan integrációd, ami képes HSAIL kódot futtatni, akkor van a legacy mód. Ez x86-on például AVX2-ig is működni fog. Ha ott van a prociban az ISA, akkor arra optimalizál a HSAIL mögötti réteg.
Azt sajnos nem mondják meg hogy hogyan csinálják a HSAIL mögötti dolgokat. Aki belép a konzorciumba az megtudhatja. A programozó számára elég a HSAIL-t ismerni.
-
lenox
veterán
Azok a kódok, amelyek erre a mély integrációra vannak kihegyezve más OpenCL-es hardveren leginkább lassulást fognak okozni. Esetenként sokszorosat. Erre jön a HSA runtime, hogy a koncepció mindenhol gyorsulást hozzon, anélkül, hogy mindenhova specifikus kódot kellene írni. Az OpenCL-ben viszont nem portolható a teljesítmény.
Tehat a HSA runtime megoldja, hogy dgpun is gyorsitson, ellenben opencl-ben nem lehet megoldani? Ezt hogy csinalja?
-
Abu85
HÁZIGAZDA
A LibreOffice új verziója nem szimpla OpenCL-t használ, hanem két speckó kiterjesztést. Ez gyorsítja be sokszorosára. Amelyik hardver ezeket nem éri el ott a gyorsulás mértéke nem több pár százaléknál. Sőt, lehet lassulás is, például dedikált GPU-val, vagy olyan konfigurációval, amire nincs Zero Copy.
Azok a kódok, amelyek erre a mély integrációra vannak kihegyezve más OpenCL-es hardveren leginkább lassulást fognak okozni. Esetenként sokszorosat. Erre jön a HSA runtime, hogy a koncepció mindenhol gyorsulást hozzon, anélkül, hogy mindenhova specifikus kódot kellene írni. Az OpenCL-ben viszont nem portolható a teljesítmény.
-
ukornel
aktív tag
"Lefele szépen skálázódik, ezt senki nem tagadja. De a 7850k árához képest gyenge, vagy teljesítményéhez képest drága. Plusz fogyasztása sem olyan jó a teljesítményhez viszonyítva. Felfele nem skálázódik jól, sajnos."
A mobil verziók (15-35W) remélhetőleg kifejezetten jók lesznek. Csak jó áron kéne adni őket; és persze a gyártóknak is szakítani a hagyományokkal és értelmes eszközöket építeni rájuk.
-
devast
addikt
Lefele szépen skálázódik, ezt senki nem tagadja. De a 7850k árához képest gyenge, vagy teljesítményéhez képest drága. Plusz fogyasztása sem olyan jó a teljesítményhez viszonyítva. Felfele nem skálázódik jól, sajnos.
Abban is egyet értünk, hogy a hardverrel kell kezdeni, amivel nincs is probléma, egészen addig amíg nem akarnak prémiumot kérni olyan technológiákért, amitmégnem használnak szoftverek. -
orbano
félisten
hat nem egyszeru es gyors folyamatrol van szo, ez teny. de a hardverrel kell kezdeni. ha megnezed a teszteket, a HSA-s dolgoktol fuggetlenul is eros lett a Kaveri, teljesitmeny/watt aranyban eleg eros, ha jatekokrol van szo. Nekem szimpatikus, otthonra valoszinuleg veszek a 45 wattos verziobol, alkalmi jatekra, meg netezgetni, illetve tesztelni jo lesz.
-
siriq
őstag
Mi az amit a kulfodi tesztekbol nem sikerult megtudni?
Mas:
A software-s tamogatottsag a beka segge alatt van. Leghamarabb 6 honap de inkabb 12 amig lesz belole valami.
Az utem terv alapjan veletlenul nem fog megjelenni addig egy masik hsa proci ennyi ido alatt? Tehat tamogatas nulla majd jon egy masik 1 ev mulva amikor mar lesz. A kaveri-t miert lenne erdemes meg venni az embernek nagyon dragan? Azert a par programert a milliobol? Most millio programrol beszelunk pc-n NEM arrol a 0.00001% rol.Mantle lehet csuszik feb-re(egyelore egyeztetes van de minimalis az hogy megjelenjen idore). Ahoz kepest mar novemberben kesz volt es decemberben akartak mindenkeppen kiadni.
-
Abu85
HÁZIGAZDA
Az új AMP valszeg az év vége felé jön.
Ugye a C++AMP egy koncepcionális rendszer a single source modellre, ahol a programot mindenhol futtathatod. Ami változó lehet, hogy a forráskódodból hogyan lesz olyan gépi kód, ami majd fut. Erre ma ott a DirectCompute, de maga a C++AMP számára ez nem feltétel. Ha van valami más projekt, ami ugyanazt a kódot valamilyen más úton eljuttatja a hardverre, akkor lehet fejleszteni. Jelenleg a DirectCompute mellett fut a CLANG projekt, amivel LLVM-IR->HSAIL, vagy SPIR1.2->OpenCL driver fordítással is futtatható ugyanaz a C++AMP forrás az adott hardveren.
Ezt elsősorban Linuxhoz fejlesztették, de semmi akadálya a Windowsos implementációnak. Erre építi fel a rendszerét az AMD. Nekik bármilyen fordítás jó a Kaverihez, ha végül egy HSAIL kódot kapnak. -
LordX
veterán
Szerintem Abu itt valamit félreért: Windowson a VS2012/13 fordítóját használja mindenki C++AMP-ra, ami jelenleg HLSL bytekódot csinál, amit majd a különféle vendorok drivere kap meg futásidőben. A Clang fork az csak Linuxon érdekes (amúgy sincs még olyan Clang Windowson, ami nem halna meg arra az egy sorra, hogy #include <windows.h>).
-
LordX
veterán
... és mit meg nem tennék azért, hogy ezt az OpenCL static C++-t a Khronos felemelje a standardba, hogy ne kelljen egy hülye minimalista nyelvben dolgozni..
A Bolt azt fogja használni, amit mondasz neki. Külön namespace a ::bolt::cl és a ::bolt::amp, nincs mechanika, ami automata kiválasztaná, hogy min menjen - amúgy is fordításidejű kérdés, nem futásidejű, úgyhogy sok értelme nem is lenne, és még egy lapáttal rá, hogy más is a két rész API-ja (kernel kódrészlet írásához AMP oldalon C++11, míg CL oldalon csak C99 támogatott, érthető okokból).
A Clang alapú C++AMP rendszer fejlesztését itt lehet követni (mai a milestone 2
). De ennek inkább a Linux támogatás a célja, nem az AMD hardverek "direkt" C++AMP támogatása (konkréten egy HD4000-en működget nálam). -
orbano
félisten
ok, a tavasz nekem még nem akkora para, eleve csak áprilisban indul a projekt, addig csak felmérek. kb mikorra várható az AMP-os vonal fejlődése?
egyébként nem teljesen világos nekem, hogy ebben mit cserél és hogyan az AMD. A M$ SDK-ja mellett lesz majd egy AMD-s verzió is? VS12/13 azt ugyanúgy fogja támogatni (profiler, debug, amik miatt a legszimpibb ez a vonal), mint a M$ félét? Lehet hülyeséget kérdezek, de ez a rész nem teljesen tiszta nekem.
Köszi -
#659
humilislupus
tag
adamssss
#20
humilislupus
tag
Nagyon tetszett a gyakorlatias hozzaallasod a Kaverihez. Gep epites elott allok es olvasgattam a hozzaszolasokat,de ez volt az elso igazan gyakorlatias megkozelites. En laikus vagyok hardver teren,minden igyekezetem ellenere.Hadd kerdezzem meg toled hogy az altalad emlitett ddr4 memoriak erkezese mikorra varhato. Egyik angol oldalon azt irtak hogy a 2500 ast is tamogatja... Persze teljesen igazad van benne hogy az nagyon megdragitana a rendszert,ami egyenlore onmagaban sem olcso.
-
Abu85
HÁZIGAZDA
Nekik OpenCL static C++-uk van. Ez van az APP SDK-ben. Például a legújabban. Mivel úgyis a Kaveri funkcióit akarja kihasználni, így édes mindegy, hogy a kód portolható-e más hardverre.
(#656) orbano: A Bolt ma leginkább OpenCL-lel működik. A C++AMP-hez van támogatás, de ha van OpenCL driver, akkor inkább azt használja és a C++AMP-t helyezi háttérbe.
Az új Catalyst nagyfrissítés lecseréli az OpenCL részt. Az AMDIL helyett lesz a HSAIL, és az ehhez kapcsolódó funkciók. Ez lesz első körben.
A C++AMP-hez olyan rendszer lesz az AMD-nél, hogy a CLANG LLVM-IR kódot készít és abból lesz HSAIL kód. De ez nem tavasszal lesz. Tehát egy ideig marad a DirectCompute elérés.Persze lesz új AMP, az MS is arra megy, amerre az OpenCL. Jönnek az integrációhoz kapcsolódó fícsőrök.
-
orbano
félisten
-
LordX
veterán
Hátőő, ez azért nem pontos.
Egyrészt a wrapper az kb. senkit nem érdekel, hogy C++, mert az egész OpenCL kód kb. 1%-a lesz az, magát a számítást meg írhatod C-ben (AMD-nek van egy nem portolható OpenCL C++ változata). Másrészt semmit nem wrappelnek pluszban AMD-ék, az a wrapper API egy-az-egyben a szabványban leírt C++ bindings. Nem "a legújabban van már", hanem már a legelső verziótól kezdve, mindegyik vendortól van.
A BOLT megint csak egy library - C++ interfész, OpenCL vagy C++AMP implementációval. Annak jó (de nagyon), aki nem akar belemászni mélyre, viszont ha bonyolultabb dolgokat akarsz leprogramozni, nem lehet kikerülni a 3 nyelv (CUDA, OpenCL, C++AMP) egyikét.
-
orbano
félisten
aha, tehát az új catalysttal már mondjuk a cppamp alatti driver is okosodik? nem sürgős nekem most ez a dolog, egyelőre csak tanulmányozom az ampon keresztül az egész kncepciót, és hogy hogyan lehetne ráhúzni az algoritmusainkra (elég bonyik, nem túl triviális a párhuzamosítása, még procira is problémás néhol), szóval van időm várni.
ez a Bolt library viszont szimpatikus. -
Abu85
HÁZIGAZDA
A Kaveri előnyeit a mai napon csak az OpenCL-en belül a cl_amd_svm és cl_amd_hsa kiterjesztésekkel lehet használni.
Gondolom az AMP-ben leginkább a C++ hasonlóság húz. Ez igazából OpenCL-ben is megoldható. A legújabb APP SDK-ban van C++ Wrapper API a Khronos C++ bindings-hez.
Esetleg próbáld ki a BOLT-ot. Ez nagyon hasonlít a C++-hoz.
Ezeket a mostani hardverekkel is kipróbálhatod. A komolyabb munkához majd a tavasszal érkező Catalyst szükséges. Az már nem csak a fenti két kiterjesztést tartalmazza, hanem le lesz cserélve benne szinte minden a compute részlegen. -
orbano
félisten
Köszi, így már világos minden. Tehaát az opencl lenne a legoptimálisabb megoldás számomra, de ettől függetlenü ha most cppampozok, azzal is ki tudom használni valamelyest a Kaveri előnyeit, vagy mindenképpen kell az opencl-es kiterjesztés, hogy többet érjen egy HD4600-as i7-nél? egyelőre húz a szívem az amp felé, ismerőseb terepnek néz ki, mint a többi, és egyelőre csak egy oldalhajtása a projektünknek a hardveres optimalizáció.
-
Abu85
HÁZIGAZDA
Még nem létező dolgok. Egyelőre 256 bitig létezik.
A SIMD-re írt kódokban lehet a fordító autovektorizálására támaszkodni, vagy ha hatékony kód kell, akkor van intrinsics, ami lényegében lehetővé teszi, hogy a programozó manuálisan vektorizáljon. Ezzel jóval hatékonyabb kód írható, de sok időbe kerül. Egy csomó cég (például az Adobe is) ezért hagyta rá az AVX projektet, mert már 256 bitre is nehéz hatékony kódot írni. Helyette OpenCL-re tértek át. Ezzel automatikusan képesek kihasználni az AVX-et, ha az adott OpenCL driver támogatja.
Ez lényegében az Intel javaslata is. Ha nem megy az intrinsics, akkor az OpenCL egyszerűbb és abban kell írni a kódot. -
lenox
veterán
Mezei gepben meg nyilvan csak 256 bitig van. Es amugy aki nem akar kezzel optimalizalni az hasznaljon valamilyen libraryt. Mindig feladatfuggo, hogy mi a jo megoldas. Kezzel vektorizalni az mindenkepp idoigenyes, szerintem sok fejlesztonek tetszene amugy, csak keves projektbe fer bele, hogy ezt az idot kifizesse valaki.
-
LordX
veterán
A Java8 ugyanúgy nincs még kint
Enszuke: AVX512 majd 2015-ben a Knights Landing-ben lesz, és úgy tűnik semmi másban a roadmap szerint. Potom 1,5 év múlva futni is fog az a "kézzel optimizált" kód, egy darab kizárólag szerverre tervezett chipen...
(ááá, neeeem, nem vagyok szkeptikus iránta, honnan gondoljátok? ) -
Abu85
HÁZIGAZDA
A legjobb az OpenCL, de ha nem akar azzal szenvedni, akkor a Java is használható. Az eléggé magas szintű nyelv.
Semmi gond. A Java 8-hoz készülő Aparapivel használható a Lambda is.(#645) Enszuke: Dehogy akarnak kiszállni, csak több tucat céget győztek meg arról, hogy a HSA az egyetlen reális irány. Mivel ezek a fejlesztők biztosítják a támogatását, így mostantól csak APU-kat készítenek.
Igazából két általános irány feszül egymásnak a piacon. Az Intel szempontja, hogy az aktuális toolokat és API-kat meg kell őrizni, de cserébe kézzel kell sokszáz bitre vektorizálni. Minden más hardvergyártó inkább arra megy, hogy legyenek új toolok és API-k, de a hardver programozása legyen könnyű. Erre van a SIMT modell. Nem kell vektorizálni és szálakkal törődni. Amire koncentrálni kell, hogy mindig legyen elég feladat, amit megfelelő mennyiségű szálra helyezhet a hardver.
Ezt ez egész irányzatot leginkább az fogja eldönteni, hogy a fejlesztők képesek-e vagy akarnak-e kézzel optimalizálni 512-1024 bites vektorokat, ezzel hatékonyan kihasználni az AVX új verzióit, vagy ez már túl sok nekik és elmennek az új modellek felé.
-
LordX
veterán
Aparapi szintű támogatás Python meg Matlab és társaihoz is van, és Java 8 lambdák nélkül minden, csak nem egy kényelmesen használható API. Nagyon nem tudok azzal egyetérteni, hogy GPGPU-hoz ma ez a valami lenne "a legjobb" opció. Egyrészt az, hogy mi jobb, az feladatonként és emberenként változik, másrészt Aparapiban kb. zéró library érhető el, ami egy programnyelv hasznosságának top3 (ha nem top1) szempontjai közé tartozik: Itt a CUDA nagyságrendekkel vezet, utána OpenCL, majd C++AMP, minden más masszívan hátul kullog. Olyan nyelvet megtanulni, amiben majd mindent implementálhatsz magadnak nulláról, minden, csak nem produktív.
C++ alapoktól kiindulva (amit orbano írt) a C++AMP-ot magasan a legegyszerűbb megtanulni, az OpenCL is csak egy mikronnal bonyolultabb, mert meg kell érteni a host oldali kódot is.
-
Abu85
HÁZIGAZDA
A Java 9 csak az a verzió lesz, amibe beépül a HSAIL kódgenerálás. Addig van ma Java 7-hez Aparapi, ami az OpenCL-t használja, vagy az év közepén lesz a Java 8-hoz olyan Aparapi, ami már HSAIL kódot generál, csak nem a Java Runtime-on belül. Tehát ma már tudsz a Java-ban GPGPU kódot írni. Nagyjából fél éven belül tudsz olyat is írni, ami kihasználja a HSA előnyeit. Ha nem akarja megtanulni az OpenCL-t vagy a C++AMP-t, akkor ma a Java a legjobb opció a GPGPU-hoz.
(#640) orbano: A Mantle is HLSL-t használ. A DX nem a DirectCompute miatt lassabb. Szóval, ha ebből a szempontból építesz a rendszerre, akkor nem kapsz túlzott büntetést az API-tól. Sőt, szinte semmit. Szóval a C++AMD a DX problémáitól, amire a Mantle reflektál nem szenved.
Ha gyakori kooperációt csinálsz, akkor ma az OpenCL a legjobb, és használhatod a CL_AMD_SVM és CL_AMD_HSA kiterjesztéseket. Ezek hUMA, hQ és Platform Atomics funkciókat kínálnak ma. -
LordX
veterán
OpenCL esetében meg SPIR kódot futtat a driver (Azt hogy a SPIR-t kaptad, vagy a driver állította elő, az más kérdés). A HLSL és a SPIR között nincs értelmezhető különbség, ami teljesítményproblémához vezetne, ha mindkettő ugyanolyan minőségben van implementálva a driverben, akkor mindkettő ugyanolyan jó lesz. Ami overhead van egyiknél, az a másiknál is meglesz.
Egyébként meg próbáld ki a Linuxos implementációt, azzal ezt a teóriát ellenőrizni is tudod.
-
orbano
félisten
Azért tartok csak a M$-féle C++ AMP implementációtól, mert HLSL kódot fordít és eleve a directcompute-ra épül, és nem tudom ebben a környezetben mennyire tud kidomborodni a kaveri képessége, egyáltalán látok-e majd érdemi javulást mondjuk egy core i7-hez képest, aminek ha jól tudom eddig jobban feküdtek az olyan kódok, ahol a gpu és a cpu sok közös adaton dolgozott, ráadásul cpu erőben ez utóbbi azért jóval erősebb. mondjuk ez érdekel legkevésbé, kipróbálom mindkettőn, aztán meglátjuk 1 wattra vetítve melyik produkál jobbat (ahogy a dolgok állnak, lehet egy 10-20 gépes kis fogyasztású, de hatékony gépekből összerakott clusterrel jobban járok, mint egy brutál munkaállomással, amire eddig terveztük a programot).
lényeg a lényeg, akkor maradok az AMP-nál, kísélreti projektnek mindenképpen jó lesz.
javában nem bízom, a cpu rész is nagyon kell, ha pedig már "interpretált" nyelv, akkor nem dobnám el a C#-ban szerzett 10 évnyi tapasztalatomat. úgyis az a terv, hogy a k+f az megy C#-ban, mert eszméletlen gyorsan lehet dolgozni, a "production" verziókat pedig C++-ban íjruk, ott lehet rendesen finomhangolni. Szerintem ez önmagában nagyobb gyorsulás, amint amit a GPU bevetése tud okozniLordX: arra gondolok, ami miatt a Mantle is gyorsabb, mint a DirectX. A restict csak a shader nyelvre való lebutítást oldja meg, ahogy fentebb írtam, abból a Microsoft fordítója HLSL kódot fordít, amit utána a DX-en keresztül futtat a VGA drivere. És mivel olyan kódom lesz, ami nagyon ki van élezve a gyakori CPU-GPU kooperációra, félek, hogy az overhead pont elviszi a plusz teljesítményt.
-
LordX
veterán
Java 9? Komolyan? Egy olyan nyelvet javasolsz, amit két év múlva terveznek kiadni? Amikor csak JDK lesz, de a többi toolnak még min fél év kell hogy támogassák, még fél év, hogy értelmesen használható is legyen?
orbano: C++AMP az jó stuff. Nem tudom mit értesz "natívabb app" alatt, mert az OpenCL ugyanúgy intermediate nyelvet használ, mint a C++AMP, gyakorlatilag egyedül az Intel MIC programozható natívan a heterogén rendszerek közül (és a KL már nem is lesz heterogén, de ez más téma..), a restrict(cpu) rész meg ugyanolyan natív kódra fordul, mint egy hagyományos C++ kód (merthogy az is). Az AMP driver csak az AMP részért felel, a teljesítménycsökkenés max abból jöhet, hogy a gyártó drivere gyengébb erre, mint OpenCL-re (a la CUDA vs OpenCL az nVidiánál). Linuxon még ez se lesz igaz, mert úgy tűnik direkten SPIR-re vagy HSAIL-re lesz ott a C++AMP fordítva, amint elkészülnek a toolok, úgyhogy pontosan ugyanazt a teljesítményt fogod kapni, mint OpenCL esetében (feltéve persze, hogy a fordító ugyanazt generálja, és nem rak bele extra hülyeséget AMP esetében).
-
lenox
veterán
Szerintem az opencl is ugyanolyan konnyu vagy nehez, mint a c++ amp, mert ugyis a mogotte torteno dolgokat kell megerteni, az api az egyik sem nehez. Eleg utos a kaveri, a memoria savszel bekorlatozza, feladattol fuggoen nagyon vagy kicsit. En nem szaroznek a helyedben, hanem nyomatnam, a kaverihez kepest ugyis mar csak az eros dgpuk tudnanak lenyegesen tobbet. A hsa-val szerintem meg nem erdemes foglalkozni, legalabbis ha holnap szeretnel mukodo kodot, ami esetleg tobb platformon is elindul, akkor nem az lesz a baratod, ha akar a c++ amp-ot, akar az opencl-t jol nyomod, akkor konnyen at tudsz terni barmire...
-
Abu85
HÁZIGAZDA
A C++AMP-hez teljesen jó, ha az adott program számára megfelel a platform tudása. A HSA-hoz ez amúgy is jobb alternatíva, mert minden C++AMP kód hatékonyan fordítható HSAIL-re. Amint lesz rá driver a régebben megírt alkalmazások automatikusan használják majd a Kaveri extráit.
A HSA alapítvány gyakorlatilag végzett az alapokkal. A 0.95-ös verzió az első kész HSA-PSA szabvány. Az elfogadásra vár. De pár hónap és elfogadják az 1.0-t is, ami a második nagy frissítés. Ez még a working groupnál van, tehát még változhat, de elég nagy az egyetértés, meg eleve csak kis frissítés az első verzióhoz képest, főleg a multi-user környezetekre.
Jelenleg a HSA Runtime/Tools van fejlesztés alatt, amelyek lehetővé teszik, hogy Java és natív C++ felületen is programozhasd az APU-t, vagy akár HTML5-ben is. Addig a 0.95-ös HSAIL-re és specifikációkra lehet építeni. Az AMD már csinált is OpenCL-es cl_amd_svm és cl_amd_hsa kiterjesztéseket. Ezeknek a módosított verziói benne is lesznek az OpenCL 2.0-ban, de a HSA-t támogató ARM-os gyártók valszeg az AMD kiterjesztéseit használják majd, mivel azok fejlettebbek.Ha HSA-ra akarsz dolgozni, akkor a Java tanulását javaslom. A befektetett erőforrásokhoz mérten a Java 9 lesz a legegyszerűbb nyelv a HSA képességeinek kihasználására, és a sebesség is elég jó lesz, mivel a HSAIL a Java Runtime része lesz.
A HPC-re majd később koncentrálnak APU-kkal. Oda egyelőre elég a sima dGPU. A Berlin APU a szervereknél az olajkitermelést, a Hadoopot és a különböző offload eljárásokat célozza, itt a különálló memóriák miatt a dGPU nem ad jó eredményt, és a HSA pont ezt a gondot eliminálja.
-
orbano
félisten
Egyébként C++ AMP vonalom mennyire érdemes próbálkozni ezzel a procival? Úgy gondoltam ez a platform elég rugalmas, a C++ miatt ismerős terep, így ha erre fejlesztek, azt kis munkával ki tudom próbálni a Kaveritől a "Larrabee"-n át bármint, de nem tudom mekkora teljesítményvesztéssel jár egy natívabb apihoz képest, torzítaná-e ez az összehasonlítást. Egyelőre nekem ez a Kaveri nem tűnik annyira ütősnek, hogy rá merjem tenni a voksomat, és megtanuljak csak emiatt opencl-ben, vagy majd az új hsa-s csodaplatformon dolgozni (november óta semmi infó, semmi mozgás az alapítvány oldalán, ami azért vicc).
egyébként nem volna ez rossz, dupla ennyi tranzisztorra, 200w-os tdp-vel egy pciex kártyán, 4-et bepakolva egy gépbe. nagyon nagy volt a szájuk, hogy hpc piac száját elkenik ezzel, mert új területeket hódítanak meg vele, de azért ez ahhoz nekem elég csirkének tűnik így. vagy tévedek?
-
jocomen
aktív tag
Javítottam: "Amíg nincs szoftver ami érdemben kihasználná, nincs értelme kapkodni a teszttel, és a megvásárlásával sem, szerintem."
"A 3DMark, Libreoffice, Jpeg dekodolo nem eleg ahhoz hogy nagy eladasokat generaljon."
Szerintem ez nem elég ahhoz, h bármiféle eladást generáljon. Csak arra, h az emberek észbe tartsák: valami készül az amd-nél, majd érdemes lesz visszanézni hozzájuk úgy 1 év múlva. De addig is...... intel
Amúgy mikor jön ki valami értelmes program hsa-val? Mondjuk játék.
És ami támogatja a mantle-t, az automatice a hsa-t is, vagy hogy lesz ez?
És a hsa-s "nem játék" programok, nem gyorsíthatóak-e dvga-n is ugyanúgy, mint az apu-n? -
Engem egy 5ghz es érték érdekelne léggel full hd felbontásban egy i 5 höz képest ... ha nincs különbség (1-3 fps ) nem nevezném annak (1024 es felbontás nem érdekel)
átlagos használatra ez is elég cs szerveremre aki feljár régi géppel tolják vagy laptoppal ... így ránézésre az árral van gond főlegszvl egy olcsó áron akár jó is lehet...feautures részét úgy sem használjuk ki ...
aki videót vág úgy is i7 et vesznekem most egy 2 magos procim van amit 16 ért vettem 3 éve és 4 magosítva megy szarrá húzva ... megint kéne valami hasonló über amds- ajánlat
Jó lenne ha bele húznának mert lassan ideje lenne gépet cserélnem
-
nyunyu
félisten
Szerintem nezz utana a dolognak kicsit alaposabban: az Itanium futtatja az x86 szoftvereket minden gond nelkul, csak nem tul gyorsan.
Az a nem tul gyorsan az eleg enyhe kifejezes ra.
Amikor kijott az elso Itanic, x86 emulacioban kb. egy Pentium 100 teljesitmenyet hozta.
Akkoriban mar 1GHz-nel tartottak a P3-ak. -
jocomen
aktív tag
Jó lenne látni valami mantles / hsa-s játékkal is, h végre eloszoljon a misztikus homály, és lássuk feketén fehéren mire képes. Amíg nincs szoftver ami érdemben kihasználná, nincs értelme kapkodni a teszttel, szerintem. Ami csak "proci+vga"-ként használja, olyat meg már láttunk.
-
#608
hugo chávez
aktív tag
Abu85
#606
hugo chávez
aktív tag
"Az x86 addig jó, amíg nem próbálja meg egy cég valami hatalmas butaságra használni."
No igen, adatpárhuzamos végrehajtásra való egységhez nem túl jó, ez egyértelmű. Az már kevésbé, hogy ezt pont az Intel miért nem látja be...
Bár nekem az jön le az eddigiekből, hogy a majdani Intel APU-kban is ugyanúgy meglesznek a hagyományos, késleltetésre optimalizált magok, csak lesz mellettük egy AVX512+ képes SIMD tömb is, mint ahogy most a Kaveriben a hagyományos modulok és mellettük a GCN IGP...Viszont egy tisztán "parallel ISA" meg megintcsak nem lenne jó egy APU-hoz, csakis a Larrabee-hez hasonló MIC-ekhez, amikben nincsenek "igazi", nagy teljesítményű, kevésszálas végrehajtásban erős LOC-k...
Akkor viszont, létezik-e egyáltalán olyan ISA, ami egyformán jó a LOC és a TOC részhez is, avagy érdemes lenne-e csinálni egy ilyet, vagy nem és elég a meglévő ISA-k (pl. az x86) reszelgetése és a TOC rész meg használja a saját ISA-jét, amire meg úgy is megy egy vISA réteg (pl. HSAIL), hogy ha drasztikusan változik az ISA, mint ahogy a mostani GPU-knál is szokás pár évente, akkor se legyen gond? -
ukornel
aktív tag
"Meg mindig nem valaszoltal ra miert koltot az Intel milliardokat Itaniumra ha olyan jo volt a sajat slagertermek X86"
Erre két válasz is van, melyek közül Fiery csak az elsőt említette:
1. fejlettebb architektúra megalapozása
2. olyan architektúra elterjesztése, amihez az AMD-nek nincs licenszeMivel az AMD a 64 bites kiterjesztéssel lehetővé tette az x86 továbbélését, a 2. válasz, mint cél teljesíthetetlenné vált az Intel számára. Ezért kénytelenek voltak az 1. célra fókuszálni, de anélkül, hogy az x86 kereteit elhagyták volna. A mai x86/64 architektúrák szerintem nem számítanak elavultnak a rengeteg új, korszerű utasítással.
-
#606
Abu85
HÁZIGAZDA
hugo chávez
#595
Abu85
HÁZIGAZDA
válasz
hugo chávez
#595
üzenetére
Igazából semmi baja. Az x86 addig jó, amíg nem próbálja meg egy cég valami hatalmas butaságra használni. Ennek az ISA-nak az tett be, hogy az Intel 2003 óta próbál a Larrabee-be életet lehelni, de nem megy. Akik a projekten dolgoztak azt mondták, hogy az x86 ISA elavult. Innen indulhatott el a le kell cserélni, mert szar hype. De valójában nem az.
A Larrabee koncepciójával az ARMvv8 sem viselkedne másképp. Andrew Richards sem azt értette, hogy az x86 univerzálisan fos, csak arra gondolt, hogy egy bizonyos magszám fölött, megfelelő méretű gyorsítótárak és cache-szervezés nélkül abszolút nem működik. John Gustafson amíg a Larrabee-n dolgozott ezért próbálta az Intel vezetőségén lenyomni azt, hogy készítsenek saját parallel ISA-t, és térjenek át a SIMT hardverre. -
Abu85
HÁZIGAZDA
válasz
#32839680
#589
üzenetére
Nem hülyeség. Az reális, hogy az x86 ISA a mag méretéből 2-3%-ot jelent. Más ISA is kb. ennyit jelent. Itt a strukturális működésben van a különbség. Az x86 egy skalár ISA, amit CPU-khoz terveztek. Tehát ahhoz, hogy skálázódjon marékszámra kell dobálni a gyorsítótárat a lapkába. Egy parallel ISA enélkül is skálázódik. Tehát az Intel a Larrabee koncepciójával ott veszít igazán, hogy nekik magonként kell a minimum fél megabájtos gyorsítótár, különben a rendszer nem működik. 2 MB/mag lenne az optimális, de az nehezen kivitelezhető ma.
Az Intel ott spórol sokat, hogy a Larrabee koncepcióban nincs programozható L1 gyorsítótár, és sok regiszter sem. Legalábbis a hagyományos GPU-khoz viszonyítva ilyen szempontból nagyon vérszegény a hardver.
-
Fiery
veterán
válasz
#32839680
#582
üzenetére
"Minek kell bootolnia egy 2014-es hardveren a DOS-nak? Minek nem védett mód? Minek 16 bites üzemmód?"
Minek kivenni, ha minimalis overhead-et jelent? Ezek mar nem a 486-os idok, hogy egy-egy ilyen feature elviszi a die area 10 %-at
"az Itanic azért volt bukás mert 100%-osan elvetette a kompatibilitást a korábbi x86 procikkal, semmilyen régebbi alkalmazás nem futott rajta, ezt persze hogy nem nézik jó szemmel."
Szerintem nezz utana a dolognak kicsit alaposabban: az Itanium futtatja az x86 szoftvereket minden gond nelkul, csak nem tul gyorsan. Az AIDA64 is fut Itaniumon, a CPU-Z is
-
Prof
addikt
válasz
Mercutio_
#537
üzenetére
Nem erzem magam sarokba szorultnak egyaltalan, csak ugy erzem mintha falnak beszelnek. Probald ki mondasz vkinek valamit es 3-szor el kell mondani neki 3-idkra se erti tuti felemeled a hangod, mas stilusban mondod 4-edszer.
Hat szerintem Pistike jobban szeretne olyan desktopot/HTPC-t amin 30-as minimum fps-el jatszogat a 120 dollaros Kaverin FullHD Skyrim-et, ami 18 a richland-al es 13fps a dupla aru, fogyasztasu i5-el.
30 min. fps FullHD Skyrim 45W AMD Kaveri APU
Mindezt ugy, hogy alapvetoen nem errol szolnak a Kaveri forradalmi ujdonsagai es valoszinu a drivereken is van meg mit csiszolniNincs semmilyen keskeny sav, lehet felbontast es grafikai reszletesseget is allitani a jatekokban. Ahogy mondtam onmagaban kompromiszumokkal jo mindenre.
Aki nem akar kompromisszumot 500 ezerbol epit gepet nem 100-bol. Amugy meg mar azt is tobbszor elmondtam, hogy arakrol/konfig epitesrol nem erdemes uj termek bevezeteskor beszelni. (se nem kaphato, se nem adjak ujdonsag felar nelkul.) es ez a topic meg mindig nem a termek tesztje, hanem egy technologiai elemzes.
Amugy meg mindenkinek mas szempontok ernek meg X penzt, semmi ertelme errol itt beszelni, meghatarozott celok ismerete nelkul (mire kell a gep vkinek/mi fontos neki). Barmelyik ovodas osszetudja adni az alkatreszarakat, de Kaveri eseteben (kulonosen A8) nem tudja oket megvenni meg annyira uj a cucc.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha azonban a szoftver keszitojet nem tolja egy gyarto sem, hanem szabadon mokolhat, akkor furcsamod lehet lenyegeben platformfuggetlen OpenCL kodot kesziteni. Oke, lehet hogy lesz benne 1-2 elagazas, de nem tobb szaz, es nem tobb, mint mondjuk egy nativ x86/x64 kodban.
Új hozzászólás Aktív témák
- A magas vérnyomást is felismerheti az Apple Watch Series 11
- Kézbe fogható paradoxon lett az iPhone Air
- Merész dizájn és új teleobjektív az iPhone 17 Pro mobilokban
- Bluetooth hangszórók
- Kerékpárosok, bringások ide!
- Gusztusos, 11 literes térfogatú Jonsbo ház jött a kompaktabb vasakat kedvelőknek
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Azonnali fáradt gőzös kérdések órája
- Minecraft
- Gyúrósok ide!
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 13 mini 256GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3311
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Hp Prodesk 600 G3/ G5/ G6 SFF/ i5 8-9-10 gen / Elitedesk 800 G4 /Win11- Számla, garancia
- Samsung Galaxy Z Fold 7 Újszerű állapot, hajlítható csúcstechnológia 12/512 GB Gyári garanciával!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest