AMD „Navi“ – 2018 m. trečiame ketvirtyje
Pasirodė gan įdomi informacija, susijusi su AMD tolimesniais planais grafikos srityje. „TweakTown“ praneša, kad AMD nusprendė paankstinti „Navi“ architektūros išleidimą, todėl tokių vaizdo plokščių debiutas numatytas jau kitų metų trečiame ketvirtyje (liepa-rugsėjis). Nepaisant to, kad turėtume sulaukti per taktą išaugusios spartos, priedo tai turėtų būti visiškai naujos epochos grafikos srityje pradžia.
„Navi“ architektūra bus sukurta pasitelkiant „Ryzen“ filosofiją, kuomet mažesni lustai sujungiami specialių jungčių pagalba ir darbuojasi kaip vienas. Toks daugialustinis modulis (angl. multi-chip module, MCM) bus visiškas perversmas grafikos srityje. Apie panašias idėjas yra paskelbusi ir „nVidia“. Kol kas visiškai neaišku kokiu būdu bus sujungiami grafikos procesoriai, bet AMD „InfinityFabric“ jungtis atrodo geras kandidatas šiam darbui. „Navi“ grafikos procesoriai turėtų būti gaminami pasitelkiant 7 nm litografiją.
Kompanijas daugialustinis modulis vilioja dėl to, kad pagaminti kelis mažus sveikus lustus yra daug pigiau nei vieną didelį. Kaip matome, ši taktika puikiai pasiteisino su „Ryzen“. Dabar lieka tik vienas klausimas, kaip tokios vaizdo plokštės su keliais grafikos procesoriais susitvarkys su žaidimais?
Loading ...
tai gaminti mazesnius ne vien kad pigiau, bet supranti ir broko maziau bus.
O tas skaidriu „perfomance per watt gains“ tai ir juokinga ir graudina tuo paciu metu….
Primetam 8mėn prie ale numatomo išleidimo ir tai abejoju ar bus kas .
infiniti bairis nesuveiks gpu srityje nes praktiškai viskas nuo žaidimų kūrėju priklauso
Nepamiršk kad cia neoficiali informacija. Neuzkipk ant jauko skirtiems neišmanėliams.. Belekuris žmogus turintis srauta žmoniu, t.y didesni koki tinklapi, gali sukurti tokia skaidre ir paskelbti, ir tokie kaip tu, ziurek jau tiki.. 😀
Siaip infinity fabric kaip tik GPU srityje daug labiau tinkamas, nes GPU load’as yra by design pararelinis. Zaidimo kurejams jokio skirtumo, ar 4096 stream branduoliu ateina is vienos serdies, ar is dvieju po 2048 – jie matytu tik viena render device’a abiem atvejais. Cia labiau klausimas butu, kokia itaka turetu papildomai inesti velinimai, del ko vaizdo ploksteje teoriskai atsirastu NUMA efektas.
Kitavertus, siai dienai nera aisku, ar NAVI naudos sita sprendima. Ziniasklaida turbut vel hype’ins apie busimus AMD GPU, nes matomai susilaukia srauto is tokiu naujienu 🙂
Dual-gpu puikus pavyzdys kokia tragedija gautūsi
Kiek zinau, dual gpu veike skirtingu pagrindu, kad abu gpu apdorodavo po skirdingus frame’us, panasiai kaip sli ar crossfire. Cia pats gpu cipas keisis, kitaip managins savo skaiciavimo blokus ir tiek.
O prie ko čia Dual-GPU?
Nes kai kuriems atrodo, kad cia yra panasus dalykai..
ta pati norejau parasyti
tik nebutu tokio NUMA efekto kaip CPU, nes nereiketu vieno threado uzduociu permetineti nuo vieno branduolio ant kito. Budu savitos GPU velavimu ar cache’u idomybes.
Is esmes taip. Nebent padarys kazkoki sprendima, kad on-chip shared atmintis/cache eitu per infinity, o lokali butu tight-coupled. Tada gali pasireiksti, teoriskai. Senai besidomejau GPU sandara, berods paskutini karta tik GTX 8800 serija 🙂 Kiek pamenu, net tame sename GPU yra gan griezta struktura, branduoliai turi savo grupes, cluster’ius ir t.t., ne visi gali share’inti su visais. Infinity siaip turetu gan graziai logiskai cia isipaisyti, prides kazkiek delay, bet gal nebus tragedija. Na, matysime…
matysime. Jei pavyks, seks Nvidios atsakas 🙂
nesik sausais miltais nanotechnologiju inzinieriau. infinity bajeriui nera kazkokios kliuties kad nesuveiktu. tik kaip kernel_panikuoja sako idomu kaip su velavimais butu, ar eitu draiveriu lygmenyje tai ispresti ar maksimaliai susvelninti, ar viskas priklausytu nuo zaidimu developeriu malones. aisku tik vienas faktas, kad nvidia shitworkais sugimpinti zaidimai tikrai tures didesniu problemu
pagal ideja tai neturi niekaip itakoti developeriu. Ir prie ko cia developeriai? Taip ir taip GPU cipas turi ten n vienoku skaiciavimo bloku ir m dar kitokiu. Tiesiog pats chipas juos kitaip managins, atsiras skirtingi siek tiek skaiciavimo/velavimo greiciai, bet lygiai taip pat tie skirtumai atsiranda vis su skirdintu modeliu. Va gali buti niuansu su driveriais.
Ir cia ne tai kai low lvl api, high lvl api, cia isvis pasleptas api, kur niekam neidomu kaip jis tvarkosi, jei tvarkosi 🙂 tad developeriams vienodai turi sviesti
sakyciau buti kvaila palikti developeriui palikti paskirstyti resirsus tarp gpu.ten turi buti sprendimas hw. ivedei ir gpu daro taip kaip sugalvojo amd.aisku bendradarbiavimas neidvengiamas kuriant tokia revoliucija
Kad net nelabai yra kaip palikti. DX12/Vulkan kiek zinau neturi jokio standartinio API kaip valdyti kazkokius vieno GPU vidinius lokalumus, tik turi mGPU. Tai reiketu ivesti hw-specific extension’us tam, ir turbut net kiekvienai kartai atskirus. Vulkan’o grupe stengiasi tu extension’u turetu kuo maziau, kad nesikartotu OpenGL’o scenarijus su jais.
As asmeniskai manau, kad jeigu ir bus sitas sprendimas, bus pilnai abstrahuotas gelezyje/firmware’e ir gal kazkiek driver’yje.
nebutinai kvaila, tik kam to reikia? Cia ziauriai ziauriai low lvl api ir ji suvaldyti butu didesnis uzdavinys (gal) negu sukurti zaidima. Jei visgi del kokiu nors X priezasciu kam nors reiktu tokiu optimizaciju ar konfiguraciju, butu sukurtas atskiras siek tiek abstrakcijuotas ir siek tiek aukstesnio lvl api, ir aisku kazkiek apribotas GPU resursu ar pasiekiamumo atzvilgiu. Kiek teko matyti GPU Nvidios programavimo kodo pavyzdziu, tai ten normalus sukurtas atskiras tam specialiai skirtas API. Nors CUDA ir nera skirtas tam 😉