Új hozzászólás Aktív témák
-
jedis
senior tag
válasz
dergander
#264
üzenetére
Lehet hogy igazad lesz, de én nem tudom elképzelni, hogy az AMD csinált volna egy olyan 4 magos "modult", amiben ha van egy hangyaf.sznyi hiba, mehet a levesbe ! Főleg, hogy előtte meg olyan architektúrákat tervezett direkt, melyeket lehetett keresztbe kasul nyirbálni. Ahogy mondtam, az AMD nincs olyan anyagi helyzetben, hogy az ostyák akár 10-20%-át netán egyenesen a kukába dobja. Szépen gyűjti a "selejtet" majd ha már lesz egy teherautónyival, bedobja a piacra jóárasírva. Majd meglátjuk nohhh.
-
ukornel
aktív tag
"És szerinted eleve úgy tervezték meg ezeket a 4 magos komplexeket, hogy ha valahol egy apró hibás rész is van benne, kuka ???"
Mindenekelőtt szeretném leszögezni, hogy 1. Nem értek hozzá 2. Ha értenék is hozzá, az AMD akkor sem kötötte az orromra, hogy hogy tervezték. Csak pletykák alapján spekulálunk, és ezeknek a pletykáknak a valóságalapja erősen megkérdőjelezhető, ahogy azt korábban is kifejtettem.
Visszatérve a kérdésedre, ha még ezek után is érdekel a véleményem, szerintem nem kuka, hanem beállítja alacsonyabb órajelre, amin még stabilan jár, átnevezi, és valamivel olcsóbban eladja. Ha jól tudom, az Intel is így csinálja, legalábbis a mobil és a HEDT alatti asztali szegmensben: nem dobnak piacra két-három magos procikat a négymagos lapkák nyesegetésével, vagy egymagos processzort a rosszabbul sikerült i3 gyengébb felét letiltva. -
jedis
senior tag
És szerinted eleve úgy tervezték meg ezeket a 4 magos komplexeket, hogy ha valahol egy apró hibás rész is van benne, kuka ???
Ez gazdaságilag, és logikailag is elég értelmetlen húzás volna az AMD-től, akinek most minden morzsányi szilícium számít. 
Lesznek itt még az év vége felé két, meg három magos Ryzen Athlonok ( non. L3 ) is meglásd ! -
ukornel
aktív tag
Csak a félreértés elkerülése érdekében írom: a Ryzen sem modulos abban az értelemben, ahogy pl a Bulldozer család modulos volt, architekturális szinten. A Zen magok egymástól független, önállóan működni képes egységek. Gyártásuk viszont négymagos komplexekben történik, melyben a magok közötti hatékony összeköttetés biztosított, és az ilyen négymagos összekapcsolása is lehetséges - így jönnek létre a 8 magos Summit Ridge, ill. a 32 magos Naples CPU-k. Azt mondják - forrástól függően -, hogy ezeknek a négymagos komplexeknek a megbontása (egy vagy több mag letiltásával) nem hatékony, vagy nem kifizetődő, vagy nem lehetséges.
Mondjuk, ezek még most is csak pletykák.
Régebben azt is állították, hogy az SMT a Zen architektúra alapvető sajátossága, ami minden processzorban aktív lesz. Most pedig már biztosra veszik, hogy az SMT letiltása a termékskála bontásának egyik kulcsa lesz. -
jedis
senior tag
"a Zen csipek 4 magból épülnek fel, amelyeket ha összeraknak, akkor értelemszerűen 8 magosak jönnek létre"
Nem hiszem, hogy a gyártás során ne keletkeznének olyan hibás modulok, melyben egy mag nem stabil a négyből. Főleg egy új csíkszélességre váltásnál, mikor még kiforratlan a technológia .Szerintem biztos lesznek olyan modulok, melyekben az egyik mag nem stabil. Azzal akkor mit csinálnak ? Kidobják ? Mert ahogy írták, csak 4, és 8 magosak lesznek, HT-val, meg az nélkül.Vagy vesznek még egy ilyen hibás modult, és az előzővel együtt, a három jól működő magból még letiltanak 1-1 magot, és összetokozzák őket 4 magosnak , mely a legolcsóbb procijuk lenne ???
Nem kimondottan lenne gazdaságos, nohhh ! Szerintem ezeket szépen megcsinálják ők 6 magosnak ( 2x6 ), és mikor összegyűlik annyi mennyiség ( nem 1-2 ezer ) , akkor piacra dobják, mondjuk olyan nyár körül ! -
core i7
addikt
-
#255
ukornel
aktív tag
Petykemano
#254
ukornel
aktív tag
válasz
Petykemano
#254
üzenetére
Most hogy újra belegondoltam, az általad belinkelt eszmefuttatás jó korrelál az AMD régebben belengetett Fastforward HPC APU-jánál vázolt kétszintes memóriarendszerrel. Ott biztosan van értelme.
-
#254
Petykemano
veterán
ukornel
#252
-
sb
veterán
válasz
Oliverda
#243
üzenetére
Akkor egyetértünk. Viszont ez így egy tök sima üzleti döntés. Arra írtam, hogy előzményként ukornel még gyártástechnológiai problémákat is felvetett.
Szimplán még mindig túl drága és/vagy felesleges átlagusernek fejleszteni. De mindkettő szvsz megítélés kérdése is, mivel amíg nem lép egy szereplő sem addig nem derül ki, hogy mennyi drága.
Ahogy okostelót is csilliót adnak el pedig pár éve (van aki most is) azt szajkózta, hogy 4-5"-on semmire se jó az egész. Mégis mindenki elvan a gagyi kis appokkal. Lehet, hogy egy neurális hálóval megtámogatott bevásárlólista app ugyanígy tarolna. Arra sincs egyértelmű válasz szerintem, hogy a szegmentáció/szar fejlesztőkörnyezetek mennyiben hátráltatóak. Erre is számos példát láttunk már, hogy nem kell feltétlen a komplett piacot lefedni.Most kicsit úgy néz ki mintha mindenki kézifékkel próbálna előre menni és közben csodálkoznak, hogy nem haladnak, szűkülnek a piacok (és ezt nem csak x86 PC-re értem, PC gaming vs DX/HSA, ultramobil nem szűkül de kezd telítődni az is). Egyébként pedig fizikailag ott a lehetőség akár "robbantani" (tök új technológiát beépíteni a sw-kbe vagy a meglévő funkcionalitást 1 nagyságrenddel gyorsítani) is.
Összefoglalva én úgy látom, hogy:
- Technológiai (hw) oldalról nincs akadály, ott van egy nagyságrenddel több kraft ultramobiltól egészen a szerverekig bezárólag.
- Sw technológiai oldalról nyilván vérzik a dolog, de ez meg akarat és pénz kérdése lenne leginkább.
- A költség oldal az egyetlen ami érthető visszatartó erő, de ott meg aki nem mer az nem nyer. Mindenki ül inkább ugyanazon, lassan 10-20 éve és várják a tutit (megrendelést).szerk: Nem tudom mennyi tartalék van az x86-ban, de én ott sem látok sokat. Persze az Intel kényelmesen elvan, de azt sem látom, hogy kicsit nagyobb lépésekkel nem lenne-e jobb a helyzetük ha van még a tarsolyban valami. Az sw fejlesztőkről nem beszélve...
De ha van is tartalék, nem nagyságrendről beszélünk, én megkockáztatom az is, hogy még csak nem is duplázásról. Energiahatékonyságot sikerült növelni, de lefelé is rögös az út, láttuk már az ultramobil Intel hátraarcon. Pedig az Atomkor is félig feladta már a klasszikus x86 elveket: kevés mag, magas órajel. Ezek nem mennek energiahatékonyan. Szerintem minden a párhuzamosítás irányába mutat már nagyon régóta az összes szegmensben. -
#252
ukornel
aktív tag
Petykemano
#250
ukornel
aktív tag
válasz
Petykemano
#250
üzenetére
Bár nem én lettem megszólítva, de ezt nem egy másik topikba (VEGA, APU, HSA, mittomén) kellett volna inkább?
-
#251
Balala2007
tag
lenox
#240
Balala2007
tag
Melyik programok azok, amik SSE3-4-et hasznalnak, de AVX-et nem?
Amiket mar nem fejlesztenek tovabb, pl. Google VP8. VP9, VP10 hasznal AVX2-t, de a VP8 sztem sose fog.
-
#250
Petykemano
veterán
Petykemano
veterán
Szakértő Urak!
Mit gondoltok erről a jósgömbről?
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#245
üzenetére
Nekik igazából az AVX2 jött volna jól eredetileg is. De nem éri meg támogatni, ha még csak az esélye sincs meg annak, hogy belátható időn belül ott lesz minden prociban. Alapvetően a GPGPU-s irány nem rossz, de lassan tényleg olyan dolgok is átkerülnek, amik nem oda valók. Persze ez felfogás kérdése. A GPU is megcsinálja, amit kérnek tőle, csak a legtöbb GPU-t nem arra alakították ki, hogy terepszimulációt végezzen és mellette még számolja is a grafikát. De annak jóval nagyobb az esélye, hogy belátható időn belül minden GPU hatékonyan tudja majd ezt csinálni, minthogy a legolcsóbb procikba AVX támogatás kerül. Sajnos ilyen szerencsétlen tényezők alakítják az aktuális döntéseket.
-
-
Oliverda
félisten
Persze, hogy a pénz jelenti az akadályt, illetve egészen pontosan az, hogy nem éri meg a befektetett erőforrásokat konzumerben a heterogén, mert per pillanat a fejlesztők számára ez a legnehezebb és legkiszámíthatatlanabb út, egyszerűen nem éri meg az erőfeszítést. A szerver más tészta, hisz ott egy fix konfigurációra kell megérni a szoftvert, ami utána akár évekig is érintetlen marad, de ha cserélnek is benne pl. gyorsítókat, akkor is megéri újraoptimalizálni.
A fejlődés hiánya az Intel elmúlt 5-6 évben mutatott produkciójára alapozhatjuk, ami csalóka lehet, hisz egyrészt komoly konkurencia nélkül lébecolhattak, másrészt a célzott szegmenseknél nem az IPC növelés jelentette az elsődleges feladatot. A mobilnál a fogyasztást igyekeztek csökkenteni, illetve a fogyasztás/teljesítményt emelni, valamint a GPU-t erősíteni, szervereknél pedig a magszámot nyomták felfele. Ezzel arra próbálok célozni, hogy az x86-ban még van tartalék, csak kell a "motiváció" egy teljesen új fejlesztéshez, amit jó esetben az AMD megad a Zennel, illetve ezzel párhuzamosan azt is érdekes lesz figyelni, hogy az AMD évről évre mekkora lépésekkel tudja majd javítani saját mikroarchitektúrájának teljesítményét.
Fiery: Szerintem inkább ne vitatkozz egy igazi AVX guruval.
-
lenox
veterán
Melyik programok azok, amik SSE3-4-et hasznalnak, de AVX-et nem? Mert ugye ezek mutatnak meg, ha valaki olyat akarna fejleszteni, amit updatel az aktualis technologia alapjan, de nem hajlando AVX-re atterni, mivel az nem elerheto mindenhol. Nem vagyok kepben, de szerintem ilyen kb. nincs. Consumer vonalon szerintem a videos szoftverek kb. az erdekesek, es azok hasznalnak is AVX-et. Szoval szerintem nem lenne max alig tobb szoftver ami tamogatna, viszont igy sok extra penzt tud beszedni az intel erte. Ami nekem sem tetszik, de ez van, de ha hulyenek nezek oket ezert, akkor szerintem te tevedsz es nem ok. Marmint ha az uzleti erdekeiket nezik.
-
Abu85
HÁZIGAZDA
Persze, nem arról van szó, hogy nekik nem jönne jól. Az Intel méretével ők évi szinten másfél milliárdot le tudnának húzni a cégről egy MCM-es üzlettel. Az Intel aki ezzel nagyon rosszul jár.
Szerintem nagyon okos szoftvermérnökei vannak, illetve leginkább már csak voltak az Intelnek. Nem kamatoztatták a tudásukat. A hardver is igen kellemesen működne, ha beletolnának évi 100 millió dollárt, de ennek ma az ötöde a büdzsé, az is jórészt kutatásra megy el, ami részben pénzkidobás.
-
Abu85
HÁZIGAZDA
Az AMD-nek semi-custom divíziója van. Az Intel rendelhet és azt megtervezik. De dizájnokat nem adnak el. Ennek is megvan az oka. Az AMD-nek minimum 100 millió dollár az a szint, amit megkövetelnek egy semi-custom dizájnhoz. Ez alatt nem dolgoznak. A GPU IP-ket bőven 100 millió dollár alatti szinten szokás licencelni.
Nem, most egyáltalán nincs így. Az Intel elég jól áll. Például most nem lenne HDR-jük sem, ha az AMD szállítaná nekik a dizájnt.
Az Intelen belül ki kellene építeni egy bizalmat a mérnökök felé, mert már önmagában az az üzenet nem jó, hogy inkább vásárolnak folyamatos másfél éves lemaradást, minthogy valamit tegyenek annak érdekében, hogy a cégen belüli problémákat megoldják.
-
Fiery
veterán
"Az Intel nem tud licencelni, mert az AMD nem licencel. Ez nem vita tárgya"
Persze, hogy nem vita targya. Hanem megbeszeles targya, papirozas es sok penz. Minden elado, csak a megfelelo árat kell megtalalni.
"Tulajdonképpen az Intel minden egyes új interfész támogatásával késne az AMD-hez képest egy évet."
Miert, most nem ugyanigy van? Sot...
-
Abu85
HÁZIGAZDA
Az Apple résztulajdonos az Imaginationben, illetve úgy licencelnek, hogy elég sok dolgot átalakítanak az alaparchitektúrában manapság. Az Intel nem tud licencelni, mert az AMD nem licencel. Ez nem vita tárgya. Az AMD csak tervez megrendelésre. Na persze olyat, amilyet az Intel rendel, tehát bármilyen 3rd party blokkot beleraknak, ezzel semmi gond nincs.
Egy probléma lesz ezzel a modellel. Az AMD mindig előrébb fog járni, mert a semi-custom divízió nagyjából egy évvel később képes kínálni azt a hardverkomponenst, amit az AMD már használ. Tulajdonképpen az Intel minden egyes új interfész támogatásával késne az AMD-hez képest egy évet.
-
Cathulhu
addikt
Tudom, hogy te nem vagy hive az otletnek, de ettol fuggetlenul mind az AMD mind az Intel szamara elonyos uzlet lenne. AMD mint legnagyobb konkurens meg maximum egy evek ota erosen szukulo x86 piacon ertelmezendo kijelentes, mert az AMD nagyon messze all attol, hogy szamottevo konkurenciat tudjon az intellel szemben felmutatni, meg akkor is, ha a Zen jol sikerul.
-
Abu85
HÁZIGAZDA
Nem teljesen. Erről azt pletykálják most, hogy az AMD-vel akarnak megegyezni, hogy szállítsanak pici GPU-kat az Intel CPU-k mellé, amiket MCM-ben ráraknak a tokozásra. Ezeket a GPU-kat az AMD külön tervezné semi-custom részlegen belül, és az Intelnél lennének gyártva. Effektíve az AMD OEM-je lenne az Intel.
Elsődlegesen ezért akarják most Krzanich-ot eltakarítani, mert Renduchintala tépi a haját az ötlettől, ugyanis az Intel ezzel arra készül, hogy egy fontos komponenst a legnagyobb konkurensüktől vásároljanak. Renduchintala azt szorgalmazza inkább, hogy hozzák rendbe a szoftverrészleget, amitől nem működik a hardver, mert utóbbi jó.
-
Fiery
veterán
Nem a nyelv a lenyeg, hanem az elv, amivel az egesz mukodik. De hagyjuk is, hiszen jol lathato, hogy sem az AVX, sem a GPGPU nem tud elterjedni, hiaba erolteti oket tobb ceg is.
A GPU team budzsejenek megvagasa pedig SZVSZ eleg egyertelmu, hogy miert tortenik. Kulso ceget fog felvasarolni az Intel (Imagination?), vagy valakitol (RTG?) licencelni fogja a GPU technologiat, a mostani GenX pedig megy a kukaba, ahova valo. Ennel vadabb teoriakrol is beszelhetunk, pl. Qualcomm-Intel fuzio, de felesleges, hiszen ahogy irod is, elso korben a mostani, vastagon leszerepelt Intel CEO-t kellene eltakaritani.
-
Abu85
HÁZIGAZDA
CUDA, OpenCL, HIP, OpenMP, stb.
Consumer vonalon pedig SPIR-V, amit számos nyelvből lehet célozni. Leginkább az OpenCL C++ ajánlott. MS-nek jön a DXIL még idén.
Na ez a baj, hogy az Intel saját magát megszopatja a szegmentációval.
Égbekiáltó baromság, amit egy ideje az Intel vezetősége csinál. Még nem is az AVX a gond, hanem az, hogy te például gondolod, hogy ha a 2017-es büdzsét megvágják a GPU-s szoftveres csapatnak, akkor az jót tesz majd nekik? Mert most volt kasza rendesen annál a részlegnél. Számos inteles rendszerprogramozó fog a Frostbite Teamhez kerülni. Majd figyeld meg a GDC-n a neveket.
Jelenleg elég sokan azt remélik, hogy hamarosan Murthy Renduchintala lesz a CEO, mielőtt Krzanich nagyon szétkaszázná a fontos részlegeket.
-
#229
Fiery
veterán
Petykemano
#227
Fiery
veterán
válasz
Petykemano
#227
üzenetére
Alapveto kulonbseg van a x86/x64 vonal es a GPGPU vonal kozott. x86-on ha egyszer, veres veritekkel optimalizalod a kododat -- adott esetben assembly betetekkel -- SSE/AVX1/AVX2/AVX-512-re, onnantol minden, ezeket az utasitaskeszlet kiegesziteseket tamogato processzoron hibatlanul fog futni a kodod, modositas es bibelodes nelkul. A jelenlegi es jovobeni ilyen processzorokkal sem lesz, nem lehet gond. A kodod, az elkeszitett szoftvered ezzel "future proof".
GPGPU vonalon viszont 2 lehetoseged van. Vagy CUDA, es az NVCC-vel binarist forditasz adott compute capability-t celozva. Ez tok jo, csak ugye ha jon egy uj GPU generacio (pl. Pascal), akkor ahhoz forditanod kell (marmint celszeru megtenni) uj binarist, tehat nem tudsz altalanos ervenyu binaris kodot kesziteni, ami minden jovobeni nVIDIA GPU-n is egyforman remekul fog futni. Vagy CUDA+OpenCL vonalon tudsz kernel source-ot szallitani a szoftvereddel, de akkor meg on-the-fly kell forditani, kiteve magad annak a problemanak, ami mar 10 eve nincs megoldva, azaz hogy a CUDA/OpenCL fordito lehet, hogy lefagy, crash-el vagy csak ugy altalaban sz*r binarist fordit az adott vason, amin epp futtatjak a szoftvered. Tehat az x86/SSE/AVX binarissal ellentetben, az on-the-fly forditott GPGPU kod futasa es az eredmeny helyessege abszolut nincs garantalva. Hasonlo, mint az orosz rulett, csak nem hal bele senki
-
Fiery
veterán
"abban mindenképpen segítene az aktiválása, hogy a fejlesztő legalább mérlegelje, hogy AVX-et válasszon, vagy GPGPU-t, ne pedig csípőből menjen a GPGPU-ra."
A piacon elerheto CPU-k jelentos resze tamogat AVX-et. Ha nem tevedek, az Atom, Celeron es Pentium szeria nem tamogatja az AVX-et, de azon kivul minden. Tehat minden Core i3, i5, i7, Xeon; AMD vonalon pedig lenyegeben minden processzor. Ha ez nem eleg felhasznaloi bazis, akkor nem tudom, mi az. Ennyi erovel ha GPGPU-ban gondolkozol, ott meg az egyetlen ertelmes megoldas a CUDA -- de azzal a piacon levo GPU-k hany szazalekat tudod megcelozni? 20? 30? Talan... Hiszen hiaba a dGPU piacon az nVIDIA nagy folenye, az eladott GPU-k nagytobbsege Intel, az meg nem tamogat CUDA-t. Az OpenCL es HSA-val meg elo ne gyere, mert mar 10 eve varjuk az attorest, es mindig jovore kovetkezik be
Sz'al majd 2018-ban terjunk vissza ra...Egyebkent a merlegeles fejlesztoi oldalrol sokszor nem arrol szol, hogy melyikkel mekkora felhasznaloi bazist tudsz celozni, hanem sokkal inkabb arrol, hogy mekkora teljesitmeny elonyt tudsz elerni adott mennyisegu befektetett munkaval/energiaval. Ha a -- mar meglevo SSE kodhoz kepest peldaul -- AVX1/AVX2-vel mondjuk +50% gyorsulast tudsz elerni, de a GPU-val (egy izmosabb dGPU-val) meg +200%-ot vagy +500%-ot, akkor az AVX-et nem csoda, ha a GPGPU vonal izgalmasabbnak tunik fejlesztoi szemszogbol. Persze aztan sokan eljutnak oda, hogy a jo kis x86/x64 binaris az igazi
-
Fiery
veterán
"Az a baj, hogy olyan dolgokról beszélünk, amelyek a GPU-kban már rég benne vannak"
Es? Hogyan hasznalod ki? CUDA? Az csak nVIDIA GPU-kban van. OpenCL? Lenyegeben vege. HSA? Ha-ha...
"És miért nem kapcsolják be?"
Piaci szegmentacio. Egy technikai ceg nem csak technikai kerdesekrol szol. Egy termeket el is kell tudni adni, a profitot maximalizalni, ki kell tudni termelni a boduletes gyar epitesek koltsegeit, a bereket, R&D-t, stb. Nem mondom, hogy nem lenne jo dolog mindenhol bekapcsolni az AVX-et, de -- szerintem -- semmit nem segitene a mostani helyzeten.
-
Abu85
HÁZIGAZDA
Az a baj, hogy olyan dolgokról beszélünk, amelyek a GPU-kban már rég benne vannak.
És miért nem kapcsolják be? Ott van a lapkákban. Potyára rakták bele, vagy potyára fejlesztették? Baromságot csinálnak, már ne haragudj. Úgy soha sem fog elterjedni, hogy ha nem aktiválják a termékekben.
(#224) Fiery: Azért abban mindenképpen segítene az aktiválása, hogy a fejlesztő legalább mérlegelje, hogy AVX-et válasszon, vagy GPGPU-t, ne pedig csípőből menjen a GPGPU-ra.
-
Fiery
veterán
Azt az egyet **rvara elfelejted, hogy az AVX-512 nem csak a szelesebb vektorokrol szol. Mint ahogy az AMD64 sem csak dupla szelessegu cimzest es dupla szelessegu regisztereket hozta, hanem egy csomo mas elonye is volt. Pl. a tobb altalanos celu regiszter kapasbol baromi hasznos, es ezt _is_ hozza az AVX-512. Ha egy fordito annyira bena, hogy csak 128 vagy 256 bit szeles vektorokra tudja szetdobni a kodot, az AVX-512 mas elonyeibol (pl. scatter-gather, csak hogy egyet emlitsek) akkor is fog tudni profitalni a program, tud gyorsulni 256 bites vektorokkal is, ha az AVX1/AVX2-hoz hasonlitod.
"Emiatt sem kapcsolja be az Intel a consumer vonalon."
Mit nem kapcsol be az Intel? Az AVX-512-t jelenleg egyetlen piacon levo processzor tamogatja, a Xeon Phi legujabb generacioja (KNL). Az minden, csak nem consumer, raadasul semmilyen "megvagott" verzioja nincs ennek a processzornak, ami barmilyen szinten consumer vonalon bevetheto lenne (vs. mondjuk a Broadwell-EP szeria, amibol van "olcsositott", kvazi mainstream verzio Broadwell-E kodneven).
-
-
lenox
veterán
Amellett, hogy egy csomo szivas van az AVX-szel azert vannak elonyei is. Ha mar tesztelt, bevalt libraryt hasznal az ember, ami kihasznalja, akkor ugye nem kell alacsony szinten programozni, es ilyenek vannak. Ezen kivul nem kell driver installal, kompatibilitassal, verzioval szivni.
-
sb
veterán
válasz
Oliverda
#217
üzenetére
Ezzel az a gond, hogy szerintem hozzáállás, de ha nem akarok rosszindulatú lenni akkor költség oldali probléma és semmi köze a technológiához. Se gyártáshoz, se máshoz.
A kívánatos teljesítményfejlődés az 1-2 szálas 20GHz-es proci lenne mert azon minden sz*r elfut.
A valóságban - fentebb is - viszont csak párhuzamosított megoldások jöhetnek szóba mint SIMD, több cpu mag, több gpu "mag". Vagyis sebesség helyett számolóegység-mennyiség sokszorozás leegyszerűsítve.Az világos, hogy nem minden párhuzamosítható, nincs is rá szükség minden esetben és ha mégis akkor sem triviális fejlesztési feladat. De akkor valahol bele kéne törődni, hogy ez van. Átlaguser számológépbe, passzinászba, FB kliensbe nem kap ilyet és vehet 1-2 magos cuccokat. Szerver, WS oldalon meg megvan az igény és forrás is rá, oda fejlesztenek ezt-azt. De akkor consumer oldalon el kell fogadni, hogy nincs fejlődés, nem lehet eladni a 6-8-10-20 magos csodákat és csillivilli új sw-ket. Marad ugyanaz a piac ugyanazokkal a korlátokkal.
Pedig potenciál tuti lenne benne. Egyrészt a mobil/ultramobilban akkuidőt lehet vele nyerni amire most azért használják is (na jó, a fixfunkciós hw inkább hódít sajnos ott is). Másrészt, visszatérve a sima passziász-FB kliens körbe, bármibe bele lehet tolni 1-2 "okosfunkciót", egy kis képfeldolgozás, AI, gépi tanulás, stb... Nem kell otthon renderelni, hogy sok magra meg gpgpu-ra legyen (gerjesztett) igény.
Ez szerintem még mindig sima bevétel-költség harc. Amíg van bevétel másból addig nyilván a könnyebb utat választják. Bekerül egy M.2 slot vagy kikerül egy feature, a HDMI 2.0-ra is igen sokat kell várni... ezekért majd megveszi a user az új telefont, vagy 5-6 éve csak ráncfellvart és alig módosított procit az új platformmal. Addig ott állhat pár tflops a gépében kihasználatlanul, ha van rá igénye akkor is. Ha nincs és elég az M.2 is a váltáshoz az még jobb.
-
Abu85
HÁZIGAZDA
A HPC-re a ROCm a platformjuk. Az pedig tulajdonképpen a HSA némi extrával. Ha arra írsz egy programot, akkor tulajdonképpen ugyanazzal a HCC fordítóval célzod a GPU-t és a CPU-t is. Effektíve innen mindegy, hogy van-e AVX-512-d vagy sem. Az AVX és AVX2 is csak a kompatibilitásért van nem pedig a teljesítményért. A fő probléma, hogy ha ezeket ki is akarod használni, akkor nem elég a fordítóra építeni, hanem vector intrinsics kell. A ROCm viszont egy olyan csomag, ami igazából nem teszi a fejlesztőknek kötelezővé, hogy majdnem assembly szintig menjenek az optimalizálásért. És ezt az AMD nagyon fontosnak tartja, mert nagyon kevesen értenek annyira a programozáshoz, hogy egy vector intrinsics-re építsenek jövőt. Sokkal kedvezőbb azt mondani a fejlesztőknek, hogy jól van, látom, hogy tetszik a CUDA, én ehhez adok egy olyan csomagot, amellyel bármilyen kódot át lehet fordítani ugyanolyan teljesítményű HIP kódra egy hét alatt, megőrizve a kompatibilitást az NV GPU-kkal is.
A throughput az AVX optimalizálástól is függ. 512 bites SIMD-re már nem fog olyan hatékonyan fordítani a fordító, hogy abból neked előnyöd legyen. Le kell menni az assembly szint fölé és kézzel kell segíteni. Ez túl időigényes. Emiatt sem kapcsolja be az Intel a consumer vonalon. Az itteni alkalmazások már az AVX2-vel is küzdenek, már arra a párra gondolva, amelyik egyáltalán számításba vette, az AVX-512 reménytelen lenne ezen a területen. Nem véletlen, hogy az ARM a saját SIMD rendszerét nem ilyenre szabta, mert az az általános tapasztalat, hogy a fordító egy bizonyos szélességű SIMD felett nem tud jól működni. Utána bármennyi pénzt raknak bele, akkor is le kell menni kézzel korrigálni azokat a kurva vektorokat. Nagyjából 128 bit az a határ, ahol az eredmények jók, és 256 bites SIMD-től egyre sűrűbben kell alacsony szintű kóddal bíbelődni. Az ARM emiatt hagyta is a fenébe ezt a modellt, mert zsákutcának tartják, és inkább egy GPU-któl lopott SIMT-hez hasonló modellt építenek be a CPU-ba. Ott 2048 bitig is el lehet vinni a hardvert és a fejlesztőnek csak a fordítóra kell építenie, mindenféle nehézkes, alacsony szintű kézi optimalizálás nélkül.
Nem tartom kizártnak, hogy a jövőben az x86-os processzorok is egy hasonló elvű megközelítésre cserélik az AVX-et.A HSA az csak egy vISA a hardver elég. Nem sok köze van ahhoz, hogy a hardverre hogyan kell optimalizálni. Egyszerű eszköz ez arra, hogy az alkalmazások több architektúrán keresztül is futtathatók legyenek úgy, hogy közben egy bitnyit nem módosulnak.
-
#218
Abu85
HÁZIGAZDA
Petykemano
#215
Abu85
HÁZIGAZDA
válasz
Petykemano
#215
üzenetére
Nem. Ezekre a megoldást úgy hívják, hogy aszinkron compute.
Jelenleg már számos programban dolgoznak a régi CPU-s szimulációk átvitelén GPU-ra, mert az aszinkron compute-tal a képszámítással párhuzamosan meg lehet csinálni. Hamarosan így fog működni a Nitrous terepszimulációja, ami klasszikus formában CPU-s megoldás, de mivel minimum hat magot igényel az AotS-ben a nagy pályáknál, ezért átviszik aszinkron compute-ra, és így már elég lesz a négy mag is, ha a GPU képes futtatni a párhuzamos feladatszámítást.
Többen beszéltek erről a modellről a SIGGRAPH Asia rendezvényen. Főleg a Khornos támogatja, mivel a SPIR-V ehhez nagyon jó alap, de a Microsoft is hozza a DXIL-t hozzá.
Persze a legnagyobb gond a konzol. Ott az a baj, hogy nagyon kevés a CPU-ban lévő SIMD számítási teljesítmény, tehát az új motorokat muszáj erre az aszinkron compute modellre felépíteni. A PC pedig ennek a portját kapja meg és kész.
Aztán egyébként az API-k számára tulajdonképpen mindegy, hogy melyik GPU-n futtatod a számítást. Akár megteheted az IGP-n is, csak arra kell küldeni a feladatot. A DirectX 12 kezeli ezt már ma, és a Vulkan 1.1 is fogja még idén. De itt van egy kis ellenérdek a gyártók részéről, mert az AMD most inkább azt akarja, hogy ezek a feladatok fussanak a dedikált GPU-n, mert nagyon erősek a Radeonok aszinkron compute-ban. Az NV és az Intel akarja azt, hogy legyenek inkább az IGP-k használva. Az Intel azért, mert nekik van egy csomó eladott is kihasználatlan IGP-jük, és ezzel mondjuk egy jó lehetőséget adnak a fejlesztőknek, hogy ne a minimum magszámra vonatkozó igényt növeljék, míg az NV azért, mert szar az architektúrájuk aszinkron compute-ban.
-
Oliverda
félisten
"Aham, az APUk, és a sok jól párhuzamosítható számolás kiszervezése az IGP-be?"
Az látjuk mennyire jött be kliens oldalon, egész pontosan semennyire. Egy ideje már nem is mantrázzák, ezzel párhuzamosan pedig nem véletlenül feküdtek a Summit Ridge-re. A szerver (és részben a WS) más tészta, ergo az APU-nak mint heterogén végrehajtású processzornak még lehet légjogosultsága, csak épp nem kliens oldalon. Ennek ellenére biztosan megemlítik majd a Raven Ridge-nél is a lehetőséget, de nem ez adhatja majd el, hanem az erős CPU és GPU egy tető alatt, kedvező fogyasztással.
-
ukornel
aktív tag
válasz
Oliverda
#214
üzenetére
"Ezek leginkább csak HPC-hez kellenének, oda pedig egyelőre más tervei vannak a cégnek."
Aham, az APUk, és a sok jól párhuzamosítható számolás kiszervezése az IGP-be? Eddig talán a memóriasávszél, vagy a potens processzorarchitektúra hiánya szabott gátat nekik. Kíváncsian várom, mit hoz a jövő...
-
-
ukornel
aktív tag
"Amíg a Celeronok és Pentiumok AVX nélkül mennek el, addig az AMD sem nagyon erőlködik [...] Nem lesz program, ami használja a consumer vonalon."
Ez oké és érthető - de remélem, nem a Cerkák és Penyák, meg a consumer vonal jelentik a jövőben a kizárólagos viszonyítási alapot az AMD-nél. Arról volt szó, hogy ráúsznak a nagy profitot jelentő (HPC, szerver) piacokra is - pénzügyileg baromi fontos lenne, ha ismét érdemleges szeletet tudnának hasítani ezekből. Kérdés, hogy ott tényleg fontos-e az AVX2&3, vagy el lehet-e gond nélkül anélkül is adni a procit? (arra tippelek, hogy fontos)
"az AMD sem nagyon erőlködik azért, hogy valóban 256 bites legyen a SIMD. [...] Az AVX-512-t egyébként be lehet építeni 128 bites SIMD-re is, ez valószínűleg ott van a todo listán."
Igen, ez így volt már a Bulldozernél, ahol két mag 128 bites lebegőpontos egysége kapcsolódik össze egy 256-bites AVX művelet erejéig és most a Zen is magonként két (szálanként egy) 128 bites FMAC-t tud, a 256 bites AVX op. kettébontva hajtódik végre. Ehhez hasonlóan nyilván az 512 bites műveleteket is le lehet bontani négy lépésre, és ki van pipálva a feladat. Az érem másik oldala viszont az alacsonyabb throughput az AVX-intenzív feladatokban.
A fentieket nyilván az AMD okos emberei is tudták a Zen tervezésekor, mégis bevállalták ezt a kompromisszumot. Mi húzódik ennek a döntésnek a hátterében?
a) Nehéz hatékonyan kihasználni a 256 bites, pláne az 512 bites vektorutasításokat a programokban, ezért a futás sebességét úgysem a natív FMAC szélesség határozza meg, tehát nem is éri meg vesződni vele.
b) Korábbi jelentések szerint az 512 bites vektorszámolók intenzív használata nagyon koncentrált, melegedést (forró pontokat) okoz a processzoron belül, amit nehéz kezelni. Az AMD nem akar pofonért menni oda, ahol az Intel is szenved.
c) A mérnökök látják, hogy a SIMD zsákutca, és nem erőltetik túlságosan, csak hozzák a kötelezőt, hogy ne érje szó a ház elejét.
d) Az Intel sem erőlteti túlságosan az AVX2&3 terjedését, csak néhány termékcsaládban van/lesz aktív.Ha az a), és/vagy a c) igaz, az elég szomorú hír teljesítménynövelés jövője szempontjából. A HSA döglődik, az Intel-féle SIMD sem használható jól - marad a tyúklépésekben araszolgatás, és a rendületlen hit a csodagrafénben, meg a kvantumszámítógépekben
Ha a b) az igazi ok, akkor lehetséges, hogy a gyártástechnológiai fejlődés előbb-utóbb kinövi ezt a problémát. A baj csak az, hogy a gyártástechnológiai fejlődés is belassult és megdrágult ... -
válasz
Oliverda
#205
üzenetére
Fogalmazzunk úgy, hogy nem vadonatúj, elvileg, szerintem. Mert ez csak spekuláció, hogy vajon lesz-e köze Jaguár / Puma archokhoz olyan szinten, mint a Intelnél a Core 2 a Pentium M-hez.
Ami izgalmasabb az az, hogy az Intel miképp fog új (nem csak finomított) architektúrát csinálni. Az mindegy, hogy a Zen jó lesz-e, az Intelnek hamarosan valami igazán újat kell alkotnia, mivel nem nagyon van már előrelépés. S itt a kérdés, hogy hova nyúljon? Szerintem egyáltalán nem garantált az, hogy jó is lesz, nagy a kockázat.
-
Abu85
HÁZIGAZDA
Amíg a Celeronok és Pentiumok AVX nélkül mennek el, addig az AMD sem nagyon erőlködik azért, hogy valóban 256 bites legyen a SIMD. Nem lesz program, ami használja a consumer vonalon. Az AVX-512-t egyébként be lehet építeni 128 bites SIMD-re is, ez valószínűleg ott van a todo listán.
-
-
Oliverda
félisten
Mi számít újnak? Világos, hogy nem minden részeleme vadiúj, korábban nem látott megoldás, bizonyos dolgokat átemeltek kisebb-nagyobb módosításokkal, összességében viszont újnak tekinthető. Az más kérdés, hogy a Zen alapvetően egy konvencionális megoldás, távolról sem olyan innovatív, mint amilyen a Bulldozer volt, de sokszor nem ezen áll vagy bukik a piaci siker, amire számos példa volt és van. Sokszor jobban megéri a jelenre fejleszteni, amit épp az AMD tanulhatott meg az elmúlt pár év GPU-s megoldásaiból meg a konzumer piacra erőltetni próbált HSA/OpenCL-ből. Az megint más lapra tartozik, hogy a Zenben mennyi fejlesztési potenciál van, jelen állás szerint érthető okokból több mint a Skylake-ben, 4-5 évig ellehetnek vele, utána viszont az AMD-nek is egy alapjaiban új megoldás után kell néznie. Ha ezt az Intel meglépi 2020 környékén, akkor 1-2 év múlva majd mehetnek utána, tanulva az esetleges hibákból.
-
Oliverda
félisten
A Core vonalban már nincs több fejlesztési potenciál, pár százalékot még össze lehet kaparni itt-ott, ami Haswell óta látszik, hogy nagyjából mennyit jelent. Teljesen új mikroarchitektúra kell, ami jó eséllyel áldozatokkal fog járni, lásd anno P6->Netburst váltás. Ezt 2-3 éve kényelmesen be tudta volna vállalni az Intel, amíg az AMD a Bulldozerekkel szenvedett, szoros mezőnyben sokkal nehezebb lesz meglépni (ugyancsak lásd anno P6->Netburst váltás). Ennek oka, hogy mára a releváns x86-os appok jelentős része Core-ra optimalizált, egy gyökeresen más architektúra ezért kapásból hendikeppel indul, lásd Bulldozer. Ezért majd újra kell fordítani, illetve optimalizálni az alkalmazásokat, ami jellemzően több hónapot vagy akár évet igényel, eközben viszont az AMD előnyben lehet a Zen vonallal, ami mai szemmel nézve összességében egy konvencionális megoldásának tekinthető, ergo jól futnak rajta a Core-ra optimalizált alkalmazások.
Ez gazdaságilag, és logikailag is elég értelmetlen húzás volna az AMD-től, akinek most minden morzsányi szilícium számít. 
Lesznek itt még az év vége felé két, meg három magos Ryzen Athlonok ( non. L3 ) is meglásd ! 
de Intelnél ,hogy-hogy nincs ilyesmi? Azért mert nem modulos?
Sz'al majd 2018-ban terjunk vissza ra...
Új hozzászólás Aktív témák
- OLED TV topic
- The Division 2 (PC, XO, PS4)
- Total Commander
- VR topik (Oculus Rift, stb.)
- Lenovo Legion Go: a legsokoldalúbb kézikonzol
- Háború Izraelben
- A fociról könnyedén, egy baráti társaságban
- LEGO klub
- Majdnem száz játékhoz engedélyezi az FSR 4-et az új AMD Software
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- További aktív témák...
- Xbox Game Pass Ultimate előfizetések kedvező áron
- Asus ROG Flow Z13 WUXGA 120Hz 2in1 Touch i9-12900H 14mag 16GB 512GB Nvidia RTX 3050Ti Win11 Garancia
- Apple iPhone 15 128 GB Kék 12 hónap Garancia Beszámítás Házhozszállítás
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 13 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3356
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest