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?

17 Komentarai

  1. newdiamond parašė:

    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….

  2. ZeroFM parašė:

    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

    • Daimonass parašė:

      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.. 😀

    • kernel_panikuoja parašė:

      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 🙂

    • adex parašė:

      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

      • Minde parašė:

        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

        • newdiamond parašė:

          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

          • kernel_panikuoja parašė:

            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.

          • Minde parašė:

            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 😉

Parašykite komentarą