- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- Vezetékes FEJhallgatók
- Fujifilm X
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- HiFi műszaki szemmel - sztereó hangrendszerek
- Androidos fejegységek
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Melyik tápegységet vegyem?
- Amlogic S905, S912 processzoros készülékek
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
Hirdetés
-
Egyre közelebb a Poco F6 startja
ma Újabb ár/érték csatát nyerhet a Xiaomi almárka.
-
VR játék lesz az Batman: Arkham Shadow (Meta Quest 3)
gp Egyelőre csak egy teaser trailert kaptunk a teljes leleplezésre a Summer Game Festen kerül sor.
-
Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
ph Megkezdődött az NPU-k elleni hadjárat, de egy fontos részletet nem említ a cég.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Ha ránézel a képre, akkor láthatod, hogy az nem 128 bit. Legalább 256 bites szélességről van szó, tekintve, hogy a Richland memóriavezérlőjéhez képest kétszer annyi helyet foglal. Egészen egyértelmű, hogy ott van benne. Legalábbis nem hiszem, hogy az AMD ráphotoshoppolt még 128 bitet, hogy így vezessen félre mindenkit.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért ma már van úgy jó 200 OpenCL/C++AMP alkalmazás. Mi még kaptunk három HSA appot és béta HSA drivert. Bár ezek ma még nem publikusak.
A tesztrendszer majdnem felét amúgy is gyorsítható applikációkkal tesszük ki a jövőben, hiszen mindenki erre megy. Bár leginkább szabványos szinten, maradva az OpenCL-nél, de a HSA-t azért érdekességnek megnézzük.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Hát sajnos nem. Csak később lesz teszt. De cserébe jól kivégezzük.
A HSA-t nem szeretnénk belevonni, mert a béta appok eléggé a Kaverire lettek építve. Maximum megnézzük az elérhető gyorsulást, de az összehasonlításban nem lesz benne.
(#78) Fiery: Ja az egyik a LibreOffice, de a másik az AfterShot Pro, míg a harmadik az AMD JPEG dekódere, ami a windowsos verzió helyére készül. Esetleg még, ha megkapjuk a Switch playert. Az is HSA-s.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Publikus formában még nem létezik. A PS4-hez készült SDK-val jól használható a PC-s blokk.
Az technikailag publikus. De persze hamarosan hozzáférhető lesz a PC-s opció is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Van már SDK. Ha partner leszel megkapod. Aki támogatja az a PC-s SDK-val oldja meg a támogatást. De ha nem vagy partner, akkor a PS4-es SDK-ban ugyanolyan kódot lehet írni PC-re, amíg meg nem jön a publikus SDK.
A PS4 ugyanazt az API-t használja, mint a PC-s blokk. A kódok ide-oda szállíthatók. Bár az igaz, hogy elsősorban ezt a PC-s fejlesztők kapták fel, tehát ebből ma inkább a PS4 profitál, de később a PS4-re írt kódok is áthozhatók PC-re.
Bár a PS4-en a Sony ICE Teamnek ezzel a hardverrel sokkal komolyabb tervei vannak. Ezt nem biztos, hogy PC-n viszontlátjuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az OpenCL 2.0 nem gond. Az OpenCL 1.2-höz lesz számos HSA extension. Az OpenCL 2.0 ebből a szempontból ráér, mert amit kínál azt a fejlesztők specifikus kiterjesztésekkel már idén kihasználhatják. Sőt, ezek többet tudnak majd, mint amit az egész OpenCL 2.0 felkínál. Az Adobe, a Corel, és a többi partner jelezte, hogy nekik ez így is jó. Sőt, a HSA-nak lesz olyan kiegészítése is, ami az eddig írt OpenCL alkalmazásokat automatikusan a HSA hardver előnyeivel futtatja. Többek között így fut az Aftershot Pro. Ehhez az aktuális kód módosítására sincs szükség, egyszerűen out-of-box működik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Persze. A TrueAudio API még béta. De ettől már a partnerek megkapták, és ők számítanak az AMD-nek. A PS4 miatt igen sokan támogatják még, mert tényleg egyszer írod és másolod mindenhova elvű a dolog.
(#102) Fiery: Az AMD eleve nem elégedett annyira az OpenCL 2.0-val. Leginkább ezért készítik az extra kiterjesztéseket. Ezek később is nagyon hasznosak lesznek a HSA alapítvány tagjainak is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azt a Kaveritől semmi sem veszi majd el, hogy az első processzor, ami Cell-szintű integrációt kínál a PC-ben. Ugyanúgy nem vette el az Athlon 64-től sem a világ az első 64 bites PC-s processzor címét.
Nem mellesleg a konzolok miatt is fontos lépés a Kaveri. Ha a kiadó azt mondja, hogy azért butították a játékot PC-re, mert nincs olyan konfig, ami vinné (lásd FIFA14), akkor helyből linkelhető a Kaveri APU. Tehát elindult a PC-s felzárkózás a konzolok technológiai tudásához. Erre nem mondanám, hogy jelentéktelen. Ez az első lépés az új generációs élmény felé. Ez már önmagában is lényeges szempont.
Ez persze nem jelent 2015-ben kapásból next-gen FIFA-t, de mostantól van egy olyan PC-s hardver, amin futtatható az Ignite motor.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Minden termékben (Kaveri, VGA-k, PS4) 800 MHz-en üzemel a TrueAudio blokk, és mindegyikben három DSP van benne. Ergo a teljesítmény lényegében megegyezik. Persze a memória-sávszélesség eltérő, de a TrueAudio blokk erre nem érzékeny. A saját 64 MB-os szeletét mindenhol elkéri majd a memóriából.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Onion van csak, aminek két módja van, de amúgy igen.
Ugyanakkora sebességgel megy, mint a CPU elérése a memória felé, de csak koherens onion módban. Sima onion módban olyan lassú, mint a korábbi.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Kaveri 1.0-ból. A 2.0 már átdolgozta ezt. Ez sokkal hatékonyabban működik, ezért lett az 1.0-s opció eldobva. Abban egyébként közös cache lett volna a CPU és az IGP számára, de amint ráeresztették az IGP-t rögtön tele lett szemetelve a cache, és összedőlt a teljesítmény. Valszeg nagyjából ugyanabba a problémába estek bele, amibe az Intel a Sandy esetében, amikor az IGP szabadon írhatta az L3-at. Egyszerűen ez a koncepció sehogy sem akar működni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#262
Abu85
HÁZIGAZDA
antikomcsi
#247
Abu85
HÁZIGAZDA
válasz
antikomcsi
#247
üzenetére
Jó, de a Thief az Mantle-ready. Az IGP teljesítménye beszámít bármilyen dedikált GPU mellé. Világos, hogy a Mantle címek többségében a Kaveri+GCN dGPU konfigurációk viszik majd a teljesítménykoronát, de ezzel kapcsolatban eddig sem volt semmilyen kétely.
Sőt, a Thief speckó eset is, mert a TrueAudio hangélményét részben lehetővé teszik szimpla processzoron is. Na most ez szoftver szintjén max. minőségen nagyon durva CPU-t igényel, ha nincs hozzá dedikált hardveres blokk.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A két Kaveri egyértelmű. Nagyon sokáig Kaveri 2.0 volt ennek a belső kódneve. De ezt le is írtam a cikkben. Arról senki sem tud pontosat, hogy ez hogyan alakult így. Az AMD bár nem titkolja, hogy Kaveri 2.0 volt a belső kódnév, de azt nem mondják meg, hogy mi volt az 1.0.
Igazából a név mindegy. Ma koherens és nem koherens FCL (Onion) van.A PS4 és az X1 APU-ja nem úgy működik, mint a Kaveri. Ugyanazt támogatják, csak eltérő fizikai implementációval. Például a PS4-ről tudni, hogy abban van Onion+ (aka koherens FCL), de ott például használható az IGP L2 cache. Viszont ebben a módban minden más feladat direkten a VRAM-ba ír. Tehát a kettőt ez sem vegyíti, csak másképp oldják meg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#316
Abu85
HÁZIGAZDA
Menthirist
#263
Abu85
HÁZIGAZDA
válasz
Menthirist
#263
üzenetére
Ugye Mantle alatt nincs CrossFire kezelés. Vannak a fizikai GPU-k, és azokból csinál az API egy logikait, aminek a partíciói képviselik a fizikai hardvereket. Mivel az API-ra semmilyen normál AFR támogatás nem lesz, így a fejlesztőknek kell megoldani a multi-GPU-t egy saját stratégiával.
Az Oculus Rift az nehéz ügy. Zömében azért nem production ready a cucc, mert rengeteg játék driveres optimalizálása van kihegyezve az fps-re agresszív kötegeléssel. Számos alkalommal a játék közben azt érzed, mintha fejbekólintottak volna. De ha elengedik a teljesítmény jó részét a driverben, és a késleltetésre optimalizálnak, akkor DX/OGL alatt is jó az élmény. A Mantle-t csak azért emlegeti az Oculus CEO-ja, mert ott nem kell engedni a teljesítményből.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#321
Abu85
HÁZIGAZDA
Menthirist
#317
Abu85
HÁZIGAZDA
válasz
Menthirist
#317
üzenetére
Mindenképp szükséges a fejlesztőknek egy saját multi-GPU-s stratégiát kitalálni. Ha nem teszik meg, akkor a sima CF rendszereket is elfelejthetik.
De ez amúgy nem gond, mert a Mantle-nél ők kérték ezt. Tehát azt is belekalkulálták, hogy a multi-GPU stratégiát a saját effekjeikhez igazítják, és nem fordítva, mint a szabvány API-kon. AFR-t egyébként valszeg nem implementálnak. Pont attól akarnak szabadulni.(#320) Menthirist: A szédülés és a "fejbevágtak érzés" nem a termék miatt van. Ez tisztán szoftveres probléma. A driverekben nem szabad az agresszív kötegeléssel és puffereléssel növelni a késleltetést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem valószínű, hogy az a doksi eredeti. A PS4 APU-jának kódneve Thebe és nem Liverpool.
A Sony kérte ilyenre. Az AMD megcsinálta ilyenre. Ez a Sony terméke, ők döntenek arról, hogy miképp működjön.
A PS4-en a lényeg, hogy bármilyen feladat, ami nem ír a rendszermemóriába megteheti, hogy direkten írjon adatokat a leválasztott VRAM-ba és onnan olvashasson is (a Garlicon keresztül, ami RMB, de mindegy). Ez egy beépített mód a hardveren belül, hogy az IGP L2-ben a koherens adatok legyenek benne, és ne legyen mással összeszemetelve.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#325
Abu85
HÁZIGAZDA
Menthirist
#324
Abu85
HÁZIGAZDA
válasz
Menthirist
#324
üzenetére
A Mantle implementálása önmagában sokkal olcsóbb, mint a DirectX-é. Egy ember meg tudja csinálni két-három hónap alatt. Dokumentációval, példaprogramokkal ez az idő rövidülhet, illetve a konzolos optimalizálásokra lehet építeni.
Az egy dolog, hogy a Mantle kód a sorok számában több lesz, mint a DirectX kód, de az már olcsóbbá teszi, hogy optimalizálás nélkül, out-of-box szinten meglesz a sebesség, míg a DX-re sokáig dolgozni kell, hogy elérjék a kívánt tempót. A partnerek elsősorban ezért építenek rá, mert kevés erőforrás befektetését igényli. Persze biztos van benne egy kis fricska is az MS-nek és a Khronosnak, hogy kapkodják magukat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezt a CES-en mondta a Nixxes. A Thief hangzásvilágának nagy szerepe lesz játékmenetben. Amit lehet azt elérhetővé teszik sima processzoron is, ami szerintem jó döntés. Nyilván a processzoron a legfőbb gond, hogy nem garantált a biztos erőforrás, de valahogy majd ezen felülkerekednek.
Sajnos a magok kérdése nem olyan egyszerű. Nem azért nem használják ki a magokat, mert bénák. Az AC4 konzolon nyolc magra skálázódik lineárisan, eközben PC-n leginkább 2 magot használ. Pedig zömében ugyanaz a kód. Ez ma a nagy kihívás, hogy olyan kódot írj, ami PC-n is skálázódik. De sajnos a legtöbb esetben a fejlesztő hiába látja a szabad erőforrást, nem igazán tudja befogni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sajnos nem minden esetben. Rengeteget küzdenek az erőforrások hatékony kihasználása érdekében. Van aki persze nem, de a fejlesztők jó része igen. És sokszor van úgy, hogy tökre látják a szabad erőforrást, de nem tudják befogni. A legtöbb esetben a kiadó az asztalra csap, hogy itt az ideje kiadni és ennyi. Viszont a konzolokon az az érdekes, hogy többen is jelezték, hogy pöcre megy a nyolc mag hatékony kihasználása.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Mercutio_
#343
üzenetére
Kétmagos gépet már Radeonnal sem éri meg építeni. Minimum négy mag. Csak azért szólok, mert a Catalystnak is része lesz a teljes deferred context támogatás és az ugyanúgy működik, mint az NV-nél. Egy procimagot kisajátít, és ezzel kétmagos procin igencsak padlóra küldheti a teljesítményt. Legalább négy mag kell játékra még DX alatt is. Persze a deferred contextet valszeg kikapcsolhatod az adott játék konfigurálásával, de nem tudni, hogy melyikkel jársz jobban.
A négy mag (vagy legalább szál) mostantól a minimum, ha nem csak casual játékokban gondokodsz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Mercutio_
#345
üzenetére
Nem erről van szó, hanem arról, hogy nextgen szinten a játékoknál minimum lesz a négy mag, vagy legalább a négy szál. Bármi ami ennél kevesebb az lényegesen gyengébben fog teljesíteni, vagy el sem indul a program. 2014-et írunk, nyolcszálas konzolokkal a másik térfélen, eljött az előrelépés pillanata. A legtöbb játékos ma amúgy is négy szál futtatására alkalmas hardvert vásárol. A fejlesztők emellett többet költenek a deferred context megértésére is, ami alapvető eleme lesz annak, hogy a konzolról portolt játéknak a látótávolságát ne kelljen a PC-ben megkurtítani.
Szóval hacsak nem casual gamingről van szó, akkor négy szálnál kevesebbel nem gondolkodnék már. Az tök mindegy, hogy Intel vagy AMD, a programok ezt nem fogják nézni, csak a szálakat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Biztos lesz egy pár BF4/Thief maximalista január és február végén. Akár egy R9 290X mellé is társnak.
Ne higgyétek, hogy csak PR-ből nyomatták a Thiefet a CES-en A10-7850K+R9 290X-szel. Tényleg ezzel a párosítással lesz a legjobb. Semmi hókusz-pókusz persze, csak tipikus exkluzivitásra és szoftvertámogatásra épülő stratégia.
(#350) akoska07: Nem vagyok erről meggyőződve. Én úgy gondolom, hogy lesznek olyan fanatikusok, akik BF4 vagy Thief rajongók, és pár extra fps-ért hajlandók konfigcserére, de tömeges váltásra nem számítanék.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez idén bőven igaz lesz. 2014-ben lesz olyan játék, ami négy szálat, DX11-et és 64 bitet kér minimum. Kevesebbel nem indul el. De ez teljesen normális. Ma a célpiac 80%-ának, ha nincs is négymagos processzora, négy szálasa van. Akinek nincs, majd vásárol magának. Szinte mindegyik kétmagos PC bővíthető négymagosra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Mantle nem arra szolgál, hogy átvegyen a CPU feladatait. Maximum az occlusion culling terhe kerül le a CPU-ról, de ez megvan a mai szabvány API-kkal is (majdnem 7 éve) csak akkora késleltetést ad, hogy nem lehet használni. A Mantle csak ezt a késleltetést tünteti el, mivel eliminálja a CPU round-tripet.
Amire te gondolsz arra a HSA való.
A Mantle pont olyan grafikus API, mint a DX/OGL, csak a modern hardverek működését vették figyelembe a kialakításánál. Az igaz, hogy vannak benne funkciók, amelyek segítenek a hardver hatékonyabb kihasználásánál, de nem azért, mert xy feladatot mondjuk átrak a CPU-ról az IGP-re, hanem azért, mert nem 15 éves alapokra épül.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HSA első user oldali implementációja január végén kerül bele egy publikusan letölthető driverbe. A második frissítés az év közepén esedékes. Ez lesz a HSA (with WDDM) és az IOMMUv2 eszközök csomagja. A harmadik frissítés pedig a HSA runtime. Ezt a HSA alapítvány adja ki. Szimpla telepítő lesz, mint a Java runtime.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Pete55555
#525
üzenetére
A január végi driverben az AMD saját OpenCL kiterjesztései lesznek benne. Asszem a cl_amd_hsa és a cl_amd_svm. Az első körben érkező programok csak ezekre építenek (H.265 lejátszó, 3D techdemó, aktuális OpenCL programok frissítései).
Ez a driver tartalmaz gépi szinten kódolt HSA funkciókat is, hogy az új gyors JPEG dekóder és a Fluid Motion Video működjön.Az év közepén érkező drivernek a 2.3-as bétája is megvan nekünk. Az már combos implementáció. Arra kaptunk programokat is, mint a LibreOffice és az AfterShot Pro.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De várhatók. Már rögtön az elején elég sok korábbi OpenCL-es programot felfrissítenek az új kiterjesztésekkel. Erre tényleg elég az első körös driver reverzió.
Az általad felsorolt dolgokhoz nem HSA kell, hanem Mantle. Nem kell a terhet levenni a processzorról, csak ki kell használni a rendelkezésre álló erőforrásokat. Ma a játékokban leginkább ezzel van a gond, nem azzal, hogy az IGP-t nem fogjuk be xy feladatra. Persze utóbbit is befoghatjuk, de ez egy másik történet. Ezzel azért kell csínján bánni, mert egy játékban kihasználható az extra erő gameplay és eyecandy dolgokra. Utóbbi egyszerű, mert nem része a játékmenetnek, tehát skálázható. De amint valami a játékmenet része, onnantól az nem skálázható, tehát minden gépben kell a futtatásához kellő erőforrás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#32839680
#531
üzenetére
A Trinity és a Richland támogat pár nagyon alapvető HSA direktívát, de a fontos funkciókat nem. A Kabinit és a Temash limitáltan képes a hQ funkcionalitására. A fontos HSA direktívákhoz minimum Kaveri kell.
(#536) Fiery: Az is heterogén módon programozható processzor, amiben ugyanazt az ISA-t használják a kis és a nagy magok is. A program oldalán meg kell mondani, hogy a késleltetésre vagy az adatpárhuzamos végrehajtásra optimalizált magon fusson a feladat. Tehát az irányt tekintve mindenki ugyanarra megy, csak a hogyan részben vannak eltérések. Az Intel meg akarja tartani a jelenlegi SDK-kat és Library-kat, míg a többiek szerint inkább legyenek új koncepciók, de legyen könnyű a programozó dolga. Ez az egyetlen lényeges eltérés az Intel és a piac koncepciója között.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az SVM egy fontos fícsőr, de a platform atomics és a dynamic parallelism legalább annyira fontos. Ez a három így együtt érdekes.
2003 óta fejlesztik a Larrabee alapkoncepcióját, és még mindig nem működik jól. Jó persze várjuk meg a Knights Landinget, mert arra már jót mondanak, ahogy a többire is korábban, de akkor is nehezen tudom elképzelni azt, hogy a vezetőség felteszi csak erre az egész vállalat jövőjét. Azért ez olyan kockázati tényező, amit nincs értelme bevállalni. Főleg nem azután, hogy számos szoftvercég a nehéz programozhatósága miatt nem támogatja ma az AVX-et.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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é.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
ph Az új APU felkínálja az új generációs konzolok képességeit; a technikai újításokkal értelmet nyert az ATI felvásárlása is.
- Hibátlan - AMD Ryzen 5 2600 - 6 mag 12 szál 3.4GHz + gyári hűtő
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-
- AMD Ryzen 7 3700X processzor (használt)
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel