Új hozzászólás Aktív témák
-
félisten
-
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.
[ Szerkesztve ]
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
válasz Oliverda #203 üzenetére
Ami az Intelnél a P6 -> Pentium M -> Core 2 az az AMD-nél a K8 -> Bobcat -> Zen. Nem? Szóval ez alapján a Zen se új, s az Intelnek nincs hova nyúlnia, mert nem nyúlt mellé mostanában semmivel.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
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.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
Yutani
nagyúr
-
pilu85
őstag
a bulldozer is eléggé 0 ról lett felépítve. 0,16 os csíkszélességen 5-6 ghz-n versenyképes is lett volna. erre a thubanok agyba főbe verték a bullokat.
"A jó hír: ha fel tudod ismerni egy illúzióról, hogy illúzió, akkor szertefoszlik. "Az illúzió felismerése annak végét is jelenti. Életben maradása attól függ, hogy összetéveszted-e a valósággal."
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
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 ...[ Szerkesztve ]
-
Oliverda
félisten
A tippem, hogy az 512 bites natív támogatás kimarad, de azt sem zárnám ki, hogy semmilyen formában nem fogják támogatni. A 256-ot talán, de arra sem mernék fogadni. Ezek leginkább csak HPC-hez kellenének, oda pedig egyelőre más tervei vannak a cégnek.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
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ő...
-
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.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
-
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.
-
Abu85
HÁZIGAZDA
És ezek az előnyök arra elegek is, hogy ne nulla AVX program legyen consumer szinte, hanem egy maréknyi.
Sokat dobna egyébként a dolgon, ha az Intel vezetése nem lenne komplett hülye, és engedélyeznék az AVX-et a teljes termékskálán.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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).
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
-
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
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
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
-
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ó.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Ashy Slashy, hatchet and saw, Takes your head and skins you raw, Ashy Slashy, heaven and hell, Cuts out your tongue so you can't yell
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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 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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
-
Griff55
senior tag
Lehet tudni valamit a megjelenésről? Lassan már nem lehet halogatnom a processzorcserét... És jelenleg az intelen kívül nincs más alternatíva, pedig szívem szerint maradnék AMD-s.
PS5 | iPhone 13 | Xiaomi Pad 6 8/256
-
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.
[ Szerkesztve ]
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
Abu85
HÁZIGAZDA
A Codemasters legújabb motorját leszámítva mindegyik új fejlesztésű videojáték-motor ilyen.
A Nitrousnál például csak azért viszik GPGPU-ra a terepszimulációját, mert az AVX2 nem érhető el mindenhol. Amúgy az AVX2-re mennének, de így nem éri meg.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Oliverda
félisten
"A Nitrousnál például csak azért viszik GPGPU-ra a terepszimulációját, mert az AVX2 nem érhető el mindenhol."
Vagy azért mert tudják, hogy mi a különbség az AVX és az AVX2 között.
[ Szerkesztve ]
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekbő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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
Szakértő Urak!
Mit gondoltok erről a jósgömbről?
Találgatunk, aztán majd úgyis kiderül..
Új hozzászólás Aktív témák
- ELADÓ - Ryzen 7 5800X
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- 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 i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel